In previous chapters we have learned a bit on GPL virality exemptions or safe harbors. As you may recall, the “identifiably independent and separate software” and the “aggregation exemption/immunity” exemptions provide some comfort, intermixing copyleft licensed code with non-copyleft code. This article will explain the limits and rules to mixing copyleft and copyrighted code.
Intermixing Boundaries
The GPL virality exemptions are applicable mostly to cases of non-GPL software calling GPL software during runtime, rather than code mixing during the development/compilation stage. The detachable and independence conditions are clearer in a scenario where the GPL and closed source code are “stored” in separate libraries/containers. The GPL virality clearly does not apply to scenarios where the GPL code and closed source code interact, only through a special interface where one library is “calls” or “references” to the other. This technique is called a “dynamic-linking” whereby no real permanent connection is made between codebases.
However, if you copy a piece of GPL licensed code into your own proprietary code, you are intermixing during the development/compilation stage. This technique creates one whole container that triggers the infectious copyleft terms of the GPL, meaning the GPL would probably apply with respect to the entire container. This technique is called a “static-linking”. From a legal copyright perspective, static linking may create derivative works, even in cases where a proprietary piece of code merely uses the GPL covered library, or vice versa.
Compatibility of multiple licenses
License compatibility isn’t necessarily related only to open source licensed code, but it is relevant in particular to the GPL.
Copyleft licenses like GPL impose their terms on other non-copyleft work, but what happens when multiple incompatible licenses apply to the same work?
For example – suppose a license has a restrictive provision that says you have to display an acknowledgment accompanied to the original source in all advertising material that you distribute. What will happen to this license term if one distributes such software, in conjunction with other software that is covered under GPL, which prohibits further restrictions?
The licensing downstream provisions of the GPL (Section 10 to be exact), dictates:
“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…”
So GPL actually prohibits additional restrictions, and via its viral copyleft effect it further limits one’s ability to add such restrictions to third party’s software, which was not originally intended to be licensed under GPL. This results in a breach of both licenses: first, a potential breach of the non-GPL – since removing the acknowledgment in our example above is prohibited, and second, of the GPL – since adding such acknowledgment would be considered as a breach of the “no further restrictions” clause.
For example – the BSD-4 Clause license is considered as non-compatible with GPL as it contains what is known as the “advertising clause” (clause 3):
All advertising materials mentioning features or use of this software must display the following acknowledgement: “This product includes software developed by the <organization>.”
Compatibility is important because it allows synergy, not only between open source code and proprietary software, but also between different open source licensed code.
So, freedom aside, incompatibility makes it legally prohibited to mix components of software that are released under incompatible licenses.
As a side note, we would mention that up until its third version, the GPL was hardly compatible with other licenses that did not “belong” to the same “family” of GNU public licenses, but the latest GPLv3 allows combinations with code subject to additional terms, listed in the license as “Additional Terms” (Section 7)
Virality and Commutability – The Middle Ground
Licenses like the LGPL (Project GNU Lesser General Public License) tend to accept the fact that the GPL’s virality may sometimes be inappropriate and offer a compromise. Instead of gross attempts to impose the share-alike license terms over other portions of the work, these licenses are more permissive of use by closed source developers. This “compromise” also enables compatibility between different types of open source licenses.
The LGPL allows linkage between libraries with less of a “viral” effect than that of the GPL. By using “dynamic” or “static” linking and meeting certain terms, one can use an open source library licensed under certain versions of the LGPL in a closed source project. These technical and legal separations allow open and closed source code to work together without imposing open source requirements on all the code.
Further discussion of LGPL Virality Exceptions
The LGPL has both the “aggregation” and the “identifiably independent and separate software” exceptions basically also offered by the GPL (further elaborated above), but it also provides for one additional safe harbor – “use of the software as a library”. This exception was designed to allow for software intermix in both runtime and the development/compilation stage without triggering the infectious terms of the license.
Section 5 of the LGPLv2:
“A program that contains no derivative of any portion of the Library, but is designed to work with the Library by being compiled or linked with it, is called a “work that uses the Library”. Such a work, in isolation, is not a derivative work of the Library, and therefore falls outside the scope of this License.”
Note that the exception given by Section 5 is not determinant and Section 6 of the LGPLv2 set forth a list of conditions for such exception to apply.
If you are using LGPLv3 code, then Sections 4 and 5 list the terms and conditions for code intermixing.
SaaS, Cloud Computing, and the ASP Loophole
As briefly discussed in previous sections, the penetration of the Internet has allowed for the establishment of new business models for software developers. As VoD (video on demand) changed the film and television industries, SoD (software on demand) – or in more commonly used terms, SaaS (software as a service) and generally cloud computing – has now changed the way people use and pay for their software and the way developers design their products in terms of support, maintenance, and scalability.
Let’s talk some more about SaaS. Many mistakenly consider SaaS to be a new method for software licensing. In fact, the provision of software as a service does not mean that one licenses software to the other – it actually means that one grants the other the right to use a service. You can read more about it here.
With SaaS, a customer will get a service, not software. The user does not receive a license for any software; they only receive access to the service provider’s interface.
The service – for example, Google’s Gmail service – is provided via the hardware and software stack of the service provider itself. The end user doesn’t obtain any rights to Google facilities, nor does he get any rights to the source code or compiled version of the software running the service. The differences are not obvious, hence the confusion, but when it comes to open source non-permissive copyleft implications – these differences have deep meaning and extensive implications.
In the software industry, granting the right to use, rather than a license, means granting the right to access. Simply put, this means that Party X – the owner of the software, allows Party Y – the client, to access and use the software hosted and installed on Party X’s (or on a third party’s, of course) remote servers. Beyond the enviable position of hosting all of your software in one place (allowing faster bug fixes, security, and performance upgrades, and scalability, etc.), it means that there is essentially no distribution of the software. No distribution of modified source code may mean no virality mandating publishing of the proprietary changes. Going back to open source politics, this advantage, or disadvantage (depending on whom we ask), is called the application service provider loophole – in short, the ASP loophole.
Several language issues of open source licenses complicate the principle that using open source code on a SaaS platform resolves virality issues and sometimes simplifies compatibility issues. For example: can we consider the deployment of our product on a third party’s servers to be distribution which would mandate distributing all the code? Circumstances, and mostly the specific license we use, will dictate our answers to this and other questions. It is safe to generalize that in many cases the ASP loophole has allowed better synergy between different types of code licenses and an exemption for virality issues.
Obviously, copyleft ideologists are not big fans of the use of open source on SaaS and consider it to be abusing and restricting freedom. You can read more on this approach toward SaaS here. The most effective tool developed by such ideologies to cope with the ASP loophole challenge is a license called the Affero General Public License (AGPL).
AGPL
Established on the basis of the GPL, the AGPL was designed to close the perceived ASP loophole, whereby, the use without distribution of software does not trigger the viral copyleft provisions of the open source. Versions 2 and 3 of the AGPL are based on versions 2 and 3 of the GPL, with an additional provision addressing the use of software over a computer network. This additional provision requires that the source code be made available to any network user of the AGPL licensed work. Obviously, using AGPL licensed libraries can prove to be difficult for SaaS companies.
Section 13 of the AGPLv3:
“Notwithstanding any other provision of this License, if you modify the Program, your modified version must prominently offer all users interacting with it remotely through a computer network (if your version supports such interaction) an opportunity to receive the Corresponding Source of your version by providing access to the Corresponding Source from a network server at no charge, through some standard or customary means of facilitating copying of software. This Corresponding Source shall include the Corresponding Source for any work covered by version 3 of the GNU General Public License that is incorporated pursuant to the following paragraph.”
Epilogue
Open source holds a great opportunity for companies and individuals. Open source licenses have democratized and decentralized access to world-class software in a revolutionary way. This revolution born from private individuals sharing their code freely has grown rapidly to be significant to even the biggest corporations. The future of open source is promising, as a growing number of open source projects are being developed by companies and individuals. We can all expect more revolutionary changes to come from open source software movements, not only from the technological front but also on the legal and commercial ones.
