Image Description
Choosing a software licence
MIT? GPL? Apache? BSD? MPL?
Software licensing has an impressive collection of capital letters.
Rather than picking the licence with the nicest name, start with a much more useful question: what do you want other people to be able to do with your software?
First: do you own what you are licensing?
If you wrote the project yourself, this may be straightforward. If it contains code from other people, was written for an employer or has multiple contributors, things can become more complicated.
A licence cannot magically give you rights you do not have.
Do you want broad reuse, including closed-source software?
If yes, a permissive licence may suit your goal.
The MIT Licence and BSD licences are short and permissive. Apache License 2.0 is also permissive and includes more explicit provisions around patents.
Do you want distributed modified versions to remain under copyleft terms?
If keeping covered software free when it is distributed is important to you, investigate the GNU GPL.
GPL is not simply "the licence where source code is available". It has specific terms and obligations, so read the version you intend to use.
Are you licensing a library?
The GNU LGPL is often considered for libraries because it is designed to allow certain forms of linking from differently licensed applications while keeping requirements around the LGPL-covered library.
Do not translate that into "always use LGPL for libraries". Plenty of libraries use other licences.
Is network use important to your goal?
The GNU AGPL is worth investigating when you specifically want its network interaction provisions. Choose it because you understand and want those terms, not because "AGPL sounds like GPL with extra letters".
Do you want file-level copyleft?
The Mozilla Public License 2.0 uses a file-level approach. MPL-covered files can be combined with other code under the licence's terms, while modifications to covered files remain subject to MPL requirements.
What licences do your dependencies use?
Your choice does not happen in a vacuum. If your project includes or distributes other people's code, their licences matter.
When compatibility matters, check authoritative guidance for the exact licence versions involved rather than trusting a random compatibility chart copied around the web for fifteen years.
Do you need a custom licence?
Probably not.
Creating your own licence gives every potential user another set of legal terms to investigate. Established licences have the enormous advantage of being recognised and widely discussed.
What about Creative Commons?
Creative Commons licences are designed for many kinds of creative works, but Creative Commons recommends using a standard free and open-source software licence for software. Documentation and artwork may be a different story.
See Creative Commons licences and software.
So, where do you start?
- Want a short, permissive licence? Read about MIT and BSD.
- Want a permissive licence with explicit patent provisions? Investigate Apache 2.0.
- Want strong copyleft for distributed software? Investigate GPL.
- Licensing a library and interested in weaker copyleft? Read about LGPL.
- Want strong copyleft that also addresses certain network use? Read about AGPL.
- Want file-level copyleft? Read about MPL 2.0.
Then read the real thing
Our individual pages are introductions. Once a licence looks suitable, read its actual text and official guidance before applying it.
Yes, licence text is less exciting than writing the software. I can't fix everything.
Further reading and external resources
- Open Source Initiative: approved licences
- Choose an Open Source License
- GNU licence list and compatibility information
Previous: Introduction to software licences | Next: The MIT Licence