The Role of Standards in Open Source
Without standards, the Internet would become a Tower of Babel. Our freedom to speak what we wish depends fundamentally on our agreement to speak the same languages. Standards are the common linguistic foundation on which we build our diverse world. To be useful for software, a standard must be available worldwide and be free of encumbrances that prevent its widespread adoption.
Consider the implications for the owner of intellectual property (e.g., the owner of a patent or copyright) who wishes to promote that property as the basis for an industry standard. Or consider the interests of a developer of industry standard software who learns that another person's intellectual property blocks the implementation of the standard. Is private intellectual property compatible with industry standards in an open-source world?
This is not an academic question. Standards organizations everywhere are trying to decide how to incorporate private intellectual property into the framework of the Free Software Foundation guidelines and the Open Source Definition, under which source code must be published and the software must be available for free copying, modification and distribution.
Patents pose the greatest threat to standards and their implementation in open-source software. Any person who owns a patent containing claims that are essential to the implementation of a standard can prevent you from making, using or selling products that implement that standard.
I won't bother defining the phrase “essential claims” here, but consider the effect if the only technically feasible or economically practical way to implement a standard requires the use of patented technology. Since the law generally doesn't mandate compulsory licensing of patents and doesn't define “reasonable” royalties, the standard may be effectively off-limits for those who can't afford to pay or to design around the blocking technology.
Many people complained publicly when the World Wide Web Consortium (W3C) tentatively proposed a patent policy that would allow adoption of web standards based on patented technology for which reasonable and nondiscriminatory (RAND) royalties could be charged. The Free and Open Source communities argued that such royalties—even if they are “nondiscriminatory”, as between rich and poor—are not compatible with software that is distributed with source code under licenses that permit free copying, modification and distribution. As a result of that public outcry, the W3C patent policy currently is being redrafted. By the time this article appears, a new draft patent policy should be available for public comment at www.w3c.org.
One solution to this patent problem for standards is to require that owners of intellectual property license their patents, royalty free, for use in implementing industry standards. Members of organizations such as W3C agree to do just that (under certain conditions that they describe on their web site). Not all standards organizations have such policies. Implementers of standards should verify, by reviewing the patent policies of the organizations that promulgated the standards, that there are no known patent obstacles to the implementation of those standards.
Even when patents are licensed for implementation of the standard, the patent license may not be compatible with the license under which the resulting software will be distributed. For example, some patent license provisions typically say that the patent is licensed only for implementation of the specific standard (a “field of use” restriction).
The GPL is not compatible with patent licenses that are restricted as to field of use. GPL software must be free so that anyone can create derived works, including derived works that are used for other purposes. (Hackers say that the code must be available for “forking” and for “reuse” in other applications.) Patent licenses with field-of-use restrictions run afoul of section 7 of the GPL, which reads in part: “[If] a patent license would not permit royalty-free redistribution of the Program by all those who receive copies directly or indirectly through you, then the only way you could satisfy both it and this License would be to refrain entirely from distribution of the Program.”
Because business motives of patent licensors differ, you will need to read the patent licenses, and the policies of the standards organizations, to make sure that the license you receive to a patent is compatible with your open-source software. Seek out standards organizations like W3C and the Embedded Linux Consortium that invite input from the Open Source community on their patent policies and procedures.
Be aware that “industry standards” are not always what they seem. Some companies or standardizing organizations attempt to control standards through copyrights on specifications, or by requiring payment for the use of certification marks to demonstrate adherence to the standard. Such restrictive techniques are fundamentally incompatible with open source and free software.
Many of us in the Open Source community are working, often behind the scenes, to convince companies to avoid restrictive standards and to share control over such standards so as to make them truly available under free and open-source terms. The good news is that our input is increasingly being solicited, and that the resulting standards are often now compatible with free and open-source licensing.
Legal advice must be provided in the course of an attorney-client relationship specifically with reference to all the facts of a particular situation and the law of your jurisdiction. Even though an attorney wrote this article, the information in this article must not be relied upon as a substitute for obtaining specific legal advice from a licensed attorney.
Getting Started with DevOps - Including New Data on IT Performance from Puppet Labs 2015 State of DevOps Report
August 27, 2015
12:00 PM CDT
DevOps represents a profound change from the way most IT departments have traditionally worked: from siloed teams and high-anxiety releases to everyone collaborating on uneventful and more frequent releases of higher-quality code. It doesn't matter how large or small an organization is, or even whether it's historically slow moving or risk averse — there are ways to adopt DevOps sanely, and get measurable results in just weeks.
Free to Linux Journal readers.Register Now!
- Hacking a Safe with Bash
- Django Models and Migrations
- Secure Server Deployments in Hostile Territory, Part II
- The Controversy Behind Canonical's Intellectual Property Policy
- Huge Package Overhaul for Debian and Ubuntu
- Shashlik - a Tasty New Android Simulator
- Home Automation with Raspberry Pi
- Embed Linux in Monitoring and Control Systems
- KDE Reveals Plasma Mobile
- diff -u: What's New in Kernel Development