Publishing code on GitHub does not make it open source. Without a license, the default is all rights reserved, and nobody can legally reuse it. A license tells others what they can do with your code and what they owe you in return.
MIT: short and permissive
Anyone can use, copy, modify and sell the code, including in closed-source products, as long as they keep the copyright and license notice. It is the most common license on GitHub because it is simple.
Apache 2.0: permissive with patent protection
Apache 2.0 allows the same broad reuse as MIT but adds an explicit patent grant from contributors. It also requires keeping the NOTICE file and stating significant changes. Many companies prefer it for that legal clarity.
GPL: copyleft
The GNU General Public License lets anyone use and modify the code, but if you distribute a modified version, you must release its source code under the GPL too. That keeps derivative work open.
- LGPL is a lighter variant often used for libraries: you can link to it from closed-source software.
- AGPL closes the network loophole: if users interact with modified software over a network, such as a web app, you must offer them the source.
How to choose
- Want maximum adoption with minimal rules? MIT.
- Want permissive terms plus patent protection? Apache 2.0.
- Want every improvement to stay open source? GPL or AGPL.
Before adding a dependency to a commercial product, check its license. Copyleft licenses can create obligations for your whole application.
Side by side
- Use in closed-source products: MIT yes, Apache 2.0 yes, GPL only if you don’t distribute the product or you release its source.
- Keep the notice: required by all three.
- Explicit patent grant: Apache 2.0 and GPL version 3 include one; MIT doesn’t mention patents.
- Share your changes: not required by MIT or Apache 2.0; required by the GPL when you distribute.
What “distribute” means
Copyleft obligations under the GPL are triggered when you give the software to someone else, for example by shipping an app, selling a device with the code on it or offering a download. Running modified GPL code on your own servers to power a website is not distribution, which is exactly the gap the AGPL was written to close. Using GPL tools such as compilers or editors to build your product doesn’t affect your product’s license at all.
Mixing licenses
Most projects depend on hundreds of packages, each with its own license. Permissive licenses mix easily. Apache 2.0 code can be combined with GPL version 3 code, but the Free Software Foundation considers it incompatible with GPL version 2. When in doubt, a dependency scanner in your build pipeline can list every license you use and flag the ones your company hasn’t approved.
Adding a license to your project
- Pick the license that matches your goals using the questions above.
- Add a LICENSE file with the full license text to the root of your repository. GitHub offers templates when you create the file.
- Put your name or organization and the year in the copyright line.
- If you use Apache 2.0, add a NOTICE file for any required attributions.
This article is a general guide, not legal advice. For a commercial product with unusual licensing needs, a short consultation with a lawyer who knows open source is money well spent.
What we think
For most personal and small-company projects, MIT or Apache 2.0 is the practical choice: simple, widely understood and friendly to anyone who wants to use your work. Choose the GPL deliberately, when keeping every future version open matters more to you than maximum adoption.
The bigger risk for most teams is not picking the wrong license for their own code but ignoring the licenses of their dependencies. An automated license check in your build costs little and avoids unpleasant surprises later.