Open Source Software Licensing

For over 30 years, open source software (OSS) has formed the backbone of the technology industry. Today, it is nearly impossible to find a computing device that does not utilize an open source component. For example, the Linux kernel powers well over a billion devices. As the adoption of OSS accelerates, it is increasingly important to understand the history, legal issues, and future challenges of the open source world.

What is OSS?

OSS is computer software that is released under a specialized license that grants users permission to view, change, and redistribute the software. The actual source code of such software is “open” to the public.

The philosophy behind OSS can be traced back to the Free Software Movement of Richard Stallman.^[1] A researcher at the MIT Artificial Intelligence Laboratory in the early 1980s, Stallman pioneered the leading open source license of the time: the GNU general public license (GPL).^[2] Stallman challenged traditional proprietary licenses through GPL by establishing software that could be developed communally and collaboratively, while guaranteeing the rights of end-users to modify and redistribute the source code.

Shortly after GPL, the Open Source Initiative (OSI) was formed to spread the open source philosophy. OSI developed the “Open Source Definition,”^[3] which includes the following core principles:

1. Free Redistribution: The license shall not restrict any party from selling or giving away the software as a component of an aggregate software distribution containing programs from several different sources.
2. Source Code: The program must include source code, and must allow distribution in source code as well as compiled form.
3. Derived Works: The license must allow modifications and derived works, and must allow them to be distributed under the same terms as the license of the original software.
4. Integrity of The Author’s Source Code: The license may restrict source-code from being distributed in modified form only if the license allows the distribution of “patch files” with the source code for the purpose of modifying the program at build time.
5. No Discrimination Against Persons or Groups: The license must not discriminate against any person or group of persons.
6. No Discrimination Against Fields of Endeavor: The license must not restrict anyone from making use of the program in a specific field of endeavor.
7. Distribution of License: The rights attached to the program must apply to all to whom the program is redistributed without the need for execution of an additional license by those parties.
8. License Must Not Be Specific to a Product: The rights attached to the program must not depend on the program’s being part of a particular software distribution.
9. License Must Not Restrict Other Software: The license must not place restrictions on other software that is distributed along with the licensed software.
10. License Must Be Technology-Neutral: No provision of the license may be predicated on any individual technology or style of interface.

Today, a wide variety of OSS licenses exist. OSI plays an important role in “verifying” new open source licenses to ensure that each license upholds the core tenants of the OSI definition. While most open source licenses follow OSI’s broad principles of granting users the permission to view, change, and redistribute the software, the way in which each license achieves these principles varies. Open source licenses can be grouped into permissive licenses and copyleft licenses.

Permissive licenses can be considered as “public domain” licenses. These licenses typically grant users the right to do what they please with source code, from repackaging the source code into another open source project to incorporating the source code into proprietary products. The only caveat of a permissive license is that correct attribution must be provided. When an author of an open source project releases their source software under a permissive license the author is given no guarantee for how the source code will be used and/or distributed in the future. Examples of widely-used permissive licenses include the MIT license,^[4] the Apache license,^[5] and Berkeley Software Distribution (BSD)^[6] licenses.

Copyleft licenses allow users to view, change, or redistribute source code, but require that any derivative work from the source code uphold the copyleft license. More specifically, when an author of an open source project releases their software under a copyleft license, the author is given a guarantee that any derivative work of their software will also have a copyleft license. This aspect essentially turns copyleft licenses into a “viral license” in which all derivative works of an original open source project are “infected” and authors and users must adhere to the original license. Examples of widely-used copyleft licenses include the GNU General Public License (GPL).

“Weakly-protective” licenses exist as a compromise between the permissive and copyleft licenses. Weakly protective licenses generally prevent the licensed source code from becoming proprietary on its own, yet allow such source code to be incorporated as part of a larger proprietary program. Examples of widely-used weakly protective licenses include GNU Lesser General Public License (LGPL).^[7]

Case Law Involving OSS

In one of the first major cases involving an OSS license, Jacobsen v. Katzer, the United States Court of Appeals for the Federal Circuit (CAFC) ruled that an open source “Artistic License” to copyrighted program code for controlling model trains was enforceable and the underlying copyright was infringed.^[8] Furthermore, the CAFC held generally in Jacobsen that copyright holders who engage in open source licensing have the right to control the modification and distribution of the copyrighted material.^[9]

