Releasing open source software involves choosing an appropriate license and applying it to your code. The choice of license will determine how others can use your software, so it’s important to pick a license that aligns with your goals for the project. Below we’ll cover several common scenarios and choices when open sourcing software, including dedicating it to the public domain, using non-reciprocal licenses, or using copyleft licenses.
Using a non-reciprocal open source license
These licenses are extremely popular for releasing software because they impose minimal restrictions on how your code can be used. Non-reciprocal licenses (often called permissive licenses) allow others to take your code and pretty much do anything, including incorporating it into proprietary products, as long as they meet a few basic requirements like preserving your copyright notice. They do not require people to open source their own derivative works.
Common examples of non-reciprocal licenses are MIT License, Apache License 2.0, BSD (2-clause or 3-clause), and ISC (among others). These licenses differ in details but share the core philosophy of “Do what you want with this code, just don’t remove my notice (and don’t hold me liable).”
- MIT License: A very short and simple license that basically says anyone can use, copy, modify, merge, publish, distribute the software for any purpose, on the condition that they include the original copyright and license notice in any copies or substantial portions of the software. It offers no patent license and no copyleft requirements. MIT is so straightforward that it’s become the most widely used open source license by modern developers. In fact, estimates show around one-third of open source projects use MIT, and since the rise of platforms like GitHub, MIT’s simplicity has made it a default choice for many projects.
- Apache License 2.0: A non-reciprocal license similar in spirit to MIT but longer and more explicit. Apache 2.0 also grants an explicit patent license from contributors to users, meaning if a contributor holds any patents on their code, they license those patents to anyone using the software. This patent protection is a key feature; it reassures users (especially companies) that they won’t be sued for patent infringement by contributors. Apache 2.0 requires preservation of copyright and license notices, a notice of any substantial changes made to the code, and inclusion of an attribution NOTICE file if provided. These conditions make it slightly less bare-bones than MIT (hence sometimes said “Apache is a bit less permissive than MIT”), but it’s still considered a non-reciprocal license because it doesn’t force derived works to be open source. Apache 2.0 is also very popular, used by many large projects and companies, e.g. Android, Hadoop.
- BSD License: There are a few variants (BSD 4-Clause, BSD 3-Clause, BSD 2-Clause), but they are similar to MIT in terms. BSD 2-Clause (also known as “Simplified BSD”) basically says: you can use/modify/distribute as long as you keep my copyright notice and don’t sue me. BSD 3-Clause adds a clause that you can’t use the author’s name to endorse derived products without permission. These licenses come from the Berkeley Unix days and are time-tested non-reciprocal licenses. Another very similar license is ISC, which is essentially a simplified text non-reciprocal license used often in place of MIT/BSD.
- Others: There are a few other non-reciprocal licenses like the Microsoft Public License (MS-PL) or MIT-0 (zero-clause MIT), but the ones above are the most commonly seen. You can check out all OSI Approved Licenses® at opensource.org/licenses
Using a non-reciprocal license for your project is straightforward: pick the license text (from opensource.org/licenses), add a LICENSE file with it, and add a short comment header in your source files indicating “Licensed under MIT, (c) 2025 Your Name” (for example). You’re basically saying “here’s my code, you can use it for any purpose as long as you give me credit and don’t hold me liable.” This invites the broadest adoption because non-reciprocal licensing places almost no burden on downstream users. Developers who might be wary of copyleft (because they don’t want to open source their own code) will happily use permissively licensed components.
In fact, if your goal is maximal usage and integration, non-reciprocal licenses are often recommended. Large companies also often prefer non-reciprocal licenses for third-party code, as it allows integration without legal worries. Many companies even have policies that any open source they release should be under a non-reciprocal license, to avoid obligations that could conflict with proprietary products
You can use a non-reciprocal license if you want to give users freedom without obligating them to share back changes. This is great for libraries, frameworks, or code meant to be widely used (e.g., an npm package where you don’t mind if someone uses it in closed-source software). The trade-off is that if someone improves your code and doesn’t want to share it, they are allowed not to – non-reciprocal licensing focuses on your freedom as the author to let others do as they will, rather than ensuring a commons of improvements. If keeping modifications public is important to you, then consider a copyleft license instead.
Using Copyleft (reciprocal) licenses
If you decide to release your software under a copyleft license, you are choosing to enforce the share-alike requirement – you want to ensure that if someone builds upon your work, the community benefits by getting access to their improvements as well.
How to apply a copyleft license: The mechanics are similar (add the license text to your project, include headers). For example, if using GPL, you would include a file COPYING or LICENSE with the GPL text, and in each source file a short notice:
Copyright (c) <YEAR> Your Name
This program is free software: you can redistribute it and/or modify it under the terms of the GNU General Public License… [etc].
Implications of choosing copyleft:
- You ensure a level playing field: Anyone who takes your code must open up their code (if it’s a derivative and they distribute it). This prevents a scenario where a company takes your open source project, improves it privately, and sells a closed-source version—copyleft would force them to share those improvements under the same license. For example, the GPL was created explicitly to prevent software from becoming proprietary; it “keeps software free” by design. Many developers choose GPL because they want to protect their project from being absorbed into closed software. This appeals to those who see their project as a community good and want any enhancements to remain in the open. As one guide put it, if you don’t want your work used in closed-source software, a strong copyleft like GPL is appropriate.
[logos of popular projects using GPL]
- The flip side is that some companies or developers will avoid using copyleft-licensed code, precisely because they don’t want to be obligated to open source their entire project. For instance, a big enterprise might shy away from GPL code if they are building proprietary software, since using it would legally compel them to release source for their whole program. This means if you choose a strong copyleft license, your potential user/contributor base might exclude those who can’t comply (like certain commercial uses).
- Compatibility concerns: Using a copyleft license means you (and others) can only combine your code with other code that is compatible with that license. For example, GPLv3 code can incorporate MIT or Apache 2.0 licensed code (since those non-reciprocal licenses don’t conflict and GPLv3 explicitly allows Apache 2.0 code as compatible), but a GPLv3 project cannot incorporate GPLv2-only code or code without violating one license or the other.
As the maintainer you’ll need to be mindful of what other licensed code you can use in your project. Generally, copyleft is easiest if your project is mostly self-contained or uses permissively-licensed dependencies. If you rely on another copyleft component, it should be compatible or the same license (e.g., GPLv3 and AGPLv3 can coexist, LGPL is designed to be linked with GPL code or closed code under conditions, etc.).
- Community expectations: Consider the community or ecosystem. Some communities lean copyleft (for example, a lot of GNU/Linux distro software is GPL, and contributors expect that). Others, like JavaScript or web developers, might lean non-reciprocal (MIT is extremely common in npm packages).
There are also gradations in copyleft you can choose based on how much reciprocity you want:
- If you want full copyleft for any use, GPLv3 is a solid choice.
- If you specifically want to ensure openness even for web services built on your code, consider AGPLv3 (used by web-oriented projects to force SaaS contributors to share changes).
- If your project is a library and you want it usable in proprietary apps while still ensuring improvements to the library are shared, LGPL or MPL might be appropriate (this is a common choice for libraries – e.g., Qt is LGPL for its free edition, many Mozilla components are MPL).
- If you want a middle ground like “any changes to my code must be released, but you can use it in larger proprietary projects,” MPL can serve that purpose (it’s file-level copyleft).
Example: Suppose you wrote a game engine. If you license it under GPL, any game developer who uses your engine and distributes their game would have to open source the entire game (which they likely won’t want to do). If you license it under LGPL, they could use your engine in a proprietary game, but if they modify the engine code itself, they must publish those modifications under LGPL. If you license it under MIT, they could even modify your engine and keep those changes private. Depending on what outcome you want (free engine improvements vs. attracting more users), you’d choose LGPL vs MIT accordingly.
Copyleft license in use: One historic success of copyleft is the Linux kernel (GPLv2). It forced hardware companies to release their driver source code if they integrated it into the kernel, contributing to a massive collaborative ecosystem. Projects like WordPress (GPL) ensure that plugins or derivatives are GPL. On the other hand, some modern companies prefer to start permissive to gain users and only later consider stronger terms if needed.
Finally, note that if you are the sole copyright holder (or have contributors sign agreements), you could offer exceptions or dual licenses for special cases. For instance, some GPL projects provide a “linking exception” to allow linking with certain proprietary software. This gets complex, but just know that copyleft isn’t all-or-nothing; it can be tuned or paired with other licensing in special arrangements.
