If you’re starting from a blank slate, it’s hard to go wrong with the MIT License. It’s short, very easy to understand, and allows anyone to do anything so long as they keep a copy of the license, including your copyright notice. You’ll be able to release the project under a different license if you ever need to.
Otherwise, picking the right open source license for your project depends on your objectives.
Your project very likely has (or will have) dependencies. For example, if you’re open sourcing a Node.js project, you’ll probably use libraries from the Node Package Manager (npm). Each of those libraries you depend on will have its own open source license. If each of their licenses is “permissive” (gives the public permission to use, modify, and share, without any condition for downstream licensing), you can use any license you want. Common permissive licenses include MIT, Apache 2.0, ISC, and BSD.
On the other hand, if any of your dependencies’ licenses are “strong copyleft” (also gives public same permissions, subject to the condition of using the same license downstream), then your project will have to use the same license. Common strong copyleft licenses include GPLv2, GPLv3, and AGPLv3.
You may also want to consider the communities you hope will use and contribute to your project:
- Do you want your project to be used as a dependency by other projects? Probably best to use the most popular license in your relevant community. For example, MIT is the most popular license for npm libraries.
- Do you want your project to appeal to large businesses? A large business will likely want an express patent license from all contributors. In this case, Apache 2.0 has you (and them) covered.
- Do you want your project to appeal to contributors who do not want their contributions to be used in closed source software? GPLv3 or (if they also do not wish to contribute to closed source services) AGPLv3 will go over well.
Your company may have specific licensing requirements for its open source projects. For example, it may require a permissive license so that the company can use your project in the company’s closed-source product. Or your company may require a strong copyleft license and an additional contributor agreement (see below) so that only your company, and nobody else, can use your project in closed source software. Or your company may have certain needs related to standards, social responsibility, or transparency, any of which could require a particular licensing strategy. Talk to your company’s legal department.
When you create a new project on GitHub, you are given the option to select a license. Including one of the licenses mentioned above will make your GitHub project open source. If you’d like to see other options, check out choosealicense.com to find the right license for your project, even if it isn’t software.