A software license is a legal instrument that tells others what they can and can’t do with a piece of software. By default, software —as any original works of authorship fixed in a tangible medium— is protected by copyright, which means that without an explicit license, all rights are reserved to the author. In practical terms, simply publishing your code (for example on GitHub) does not automatically give others permission to use or modify it. If you want others to use, study, share, or change your software, you must include a license granting those rights. A license thus acts as your explicit permission (under certain conditions) for anyone to use or redistribute your copyrighted software.
To better understand what a license is, let’s start with an etymological analysis of the term: the word “license” comes from the Latin “licére” which means “to allow”; therefore indicates an authorization, the granting of a permit.
The owner of the rights to the creative work (licensor) grants the user (licensee) permission to make certain uses of the work, provided that the latter complies with certain conditions. The license to use therefore represents a “conditional permit” and we can summarize the concept in the phrase “you can do X as long as you do Y”.
— Simone Aliprandi (April 2022) – Understanding software licenses: a clear and comprehensive guide
How are licenses applied to software?
In practice, applying a license to software involves adding the license text and a notice of copyright to your project. Most open source projects include a LICENSE, NOTICE or COPYING file in the root of the source code repository that contains the full license text. Many developers also include a copyright and license header in each source file (or at least in major files), so that the licensing terms travel with the code.
In modern practice, a SPDX license identifier can be used in file headers to clearly label the license of each file in a standardized, machine-readable way. For example, adding a comment like
// SPDX-License-Identifier: MIT
at the top of a source file indicates that file is licensed under the MIT License.
Using SPDX tags helps others (and tools) easily determine the license of code, especially when files get copied between projects. In short, to release software under a license, you should include the license text and make it unambiguous which license applies to the code (often by a top-level file and file headers or README notices).
Open Source vs. proprietary licenses (reciprocal vs. non-reciprocal)
Software licenses generally fall into two broad categories:
- Open Source licenses
- Proprietary licenses
Any license that is approved by the OSI is considered an “OSI Approved License®.” and grants users the freedom to use, study, modify, and share the software, as long as they comply with certain conditions.
Proprietary licenses (also known as closed-source licenses) are more restrictive – they do not meet the Open Source Definition and usually forbid sharing or modifying the software. In other words, open source software can be freely accessed and modified by anyone under its license terms, while proprietary software usually keeps source code closed and tightly controls what end users can do.
Open source licenses themselves can be divided into reciprocal and non-reciprocal categories. A reciprocal/copyleft license (also called a share-alike license) requires that if you distribute derivative works (modified versions or software that incorporates the licensed code), you must release them under the same license as the original. This “reciprocity” ensures that the software and any improvements to it remain open source in downstream copies. For example, if you incorporate code licensed under the GNU General Public License (GPL) into your project, you are required to distribute your project under the GPL as well
Copyleft licenses essentially say: you can use my code, but if you share a modified version of it, you must also share it under the same terms. This category includes licenses like GPL, LGPL, AGPL, Mozilla Public License (MPL), etc., with varying strength of the share-alike requirement (more on “strong” vs “weak” copyleft below).
In contrast, a non-reciprocal license (often called a permissive license) does not require derivative works to carry the same license. These licenses allow the code to be used and combined with other code (even proprietary) without forcing the combined work to be open source. In other words, software under a non-reciprocal license can be incorporated into projects that are released under different licenses, including closed-source projects
For example, code under the MIT License or Apache License 2.0 can be used inside a closed source proprietary product – the only obligation typically is to preserve copyright notices and license disclaimers in the portions of code you used. Because they don’t impose a share-alike requirement, non-reciprocal licenses are sometimes called permissive licenses.
Open source licenses can be either reciprocal or non-reciprocal. Both types are open source because they grant the requisite freedoms (use, study, modification, redistribution) – they only differ in whether they require sharing under the same terms. Proprietary licenses, on the other hand, do not grant the freedoms required by the Open Source Definition.
