Today there is a lot of misunderstanding and confusion about what uses of GPL’d software might compel a company to open source their software. Having run into this issue at Disney, Sony and several startups, this article is meant to clarify my own understanding as well as hopefully help a few others make informed decisions. Please note that I am not a lawyer and this article must not be relied upon as a substitute for reading the GPL and obtaining specific legal advice from a licensed attorney.
While there are many less restrictive licenses (MIT, BSD, MPL, etc.) the GPL is perhaps the least understood and most feared by business. To an extent this confusion shouldn’t be a surprise. The FOSS ( Free and Open Source Software ) movement is made up of an array of activists that have slightly different ideals. Since to an extent law relies heavily on intent and consistent treatment, the inconsistencies in this approach muddy the waters. When over time the leaders of the movement make contradictory statements regarding the scope and intent to the GPL, this injects Fear Uncertainly and Doubt (FUD).
Making matters even more confusing, copyright law is also in sad shape in relation to basic tenants that the GPL relies. For software, what constitutes Fair Use and Derivative works are at odds within case law. On one extreme, case law infers that a product is derivative even if you have copied no code from the system it interacts with. On the other, conflicting case law infers that it is Fair Use to reverse engineer a system to utilize it without worrying being considered derivative.
Which of these precedents we think will play out is potentially random and depends a lot on the way we use the code. Without explicit exclusions set down from developers we have to go back to the intent of the authors of the license itself. In this case the Free Software Foundation specifically spells out its beliefs. In their interpretation of the GPL your program IS derivative if you include GPL code or link to GPL code in any way (dynamically or statically).
There are several acknowledged exceptions to this rule such that your program may NOT be considered a derivative work.
- You may dynamically link against a standard interface where other existing libraries may be substituted.
- You may execute a GPL program via fork() or execute().
- You may communicate with a program via standard network and IPC mechanisms.*
- You may distribute your program and a GPL program in aggregate (on the same medium) provided they are still represent separate programs and the terms of the GPL are observed.
These exceptions give us enough rope to use GPL’d programs and libraries in conjunction within a larger closed source systems. On top of these some developers may add additional explicit exceptions like allowing dynamic (LGPL) or static linkage. In some cases it may also be possible to contact the developers and negotiate a closed source license that removes the limitations of the GPL all together.
There is one other notable loophole. The GPL only kicks in when you distribute the derived program. If you do not distribute a derived program to people outside your company you do not have to distribute your closed source. You may even use GPL derived software as a service and charge money for it without releasing any code.
In practice this loophole does have a couple gotchas. The first is that you cannot sell or give the derived program to another company or person. The second that many do not consider is that during some M&A transactions the company is selling the assets rather than merging the companies and selling the assets may also be considered a distribution.
Of course as with any software your license (FOSS or commercial) you should be cognizant of the patent issues, indemnification, additional license restrictions (e.g. GPL3 restricts DRM) and the total cost of ownership related to maintenance and support. As with anything we do as companies there is more to the bottom line than the price tag coming in the door.
The other thing to consider is the perception of the public and the FOSS movement. You are using FOSS software and the implied contract is that you will participate in the community and contribute improvements. It is not enough to use FOSS, you should adopt a policy that states how you use FOSS and how you support it. Working with FOSS developers and being a good citizen goes a long way.
References:
http://www.gnu.org/copyleft/gpl.html
http://www.gnu.org/licenses/old-licenses/gpl-2.0.html
http://www.gnu.org/licenses/old-licenses/lgpl-2.1.html
http://www.fsf.org/licensing/licenses/gpl-faq.html
http://www.bu.edu/law/lawreview/v85n5/Stoltz.pdf
http://www.linuxinsider.com/story/38089.html?welcome=1202601329&welcome=1202602307
http://en.wikipedia.org/wiki/Free_software_licenses
http://en.wikibooks.org/wiki/FOSS_Licensing/Scenarios
As someone recently pointed out on a mailing list, the GPL seems very arbitrary in that you don’t have to distribute your source if you provide a service, but you do if you provide a product. In other words, the GPL promotes software-as-services over software-as-products.
Why should someone creating software with an XML-RPC interface get to keep their mods private while someone distributing a library be forced to reveal their mods?
Hi Chuck,
Looking at it as an outsider I think there are a number of factors.
1) The GPL seams to be designed to redefine the roles of programmers from IP producers into service providers. With client software the service is simply a different model (consulting, customization etc).
2) It is harder to enforce on the server. It would be simple to hide the use of GPL’d software.
3) Not allowing software to be monetized as a service limits the products adoption.
In a nutshell limiting GPL’d softwares use as a service would limit its adoption, utility and enforceability. Also remember that the owner of the GPL’d software can dual license the product and is therefor not bound by the GPL.
While I do use some GPL’d software, I prefer much less restrictive and viral licenses, even as a service. Each use of software, commercial or FOSS, requires some due diligence to determine fitness and total cost of ownership.
There are many factors that lead to the success or failure of an FOSS project, the license is one of the elements that can add friction for adoption. We are already seeing a division and duplication of effort as a result of license requirements. It will be interesting to see how each license competes.
-Marty