More recently, in Artifex Software, Inc. v. Hancom, Inc., the Northern District of California cited Jacobsen as a basis to establish that royalty-free licensing under open source conditions does not preclude a claim for damages with a decision that stated a “jury can use the value of the commercial license as a basis for any damages determination.”^[10] Additionally, in Artifex, the district court ruled that GPL-licensed code can be treated like a legal contract, and developers can sue if the obligations of these licenses are not followed.^[11]

Such decisions have supported the enforceability of OSS licenses and suggest that potential copyright infringers ignore the terms of such licenses at their peril.

OSS and Patents

In the United States, OSS can be protected under both copyright and patent law. Whereas copyright protects the underlying expression of source code (i.e., the originality and creativity underlying the way the source code is written), patents can protect the source code’s functionality and the utility and/or design in which it influences the outside world. Because OSS licenses grant user rights under copyright, open source licenses do not inherently bar an original author (or a secondary author using the source code provided by the original author) from obtaining protection on patentable aspects of the source code.

However, in light of the decisions described above, why would one want to obtain a patent on OSS or derivative software that carries a corresponding OSS license? As an example, an original author may desire to assert patent rights against infringers who are not using OSS subject to the OSS license, but different, independently created, software that is nonetheless infringing the author’s patent right. Accordingly, a patent holder could potentially assert patent rights against an infringer who uses independently-developed software that utilizes a patented concept, regardless of whether the source code is subject to an open source license.

Additionally, the original author may desire to market or provide a non-open source licensed version of a software product, such as many dual-license software products.^[12] For example, such software products may be released under a proprietary license and an open source license. The open source version can be provided for free, with the aforementioned caveat that any subsequent product using the software must include the open source license. The proprietary version may be sold to businesses looking to incorporate the software into their own proprietary products.

In an effort to protect contributors from such legal discrepancies between copyrights and patents, many open source licenses have explicit clauses that address would-be patentees. For example, the GNU GPL^[13] explicitly states:

You may not impose any further restrictions on the exercise of the rights granted or affirmed under this License. For example, you may not impose a license fee, royalty, or other charge for exercise of rights granted under this License, and you may not initiate litigation (including a cross-claim or counterclaim in a lawsuit) alleging that any patent claim is infringed by making, using, selling, offering for sale, or importing the Program or any portion of it.

In such cases, under the purported terms of the license, an inventor who distributes source code under the GNU GPL cannot assert her own patent rights against subsequent users of the GNU GPL source code.

In a further effort to deter would-be patentees, some open source licenses include clauses that terminate a licensee’s rights to use the OSS if the licensee asserts a patent infringement claim relating to the use of the OSS. Such provisions are often referred to as “patent retaliation clauses.” As an example, Section 8 of the Apache 2.0 license states:^[14]

If You institute patent litigation against any entity (including a cross-claim or counterclaim in a lawsuit) alleging that the Work or a Contribution incorporated within the Work constitutes direct or contributory patent infringement, then any patent licenses granted to You under this License for that Work shall terminate as of the date such litigation is filed.

Due to the complexity of modern software projects, patent holders may be completely unaware of OSS embedded into their systems. Accordingly, such patent retaliation clauses can become a substantial risk for patentees intending to assert their software patent. For example, suppose that an enterprise constructs a product that is a derivative of software covered by an open source license with a patent retaliation clause. Then, suppose that the enterprise obtains a patent on the features they added to the derivative work. If the enterprise sues a third-party for patent infringement, the license to distribute the enterprise’s own software (a derivative work of the original software covered by the open source license with a patent retaliation clause) could be revoked under the terms of the OSS license because the enterprise asserted their patent on their derivative work. Under such a hypothetical scenario, the enterprise who merely attempted to assert their patent right may lose the right to distribute their own product.

The Future of OSS

OSS has created enormous value throughout the software industry. One open source project’s success has become the bedrock of another project’s innovation. However, for the OSS model to continue, viable business models must exist to reward creators and maintainers of OSS.

