A particularly important obligation is the copyleft obligation found in some, but not all, open source licenses. The copyleft obligation requires that any incoming open source code with a copyleft obligation be distributed under the same license to third parties only. In short: The outgoing license must be the same as the incoming license.
This does not only apply to the original open source code, but also to any code that is derived from the incoming copyleft-licensed open-source software. A distributor cannot take incoming copyleft-licensed code, modify it, and distribute it under their own proprietary license. It must be distributed under the incoming copyleft license.
Not all closed-source software will be affected by incoming copyleft-licensed code. U.S. copyright law makes a distinction between derivative and collective works. The copyleft effect applies only to derivative, but not to collective works. Applied to software, it leads to the following definitions.
- Derivative code is code created by building on the original code in such a way that the original code cannot be separated from any additions and modifications easily and using standard tools. The prime example of derivative code is code created by modifing the original code.
- Collective code is a set of codes (programs, libraries) that are kept separate from each other and where each individual code is accessible using standard tools. The prime example of a collective work is when distributors put independent programs next to each other into the same directory.
Developers usually prefer not to modify other people’s code. Rather, they’ll try to use it as a library. However, using a copyleft-licensed library makes any using code a derivative of the library, because the using code necessarily incorporates the interface symbols of the library. This seemingly little beachhead is enough to turn the using code into derivative code, even if using code and used library are maintained as separate files.
Licenses that do not contain a copyleft obligation are called permissive licenses. Licenses that contain a copyleft obligation can be split into weak and strong copyleft licenses. Weak copyleft licenses weaken the copyleft effect by stopping it at a code boundary, if the copyleft-licensed code is its own separate component that can be accessed using standard tools. An example is a dynamically-linked library. In summary:
- A permissive license is a license that has no copyleft obligation. Examples are the MIT license, the Apache-2.0 license, and the BSD family of licenses.
- A (strong) copyleft license is a license with an unrestricted copyleft obligation. Examples are the GPL-2.0-or-later and the AGPL-3.0-or-later families.
- A weak copyleft license is a license where the copyleft effect stops at the code boundary, if the boundary “strongly separates” the using code from the used copyleft-licensed code. Two components are strongly separated, if they can be accessed and modified independently of each other using standard tools. The main example of a weak copyleft license is the LGPL-2.0-or-later license.
Sometimes, developers construct a weak copyleft license by taking a strong copyleft license and modifying or amending it to weaken it for a particular use-case. The prime example is the Syscall Note by Linus Torvalds, through which he stopped the copyleft effect of the Linux kernel code from reaching application code that only uses regular application functions of the kernel.
The copyleft obligation was first introduced by the GPL-2.0-or-later license in 1991 and has proved divisive to the free and open-source software world. Some applaud the obligation for its intent to ensure freedom for end-users, who will always have a right to receive the source code to any copyleft-licensed binary code they are receiving, while others have chided this intention and likened copyleft-licensed software to viruses. Given that most software vendors keep the source code for their products closed, they will try to keep copyleft-licensed code out of their code base at all costs.