There’s plenty of confusion around the differences between the various open-source licenses and the use-cases for each. Let’s discuss those differences for a bit and also see how commercial open-source licensing comes into play.
Note: This is not intended to be a comprehensive of open-source licenses, but only of the differences that are meaningful for most people.
Copyleft – Licensing Virality
Viral licenses (also known as copyleft licenses) only allow derivative works – modifications and redistribution – under the original license. That means that if you modify or include code that is under a viral license in your code, you have to redistribute those modifications under the original license, thereby “infecting” it with the license (hence, viral). The most common example of a viral license for code is the GPL license. Note that this only applies if you are distributing your work (as an application or as the source files). If you use it for internally only, there is no problem.
This property is not limited to code, the Creative Commons Sharealike license is viral for copyrighted content in the same way as GPL is for code.
Attribution and copyright notice
Some licenses require a copyright notice to the author be present in all the source files. Some go even further, requiring specific attribution to the copyright holder when the code is used for a commercial or promotional purpose. Licenses that exhibit this property include some versions of the MIT and BSD licenses.
License compatibility
One of the freedoms offered by some open-source licenses is the ability to sublicense the code to other people (under the same or a different license). The GPL license explicitly does not allow sublicensing to a different license, while the BSD does not mention it specifically – which leaves it open to interpretation and could be problematic, legal wise.
The MIT license does specifically grant the right to sublicense MIT licensed code, making it one of the more permissive licenses.
When discussing the inclusion of code with different licenses in the same project, it’s important to note the compatibility of the different licenses with each other, with regards to sublicensing.
For example, if you have MIT licensed code and you want to license your modifications of that code under GPL – that is completely fine, as the MIT is compatible with the GPL. The reverse is not true however, as modifications to GPL’ed code must be released under GPL as well.
Dual and commercial licensing
It’s important to note that all of those restrictions apply to license holders and not to the copyright holder. The copyright holder has the option of licensing his code under as many (and not necessarily compatible) licenses as a he sees fit.
That is the basis of dual licensing, a model used by MySQL and Magento to great effect for building profitable, sustainable businesses. Typically, a copyleft license is used for a free, community edition, and a commercial license is used for a so-called “enterprise” edition. In some cases, the commercial license is actually more permissive than the free license (we’re talking “free” in the sense of cost here, not freedom) – because it allows modifications and sublicensing not allowed by the copyleft license. For this reason, a GPL license is commonly used in a “freemium” model such as that of MySQL and Magento.
In other cases, a commercial license allows the licensing party to remove copyright and attribution from the code, which is a very viable use-case. We’ve had a couple of publishers add a commercial license on Binpress for that exact purpose – clients needed a license that allowed them to remove those copyright notices required by an MIT license.
Dual and commercial licensing provides the groundwork for the basic business model of open-source projects. The commercial licenses support continued development and professional support, increasing the sustainability of open-source.
Binpress Licenses
Licensing is a part of the umbrella of services we provide on Binpress to help developers build a profitable open-source business. We have two main variants of licenses – sublicensable and non-sublicensable.
We typically call the sublicensable licenses “developer” licenses (though you might find a few projects terming it as “distributor” licenses), and those allow free redistribution of the source-code under any license. This is useful for developers building applications for 3rd parties (and thus needing to sublicense the code to them), or people building a product where they need to distribute the code as well (such as an SDK or a library).
The non-sublicensesable licenses deal in more limited use-cases – either building a website or service, or building a compiled application. Those limit the usage of the code in those scenarios – either for hosted usage, or for binary (compiled) redistribution only – in application form. Those licenses typically cost substantially less than the developer licenses, and accommodate developers who do not require the ability to sublicense.
There are a few other freedoms that can be adjusted depending on the business needs of the developer and their sharing philosophy – including whether to allow commercial use (typically, yes), whether to include guaranteed support (and for what duration), whether to require attribution in specific cases and so forth.
Aside from the licensing options available to our marketplace publishers, we also provide an external license generator that can be used by anyone for any project they may have.
There you have it – licensing for dummies
I hope this post helped answer some of the questions you had regarding free and commercial open-source licensing. If you have other questions not covered above – ask it in the comments and we’ll do our best to answer.
Author: Eran Galperin