Currently, the software industry is experiencing a shift towards a software as a service (SaaS) paradigm. Above all, the shift has ushered in the era of cloud providers: large organizations who offer computational resources to run the software in production environments. With this paradigm, owning hardware, not software, becomes the engine of wealth creation. So, rather than paying a maintainer of an open source project, the price of using OSS is now more closely tied to the price of paying a cloud provider to execute the OSS. For this reason, many cloud providers are now “open source friendly” (and even belong to a non-aggression Open Invention Network^[15]) because they directly benefit from the use of OSS in their cloud environments without having to bear any of the engineering costs of maintaining or upgrading the OSS. However, the open source authors do not directly benefit and typically rely on revenue from “enterprise tier” infrastructure solutions to fund operations and the continued development of OSS.

Many organizations are creating specialized open source licenses to address these issues. MongoDB, a database software company that “open sources” most of their products, has shifted to a Server Side Public License (SSPL)^[16] to exclude cloud providers. Specifically, the SSPL requires that those who provide an SSPL product in a hosted platform must also make available their infrastructure code for the hosted platform available under an open source license. This infrastructure code would include things such as provisioning systems or anything that might be required for another company to create a clone of the hosting service. Similarly, Redis Labs, another database software company, has shifted to the Redis Source Available License (RSAL), which precludes Redis software from being used as a database, a caching engine, a stream processing engine, a search engine, an indexing engine, or a machine learning/deep learning/artificial intelligence serving engine. ^[17]

As the dominance of cloud providers continues, we can expect to see more new open source licenses that focus on fair compensation for the creators and maintainers of OSS.

Conclusion

OSS has evolved to fit the various and disparate needs of the technology industry. OSS licenses have provided a way for its authors and innovators to control how the OSS will be used in the future. With only a few court cases decided relating to OSS licenses, this will be an interesting area of law to follow moving forward.

Additionally, the rise of cloud providers has drastically changed open source models for many technology companies. With the next waves of technological change coming along soon, such as autonomous vehicles, Blockchain, and IoT, newer, more complex open source licenses may be drafted, and argued in the courts, to protect the interests of software innovators and the OSS community.

[1] Brian W. Carver, Share and Share Alike: Understanding and Enforcing Open Source and Free Software Licenses, 20 Berkeley Tech. L.J. 443, 443 (2005).

[2] Id. at 447; see also What is GNU?, GNU Operating System, https://www.gnu.org/home.en.html (last updated May 7, 2019).

[3] See Carver, supra note 1, at 449; see also The Open Source Definition, Open Source Initiative, https://opensource.org/osd (last updated Mar. 22, 2007).

[4] The MIT License, Open Source Initiative, https://opensource.org/licenses/MIT (last visited May 23, 2019).

[5] Apache License, Version 2.0, Apache, https://www.apache.org/licenses/LICENSE-2.0 (last visited May 23, 2019) (hereinafter “Apache License”).

[6] The 3-Clause BSD License, Open Source Initiative, https://opensource.org/licenses/BSD-3-Clause (last visited May 23, 2019).

[7] GNU Lesser General Public License, GNU Operating System, https://www.gnu.org/licenses/lgpl-3.0.en.html (last updated Nov. 18, 2016).

[8] Jacobsen v. Katzer, 535 F.3d 1373, 1381 (Fed. Cir. 2008).

[9] Id.

[10] Artifex Software, Inc. v. Hancom, Inc., No. 16-CV-06982-JSC, 2017 WL 4005508, at *3 (N.D. Cal. Sept. 12, 2017).

[11] Id. at *6.

[12] Multi-licensing, Wikipedia, https://en.wikipedia.org/wiki/Multi-licensing (last updated Feb. 8, 2019).

[13] GNU General Public License, GNU Operating System, https://www.gnu.org/licenses/gpl-3.0.en.html (last updated Nov. 18, 2016).

[14] See Apache License, supra note 5.

[15] Members, Open Invention Network, https://www.openinventionnetwork.com/about-us/members/ (last visited May 23, 2019).

[16] Server Side Public License, mongoDB (Oct. 16, 2018), https://www.mongodb.com/licensing/server-side-public-license.

[17] Redis Source Available License Agreement, Redis Labs, at 1 (Mar. 20, 2019), available at https://redislabs.com/wp-content/uploads/2019/03/Redis-Source-Available-License-PDF-2.pdf.