If you don’t know anything about open source licenses, you will probably never look at software the same way again. Licenses imply many meanings about the project and its eco-system and its a decision many developers have to make at some point in their development process.
This tutorial tries to decipher different types of open source licenses and you will find some detailed information about different licenses and their types as well.
If you are in a hurry consider checking out Github’s website about choosing a license.
Estimated Time
20 mins
Skill Level
Upper-Intermediate
Exercises
na
Posts from the Series
Course Provider
Provided by HolyPython.com
If you’re sharing your code you’ll also need a license. A license is an agreement that defines some major criteria about your program such as, but not limited to:
- who can use your code
- to what extend can they use your code
- what kind of attributions are required
- how can they use your code
- who is responsible if something goes wrong
- who can modify your code
- sublicensing
- who can resell your code or something created with it, etc. etc.
Luckily, if your code is open source there are a number of convenient and ready-to-use open source software license options that you can choose from. We take these licenses for granted but they save open-source coders and developers so much headache and legal costs.
When you decide to share your code as open source, which is an amazing thing to do, the license mostly becomes about protecting you, the developer, from the situations where something goes wrong related to your code or program.
One of the most important and significant criteria regarding choosing an appropriate open source license for your software, or also when you are working with open source software, is license being permissive or copyleft.
Permissive licenses are more relaxed in their terms and they basically allow whatever users please to do with the source code of a library, package, program or software.
Copyleft, on the other hand comes with some obligations, hence its more restrictive in this sense. It usually requires that users continue using the same license and continue sharing source code of their modified work (and also everything related to that work). But, copyleft also comes in weak copyleft form which can be a little more permissive and flexible than copyleft, yet still not fully permissive.
Copyleft Vs. Permissive
In general open source licenses fall under two categories: permissive and copyleft.
Permissive makes less demands on the user’s of the program. It doesn’t enforce derivative work or modifications, rebrandings, redistributions etc to stay under a specific license. It doesn’t require that in case of commercial adaptation the code must be shared as open source.
For these reasons permissive open source licenses are known to be more commercial friendly and less strict in general.
Copyleft on the other hand is a bit stubborn or demanding in that sense. It usually requires that code remains under the same or similar open source licenses. It can also apply restrictions in commercial use cases. While remaining open source can be a good thing, restrictions also can hurt business in long term especially if the license enforces to remain under the exact same license.
There can be cases where VC or other investors avoid work done with copyleft licenses simply because it might imply further restrictions in the future. Copyleft can also make it impossible to adopt a custom license.
Nevertheless, there are definitely room for copyleft applications in the open source world and famous license options from both sides continue to remain and co-exist.
Strong Copyleft vs Weak Copyleft
Weak copyleft is a lighter version of regular copyleft licenses. It usually has less restrictive conditions and allows some of the code the remain proprietary or undisclosed depending on the relations with modified source code.
Here is a nice a nice and detailed explanation of copyleft (or strong copyleft) vs weak copyleft from: WhiteSourceSoftware.com:
Weak copyleft licenses requires you to disclose your source on source code, but not on binaries and therefore you can compile covered sources with others and distribute the resulting (merged) binaries under the licence of your choice. With ‘strong’ copyleft license, the GPL family, you are obligated to reuse the same licence in case of re-distribution of copies or derivatives on both source and binaries.
Most Common Open Source Licenses
Let’s take a deeper look at most common open source licenses.
Some of the most common copyleft open source licenses are:
- GNU GPL (strong copyleft)
- Eclipse Public License 2.0 (weak copyleft)
- LGPL (weak copyleft)
- Common Development and Distribution License, CDDL, (weak copyleft)
And, some of the most common permissive open source licenses are:
- Apache-2.0
- MIT License
- Berkeley Software Distribution, BSD
As it’s often the case in legal practice there are some nuances between the fine prints of these licenses. Let’s look at the main characteristics of each of these licenses.
GPL and AGPL
GPL is a slightly tricky license because if you share something under GPL license this means your package can be used freely but if someone wants to modify or repackage and redistribute your package they will also have to use the same GPL license.
So, you might want to consider that your audience will be forced to use the same license in that case. Also, if you are working on a package which is published under GPL license and planning to distribute a different or improved version of it you don’t want to breach the license agreement so, you have to use the same license.
In this sense it can be a bit restrictive as a license but it’s also supporting and promoting the continuation of open source distribution which is really nice.
Basically, if you share your work under GPL it’s likely to stay under the same open source licensing.
Another important point with GPL is that it has 3 variations so far: GPL1, GPL2 and GPL3. But each of these variations also have “only” and “or later” versions. So, if you decided to adapt GPL2 only license back in the day, you couldn’t even switch to GPL3 license when it came out while if you choose GPL3 or later license that means you can also use any license that comes after GPL3 if it does (such as GPL4)
AGPL (Affero GPL) is pretty much GPL for network applications such as a website or online service. It’s not weak copyleft like LGPL and it’s copyleft like GPL. The only difference is user is redefined as the visitor of website or user of online application where in GPL case user is user of the program.
You can check out this interesting article on Wikipedia regarding the acquisition of MySQL and how involved open source licenses were affected. You can see the interesting license dynamics and the event that leads to MariaDB database management system after Monty Widenius’ effort to fork MySQL and release it under GPL only license with the name MariaDB.
LGPL
LGPL or Lesser GPL is a weak copyleft version of GPL. Although they are similar in many ways, LGPL allows many important things that GPL don’t.
With LGPL:
You can link to a library dynamically in your software and you wouldn’t have to publish your software under the same license because of that as long as you don’t modify the library with LGPL.
This allows proprietary applications as well as open source applications under different licenses.
If you link to the LGPL library statically though the situation changes and you are required to publish derivative work under LGPL.
There is a very interesting discussion here about how GPL or LGPL applies to interpreted languages such as Python: How does GPL/LGPL static-dynamic linking rules apply to interpreted languages?
Also, if you’d like to learn more about static linking Vs. dynamic linking.
Eclipse Public License 2.0
Eclipse is a weak copyleft license and it’s more similar to CDDL than GPL. EPL allows EPL and non-EPL licensed code to be combined under the same software given that they are separate modules. EPL also allows sub-licensing.
Another feature of Eclipse Public License 2.0 is that it requires commercial distributors to compensate contributors for any damage or lawsuit scenario that might happen.
Eclipse Foundation has a very nice FAQ page you can find here if you are interested.
CDDL
Common Development and Distribution License is a weak copyleft license with a restriction level between GPL and permissive licenses like Apache 2.0.
Instead of everything related or working with the code to be published under the same license as in the case of GPL, it only requires source code under CDDL to remain under CDDL.
This provides more flexibility regarding mixing codes with different licenses and also provides less restriction regarding re-licensing permissions.
Although it might seem subtle this difference has massive implications. A good example is if a closed source product like Adobe Photoshop or Microsoft Windows was to use GPL licensed code somewhere in their massive eco-system, they’d have to publish everything as open source under GPL license. Probably a nightmare scenario for such proprietary software companies or products.
But, if a closed source product used CDDL, they would only have to publish CDDL licensed code and compiled software could be packaged under a different license.
That’s basically how a weak copyleft license such as CDDL exists in a sweet spot between copyleft and permissive licenses.
Unlike strong copyleft licenses like the GPL, mixing of CDDL licensed source code files with source code files under other licenses is permitted without relicensing. The resulting compiled software product (“binary”) can be licensed and sold under a different license, as long as the source code is still available under CDDL, which should enable more commercial business cases, according to Sun.[5][6][7]
Apache-2.0
Apache 2.0 license is permissive and it’s also very similar to other permissive open source licenses such as MIT. However, it has a special trick. Apache 2.0 comes with patent protection for the user and software owner.
If any patent is involved, Apache 2.0 grants rights to freely use the software and waives all the license or patent fees. This grant is in effect until the user decides to sue the contributor/owner in which case license is immediately revoked.
Otherwise, Apache 2.0 gives rights to do pretty much whatever user legally wants to do. It also protects the owners from responsibility and legal issues by disclaiming warranty regarding the code or program.
Another edge Apache 2.0 license has over others is the appropriate legal language and explicitness which makes it an attorney-favorite.
You can check out Apache Licenses here.
MIT
MIT is the most popular open source license. Approximately 50% of all open source projects are under MIT license on Github which is probably a good representative sample of all open source projects in the world.
MIT license is known to be very short and straightforward basically suggesting
- software is free and source code is openly shared
- user can do whatever they want with it
- contributor(s)/owner(s) aren’t responsible and do not guarantee anything
BSD
BSD comes under many varieties. Some main ones are:
0-clause BSD: Originally named Free Public License 1.0.0, zero clause BSD is not derived from BSD license family.
2-clause BSD: Very similar to MIT license with the exception of not explicitly mentioning granting of; merging, publishing, sub-licensing, selling rights.
Although, these rights are likely to be granted under the right to use. There can be restrictions to some of the items since they are not explicitly mentioned such as sub-licensing.
3-clause BSD: Bans using contributor or organization names in promoting products derived from original source code.
4-clause BSD: Requires mentioning the organization’s names in all advertisements related to derivative work. Here is the text obliged to be included:
This product includes software developed by the [organization].
There are also other interesting BSD License varieties such as:
2-clause BSD + Patent, which is somewhat familiar patent reciprocity offered by Apache 2.0 license.
3-clause BSD + no nuclear, which clearly states that code is not licensed or intended for any use in any nuclear facility.
Caution for freestyle licensing
Given there are so many varieties of different licenses, you might be tempted to create your own cool as a cucumber license and maybe name it something like Snow Frost ATL 5.0. Well, hold your horses because this might not be a very wise thing to do for a number of reasons.
Although there seems to be quite some amount of open source licenses these are all approved by Open Source Initiative OSI.
- When you try to operate on your own homemade license, this might mean that you are excluded from using other open source material only allowed to be used by open source projects under OSI approved licenses.
- A bigger problem is however uncharted waters. Regarding any common open source license you can go on an online forum or ask an intellectual property lawyer and you will easily get decent information and likely outcomes about a case. Since, precedent is a major principle in legal matters, having previously established rulings or consortium creates a massive convenience regarding your the visibility of your situation. A custom, homemade license means a whole estimation from ground up which will be a very costly scenario in case you have to go that route.
- It’s very likely that you will mess up something. Open source licenses are created by decent amount of legal power that big organizations employ. It’s usually a team work and takes lots of time effort and time even though they might seem simple. In law, one word or its lack of can turn the tables and your probably don’t want to go through that kind of a stressful situation.
For these reasons, we don’t usually recommend adaptation of a homemade amateur license. However, you never know, your project or startup might actually require something more custom, in which case working with some experienced people and law experts will probably make most sense although even then, unless if you really must, it’s probably something that should be avoided.
Luckily there are numerous options that cater to different needs and philosophies.
The Software Package Data Exchange® (SPDX®) also has a very nice and extensive list of open source licenses here. And also you can find open source licenses under different categories in this list.
Disclaimer: Please understand that, knowledge and comments shared in this article are not legal advice. Although utmost care is taken for integrity and correctness of the information gathered here holypython.com or its authors or its owners do not guarantee accuracy of this information. If you are concerned about choosing a license we encourage you to read the individual license and draw your own conclusion before making your decision. Or, you can also consider seeking professional legal advice. Holypython.com or its authors or its owners will not take any responsibility for decisions made or conclusions drawn based on this article.
Please share if you found this article helpful.
