Part one of this series provided an intro to open source licensing. Here I will dive into the spectrum of licensing options available to you and how they can be combined.
Open source licensing is a continuum.
On one end of the continuum is public domain. Just to the right of the public domain are permissive licenses like MIT and BSD. The solid middle ground of software licensing is protective, the most common of which are the GPL and Apache licenses. Even within the released versions of those licenses, there are important distinctions that put them on a continuum with each other. The GPL is decidedly Copyleft—meaning it has provisions to ensure that people contributing to it license the derivative work as GPL as well.
Just to the right of protective FOSS licenses are freeware or shareware licenses that were wildly popular ways to pass on desktop applications for a time but have faded as other licenses become more common. Proprietary licenses fall solidly on the most conservative edge of the license spectrum. There is no further to go after proprietary than keeping the software a trade secret.
Where do patents come in?
It gets a little more interesting when you consider what copyright does not protect.
In no case does copyright protection for an original work of authorship extend to any idea, procedure, process, system, method of operation, concept, principle, or discovery, regardless of the form in which it is described, explained, illustrated, or embodied in such work.
That provision is where we get into patent law and the protection of intellectual property. Patents can’t really be applied to just an idea. Patents can only be applied to the description of a tangible object in order to protect that object from creation or distribution by others.
Patents come into play with software when the software is integrated into the object/device/machine being patented. Some licenses have patent clauses that explain contributors rights to use the patent for the purpose of development without giving up the right to protect the final product.
While challenges to open source license precedent are rare, one area where there has been a ton of review and interpretation is compatibility. The language of a license can naturally lead to a conflict with another license if works are combined into a derivative. Nearly all compatibility concerns have to do with the distribution of the final software derivative.
In general, permissive licenses (MIT, BSD) can be combined into more protective licenses (LGPL, GPL) with the derivative getting licensed as a whole under the more protective free open source software license. There are even licenses especially designed to allow for a derivative that is a combination of proprietary and protective open licensing. The LGPL is a good example of this compromise to help protect business interests while still open sourcing significant libraries used within a larger framework.
A couple of important exceptions to compatibility pattern can be seen in combinations such as Apache2 (a permissive license with wording to protect patent use) and the GPL version 2 (a strongly protective license). These two licenses have conflicting clauses that make them incompatible with each other.
Some of the biggest open source projects (Drupal, WordPress, Linux) have gotten around this incompatibility by using the GPLv2, but expressly stating that it is okay for the project to be combined with any later version of the GPL for distributions. This is sometimes referred to as GPLv2+ or GPLv2 and later. Do not let the common names for this confuse, those projects are released as GPLv2.
Why choose a license from 1991?
The second version of the GPL was released in 1991. That is forever ago in technology years. It was one of the first and most important “copyleft” licenses. Copyleft is the protective part of the GPL. It has intentional provisions to force the resulting distribution to be free and open source. That makes it very opinionated.
The GPLv3 was released in 2007—still an eternity—but it was intentionally written to be compatible with software that is GPLv2 or Apache2 that is being combined into a GPLv3 licensed derivative. This sounds great, but as a result of the GPLv3 being fiercely protective and Copyleft, many lawyers and companies are hesitant to introduce this license into derivative works in their software portfolio.
WordPress and Drupal both predated the Apache2 license (released in 2004), and chose to keep the GPLv2—which was chosen based on the Linux kernel’s license of choice. The result is that if you want to host a Drupal module on Drupal.org or a WordPress plugin on WordPress.org, you are releasing that module under GPLv2. That means the combined code for the module could include libraries that were licensed under more permissive licenses, such as MIT, but those libraries cannot be either Apache2 or GPLv3 as provisions in those licenses are incompatible. Technically, you could create a derivative of Drupal or WordPress and some related modules or plugins that were GPLv3, but you would not be able to host them in the repositories those projects host. Complicated, eh?
What have composer and NPM done for compatibility?
Both NPM (node.js) and Composer (PHP) provide some compatibility checking by allowing projects to clearly identify their license.
Further I would argue, and here is where you should stop trusting me and talk to a lawyer, that a composer.json or package.json requirement does not represent distribution since the code is not packaged into a combined tar or zip. Rather, those files are combined on the server via scripts that request the packages separately assembling the final package. Therefore the final product running on the server would not constitute a derivative since it will not be distributed.
I could be wrong in my interpretation, and I encourage legal feedback, but if project requirements represent “a derivative” that can be “distributed” then much of the open source world is out of compliance with a great many implementations of open source that are defaulting to the most protective license—likely GPLv3.
I work with a lot of free open source software; the value does not come from the code but from the services provided on top of that code. However, incompatible combinations do leave corporations exposed to possible lawsuits. Consult a lawyer to review your licensing and options if you are concerned.
Up next in part three, I’ll provide some guidelines to help you choose the licensing option that fits your specific needs.
This topic is complicated. I’m offering up my research, but also need to offer up the following disclaimer. I am not a lawyer. I am a technologist. While I have a pretty extensive history in using and participating in open source projects, this work should not be taken as legal advice. That said, I do not think just any lawyer will do to help you decipher your open source licensing needs.
If you are truly interested in the legal ramifications of a software licensing decision you need to make, consult with a lawyer that specializes in copyright, intellectual property, and software law. Further, software licensing and the related laws differ from country to country based on the legal systems present. Make sure your legal advice comes from someone that knows law that covers your type of software. Software licensing for devices, particularly networked devices, differs significantly from web and service software, the focus of this post.