Licensing
The first step to open sourcing a project is to decide which license will help meet the aims of the project in the best way.
Last updated
The first step to open sourcing a project is to decide which license will help meet the aims of the project in the best way.
Last updated
MIT, Apache 2.0, and GPLv3 are the most popular open source licences, but there are other options to choose from.
When you start looking at different types of licenses, you will most likely wonder:
Why are there so many types of licenses? Aren't they all the same?
And the truth is that while they may be similar, no two licenses are the exact same. All licenses have to be certified by the OSI and meet a certain range of criteria.
Comply with the open source definition:
Basically - have open source code, have no restrictions, allow derived works (can ask them to have a slightly different name than the original software), and not be limited to a product or type of platform.
Choose one of the 3 types of licence approvals:
Retirement (saying bye to current licence),
Legacy Approval (if the licence has been extensively used unofficially by the community and you want to make it official)
Approval (first timers)
Each license should be clearly distinguishable from current licenses. The application form to submit a new type of license for approval must include:
Rationale: Clearly state rationale for a new licence.
Distinguish: Compare to and contrast with the most similar OSI-approved licence(s)
Legal review: Describe any legal review the licence has been through, and provide results of any legal analysis if available
Proliferation category: Recommend which licence proliferation category is appropriate
Another way of looking at it is that you’re picking a licence based on what you are afraid of. All of these licences assume you’re afraid of being sued.
The MIT licence is if you’re afraid no one will use your code; you’re making the licensing as short and non-intimidating as possible.
The Apache licence you are somewhat afraid of no one using your code, but you are also afraid of legal ambiguity and patent trolls.
With the GPL licences, you are afraid of someone else profiting from your work (and ambiguity, and patent trolls).
This is a radical simplification, but if nothing else it can be a helpful framework in discussing with your attorney what licence makes sense for your software.
📌 Great site that simplifies the licences - https://www.exygy.com/blog/which-licence-should-i-use-mit-vs-apache-vs-gpl
MIT gives you only a copyright licence. Apache 2.0 gives you both a copyright AND a patent licence.
Apache is harder for common users to understand and places more restrictions on users than MIT.
However, Apache is preferred by some because it allows developers to claim patents on derivative projects.
The answer of which licence is best depends on answering: What is your goal?
Broadly speaking, if developers desire the assurance of patent protection + added security to the original, Apache 2.0 is the better choice.
If the goal is for the resultant modified software to be highly accessible by future users without constraints, developers should choose MIT.
Apache and MIT are ‘permissive licences’, GPL is a copyleft licence. It places additional restrictions on users and can be very intimidating to those not familiar with tech. In some cases it is preferred by developers because of the logic ‘if i’m using open source, you should too’.
Basically: