GPL or not to GPL
11/1/2011 / By Derek Jones
In the free software world, that is often the question.
The content in this article is neither legal advice nor a legally binding interpretation of the licenses discussed, including those distributed with EllisLab products. We are sharing our opinions, thoughts and conclusions which we hope are helpful and spark meaningful discussion. You should consult an attorney with questions regarding your specific legal needs and the terms or interpretation of any software license.
The GPL is typically a very polarizing software license. It has promoters and detractors, with few who are non-committal. Full disclosure, EllisLab is not a fan of GPL, and this article is going to reflect that opinion. That said, we respect every copyright holder’s right to choose the license that they want to use for their work. So the purpose of this article is not to persuade you to adopt our view of the GPL, but to explain our conclusions, and perhaps even educate our communities on the proper use of the GPL, as it is often misapplied and misunderstood.
Ambiguity
This is one of the problems we see with the GPL - its loose wording and use of technical jargon gives the appearance of being developer friendly. But in actuality, both of these are problematic because of one of the conclusions we shared yesterday: "...it will be a judge or ruling copyright authority…that will interpret and render a judgement".
Copyright lawyers and judges who hear copyright cases often aren’t familiar with the technical jargon employed in our industry, and combined with the loose wording it seems to serve to leave room for a wider range of interpretation by legal authorities.
For instance, there is much ambiguity surrounding when code of independently written software relating to GPL code must be disclosed or not. Many paragraphs are spent in the GPL regarding source code obligations, and debates crop up continually over details of static and dynamic linking, whether linking is at issue at all, and how software works with other software.
Looking at the lawsuits that crop up regarding GPL is a testament to that fact, including some with outrageous conclusions, like the one reached by some lawyers in Mauritius that GPL software has no copyright restrictions and that derivative works transfer the full copyright and ownership of the code to the one making the derivative work.
Obviously, we don’t believe that the GPL does that, but the fact that lawsuits are reaching Supreme Courts with such extreme claims intact draws into question whether or not the GPL is actually effective at accomplishing its noble goals.
Speaking of those goals, note the GPL Preamble, which lays out the philosophy of the license, but is itself not included in any of the legally binding portion of the license (Terms and Conditions). This can add to the confusion of the license, particularly if people quote GPL restrictions from the preamble.
As an addendum to yesterday’s post, it’s noteworthy to point out that the Licensor’s and Licensee’s understanding of a license between themselves will carry weight in a courtroom. The opinions of the author of the license have no bearing, unless he also owns the copyright to the software in question. This is why we saw it unwise to rely on the Free Software Foundation (FSF) to interpret the GPL, and certainly not other licenses. Unless you’ve yielded your copyright to them (they recommend that you do!), they do not have a stake in the application of the license between you and your licensees.
Copy-Forward
Another aspect of the GPL that we find onerous is what is commonly referred to by developers as the "viral" nature of the license. Let’s call it "copy-forward". That when you incorporate GPL software into a package, the whole package must be distributed as GPL. This goes beyond copyright law in that forming collective works from copyrighted material normally does not constitute a new, derivative work.
Copyleft is helpful. Copyleft is a term used to describe a method for making some work free, in this case software, and requiring that all modified versions of that work be free as well. It works to ensure that free software remains free as it grows and gets patched. This is an area that we agree with the philosophy of the GPL.
Copy-forward, though seems less helpful. It creates an "island of software" whose reach goes beyond simply keeping that software free. Why should free software care what license other free software uses so long as both are guaranteed to remain free?
Commercial Limitation
It is technically true that the GPL does not forbid the sale of GPL software, but it undoubtedly limits the options a company has to monetize their own endeavors. GPL software does not work well in a product based model whereas it more easily can in a service model. There’s no problem with the latter if that’s the type of business you want to build, but why limit enterprise in such a restrictive way?
This is a good time to interject an answer to the question that has come up of whether or not ExpressionEngine or MojoMotor would be OSL because CI is OSL. The same question could be raised of whether or not a copyright holder of GPL code could use that code in a commercial application without applying GPL to the commercial application.
The answer goes back to a conclusion brought out yesterday: "...the copyright holder still owns the work, and retains a right to license it how they choose". Your granting of certain rights to others does not take away your own rights to your own works. In practical terms it means that even if OSL were a viral license (it’s not) that latched on to a licensee’s independently written code, the licensor still owns his own code and can use or license it however he/she sees fit. The Licensor is not bound by the license granted to licensees. Even if CodeIgniter were GPL, EllisLab, as the copyright owner of CodeIgniter could still use CodeIgniter without the GPL license as part of ExpressionEngine, MojoMotor, etc.
The same is true with your own code. You own the copyright, and you decide how your code is licensed in a CodeIgniter application. Unlike the GPL, OSL does not demand that you license your code in any specific way, nor that you even disclose your own source code. So you can sell or give away your CodeIgniter applications without any conflict with OSL. In fact, you could choose to license your independently written code as OSL, give it away for free, and turn around and sell that same code with a closed commercial license. It’s yours. The popular ecommerce platform Magento is in fact licensed this way. The community version is OSL, and the editions you pay for are licensed differently. They can do that because it’s their copyright, their code. So can you. You can always choose who you grant rights to your code, and under what terms.
The only thing you are obligated to license and make available under OSL are modifications you have made to the OSL-licensed CodeIgniter files, which can be clearly identified in their attribution notices (more on this in a bit).
Patents
GPL also seeks to restrict the use of software that contains patents. Here is one area where we again agree with the GPL’s basic philosophy (patent proliferation and litigation is bad) but disagree with how it attempts to solve it. §11 of the GPL is all about patents and is 8 paragraphs long. Compare that to OSL 3.0 which contains two sections dealing with patents, but in a total of four sentences.
Instead of restricting patent use, we prefer the OSL 3.0’s take - that like it or not, we live in a world of patents, so we need to make sure that licensees have rights to use any included patents, and that everyone should have a measure of protection against patent lawsuits. OSL 3.0 handles this with an explicit grant of patents embodied in the original work to the licensee, and an immediate termination of the rights granted by the license when a lawsuit is initiated over a patent.
We will touch again on our conclusions regarding patents on Wednesday.
Trademarks
In order to retain strong protection of your name and trademarks, you must supplement the terms of the GPL as it states in §7d and §7e:
...you may…supplement the terms of this License with terms…
d) Limiting the use for publicity purposes of names of licensors or authors of the material; or
e) Declining to grant rights under trademark law for use of some trade names, trademarks, or service marks; or
You would need to provide in a clearly documented way that you are declining to grant rights to your trademark names, otherwise these are not expressly protected by the GPL.
Which raises an interesting question. If you do not supplement these terms for §7e, what happens if one of your licensees does? Did you inadvertently pass your trademarks on to them, suddenly making them the owner? Would you then have to change your own product’s name because someone downline asserted that right? It doesn’t seem logical, but with the GPL, again, look at what absurd claims have already made it before the courts. Just the thought of being embroiled in such an entanglement should be motivation enough for someone adopting GPL to put forth appropriate effort ahead of time to protect their trademarks.
So you can see why we are attracted to the importance that OSL places on warning licensees that your brand names and your reputations are not included for free with your copyright licenses.
Neither the names of Licensor, nor the names of any contributors to the Original Work, nor any of their trademarks or service marks, may be used to endorse or promote products derived from this Original Work without express prior permission of the Licensor…No license is granted to the trademarks of Licensor even if such marks are included in the Original Work.
FSF and FUD
Only related to the GPL in terms of the reach of its politics, the Free Software Foundation itself has a heavy-handed stance on other copy-left licenses, particularly OSL. Their website even contributes directly to some particularly strong fear-mongering (notice the name of the anchor link “OSLRant” when you click through):
Recent versions of the Open Software License have a term which requires distributors to try to obtain explicit assent to the license. This means that distributing OSL software on ordinary FTP sites, sending patches to ordinary mailing lists, or storing the software in an ordinary version control system, is arguably a violation of the license and would subject you to possible termination of the license. Thus, the Open Software License makes it very difficult to develop software using the ordinary tools of free software development.
This statement by the FSF has led many to conclude that OSL software cannot be developed in an open way, and that even hosting the project on GitHub or using source control immediately terminates the license. This is flatly not true. Larry Rosen, the lawyer who wrote OSL went as far as to say that "this is more hogwash from the FSF".
It’s not fully clear why the FSF would make such a strong assertion when the OSL obviously doesn’t contain anything of the sort. It asks for "reasonable efforts" to obtain express assent. It does not demand a particular mechanism, there is no requirement to click-wrap, shrink-wrap, or obtain signatures. Having the license in the README, as a file in the main directory of the repo, in the product’s documentation, and on the GitHub homepage all seem like reasonable efforts to alert developers that use of the software constitutes agreement to the conditions given in the grant of license.
The fact that the change in license garnered as much attention as it did shows that developers do at least look at licensing and documentation. How someone could fork a repo on GitHub, see all of the files in their own account, make a meaningful change, and submit a pull request, all without having any idea that they are using licensed software seems a bit far fetched. If everyone were that negligent, no one would have noticed or paid any heed to the license change.
Compatibility
Ok, this section is going to be a little painful, so please know that our goal is to educate and not to cause trouble for anyone. If you learn something from this section that impacts your work, we encourage you to take steps to assure that you and your licensees have a valid agreement.
The CodeIgniter license is not compatible with the GPL. We’re not talking about OSL 3.0 here, we are talking about the simple license we have used for CodeIgniter from the very beginning. §5 alone:
Products derived from the Software must include an acknowledgment that they are derived from CodeIgniter in their documentation and/or other materials provided with the distribution.
The GPL does not allow any additional restrictions beyond those placed in the GPL itself. The FSF refers to clauses like the above as an "obnoxious…advertising clause".
So for everyone who has been tweeting or posting that the license change is going to prevent their product from upgrading / existing / or moving forward: I’m sorry to inform you that you have probably been in violation of GPL this entire time.
In addition to revealing a large misunderstanding of the terms that the GPL places on your code, looking at some of the products that have been mentioned revealed that there’s also an apparent lack of understanding of how to clearly apply a software license in general. So we’ll take some time to help out there. After performing due diligence in researching which software license you want to use, make sure that you have actually granted the rights to your licensees that you want them to have, and have established that you have the right to do so as copyright holder.
- Two separate elements must be added to each source file of your program: a copyright notice, and a statement of copying permission, i.e. the license you are distributing that file under.
- You must include an unmodified copy of the license itself somewhere in the distribution of your program.
- If your code includes code copied from other programs, include their copyright noticies too.
- Include contact information for how to reach you.
The above list is condensed from GNU.org’s How to use GNU licenses for your own software and is echoed on their GPL violation page. But in a broad sense, these points fairly apply to any software license.
- If you are distributing software under license Foo, and are missing a Foo license file in your distribution, you need to add it.
- If you have source files within your package that are missing a copyright notice and/or a license notice, you need to add them.
- Don’t remove other people’s copyright and license notices unless they have given you express permission to do so.
- Make sure people know how to find you if they have questions.
As an example, here is the attribution notice that EllisLab has chosen for CodeIgniter using OSL 3.0:
/**
* CodeIgniter
*
* An open source application development framework for PHP 5.1.6 or newer
*
* NOTICE OF LICENSE
*
* Licensed under the Open Software License version 3.0
*
* This source file is subject to the Open Software License (OSL 3.0) that is
* bundled with this package in the files license.txt / license.rst. It is
* also available through the world wide web at this URL:
* http://opensource.org/licenses/OSL-3.0
* If you did not receive a copy of the license and are unable to obtain it
* through the world wide web, please send an email to
* [email protected] so we can send you a copy immediately.
*
* @package CodeIgniter
* @author EllisLab Dev Team
* @copyright Copyright (c) 2008 - 2011, EllisLab, Inc. (https://ellislab.com/)
* @license http://opensource.org/licenses/OSL-3.0 Open Software License (OSL 3.0)
* @link http://codeigniter.com
* @since Version 1.0
* @filesource
*/Additionally, we include full text of the OSL in a license file in the distribution (as indicated in the attribution notice), and it is also copied verbatim in the product documentation.
Make it obvious, and make sure you have applied the copyright and license grant to each source file that you mean for it to have.
Wrap Up
To sum it up, EllisLab is not a fan of GPL because of its ambiguity, viral nature, limitation of commercial opportunities, its political agenda, and its lack of respect for other software licenses.
As you can probably tell, we are not going to choose GPL for any of our own works. But we don’t hold it against anyone who chooses to do so. It’s your work, your copyright, you have the right to license it however you choose. And we respect that.
For works that we are extremely fond of we’d likely not even choose a license that allows relicensing as GPL as that could create the potential that a downstream licensee might distribute a derivative of our original work that inherits all of the problems that we see above. And we do of course realize that as lengthy as this article has been, it only scratches the surface of the issues it raises, and likely oversimplifies some issues and gets some things wrong.
We hope that regardless of your own conclusions this article has impressed upon you the importance of doing research and not being casual when selecting a license. And once you select a license, please make sure that you apply it visibly and responsibly, and in harmony with the terms of the license you’ve chosen. Any contradictions or violations you have just hurt your licensees, and perhaps yourself.
References and Further Reading
This is by no means an exhaustive list, as there are volumes of information devoted to the topic. Below are links to sources used to help form our opinions of the GPL and whether or not to use it (as well as whether or not it can be used with CodeIgniter).
https://ellislab.com/codeigniter/user-guide/license.html
http://www.itbusinessedge.com/cm/community/features/interviews/blog/rosen-gpl-is-good-but-osl-is-better/?cs=22541
http://www.rosenlaw.com/Rosen_Ch06.pdf
http://rosenlaw.com/OSL3.0-explained.htm
http://www.gnu.org/licenses/gpl-howto.html
http://www.gnu.org/licenses/gpl-violation.html
http://mail-archives.apache.org/mod_mbox/www-legal-discuss/200710.mbox/%3C047101c81328$b1affee0$6401a8c0@LROSENTOSHIBA%3E
http://www.mail-archive.com/[email protected]/msg06069.html
http://www.oss-watch.ac.uk/resources/duallicence2.xml