Copyright Management and License Compatibility in a Remixed Work
Don't get scared by the title! We wish to use our simplest language to explain some common scenarios that you may encounter when collaborating on software projects. This article is structured in a Q&A way so that you can read only the parts of your concern.
- Can I incorporate the source code of project A into project B?
- If the project A is under an incompatible license with project B, is it impossible to incorporate the source code of A into B?
- What should I do when incorporating project A's source code into project B?
- Can I change the license of my project?
- Can I upgrade the license version of my project?
- I'm asked to sign a CLA before contributing to a project. What is it?
- Can I revoke my license?
- Can I modify an existing license or draft a new license?
- Can I grant additional permission to an existing license?
- Can I add further restrictions to an existing license?
- Can I use multiple licenses for my project?
- Can I allow others to pay me for an exemption from a requirement of the license?
- How are various licenses compatible with each other?
- Afterwords
Can I incorporate the source code of project A into project B?
It primarily depends on whether the license of project A is compatible with the license of project B. Generally, compatibility among free software licenses can be explained as follows:
Permissive licenses ⇒ Intermediate (weak copyleft) licenses ⇒ copyleft licenses
Whereof code under a license on the left side of the arrow (⇒) may be incorporated into code under a license on the right side. If you are still confused about what these categories mean, read An Introduction to Software Licensing.
For example, since LGPLv3 is an intermediate license, and GPLv3 is a copyleft license, you may incorporate LGPLv3-licensed code into GPLv3-licensed code.
Similarly, permissive-licensed code may also be incorporated into intermediate-licensed code, or into copylefted code. For example, code under the MIT License or the Apache License 2.0 maybe incorporated into code under the LGPLv3 or MPL 2.0, or into code under the GPLv3 or AGPLv3.
Do note that these are usually, but not always the case. Sometimes, older versions of licenses may cause incompatibility. Some common examples are:
- The Apache License 2.0 is not compatible with GPLv2, but is compatible with GPLv3.
- MPL 1.1 is not compatible with GPL, but MPL 2.0 is compatible with it. (But there is an exception; see below.)
Some other factors may also lead to incompatibility. For example, MPL 2.0 allows the distributor to attach a notice prohibiting the software to be incorporated into a project under a GNU license. This way, it is not compatible with GPL.
See also our compatibility matrix.
If the project A is under an incompatible license with project B, is it impossible to incorporate the source code of A into B?
Not really. It's impossible only when their license remains unchanged. By changing the license of project A or B, you may be able to incorporate the source code of A into B. See our compatibility matrix and how to change the license.
What should I do when incorporating project A's source code into project B?
It depends on the license of project A.
If project A is under a permissive license, then the usual condition is to attribute project A in project B. For example:
- If project A is under the MIT license or BSD (2-Clause or 3-Clause) license, you only need to retain project A's copyright and license notice where appropriate in project B.
- If project A is under the Apache License 2.0, the following things need to be done in project B: (1) accompany a copy of the license; (2) mark changed files; (3) retain all notices of copyright, patent, trademark attribution; (4) retain the NOTICE file distributed with project A (if any).
If project A is under a copyleft license, then:
- For GPL, these are the main obligations: (1) accompany a copy of the license; (2) mark changes of the work; (3) retain all notices of copyright, disclaimer of warranty, etc.; (4) provide the source code of project B under the same license.
- For AGPL, in addition to the obligations from GPL, for users who use project B as a service over the internet, you have to provide them with the source code of project B as well.
If project A is under an intermediate (weak copyleft) license, typically MPL or LGPL, the license of project B is of your choice. Despite that, when distributing project B, you'll have to at least meet some minimum conditions:
- Some common conditions from license A are: (1) claim the usage of project A; (2) retain the copyright and license notice of project A; (3) provide a way to obtain a copy of project A's license; (4) provide the source code of project A or its modified version under the same license.
- Additionally, LGPL requires that you must allow the recipients to recombine project B using a modified version of A.
Above is our summary of obligations concerning some common licenses. If you want to learn the details of a license, please read its license text.
Can I change the license of my project?
Yes. We call this "relicensing."
If the project is fully written by you, without anyone else's code, you may relicense your project directly.
If your project contains code not written by you, then relicensing is only allowed when:
- The license of that code is compatible with the license you wish to switch to; or
- The author of that code signed a CLA or similar document when contributing, explicitly granting you the permission to relicense it.
If none of the above is your case, you have to ask the author of that code for permission before you can relicense it.
Note that by relicensing your project, the new license only applies to newer versions of the project. Previous license still remains in effect for older releases of your project.
Can I upgrade the license version of my project?
Two different versions of a license are in practice two different licenses. Therefore, upgrading the license of a project is equivalent to relicensing it. Please read the previous question to learn the requisites of doing so.
Despite that, there are two exceptional cases:
- For GNU licenses (GPL, AGPL, LGPL):
- If, when publishing your project, you stated that the project was "licensed under XYZ or any later version of the license", for example "licensed under GPLv2 or any later version of it" or "licensed under AGPLv3 or any later version of it," then recipients may choose to accept that version of the license, or any later version of their choice.
- If, when publishing your project, you stated that the project specified a proxy that could decide which future versions of the license could be used, then recipients may choose to accept the current version of the project's license, or any later version of it that the proxy had publicly accepted. Here is an example where a project specifies a proxy.
- For MPL, if you published your project under MPL 2.0 (the most commonly used version), then recipients may use your project under MPL 2.0 or any later version of their choice, regardless of whether you permitted usage under any later versions beforehand. In other words, the auto upgrading mechanism is built-in. You don't need to upgrade the license manually, and you can't stop the mechanism.
I'm asked to sign a CLA before contributing to a project. What is it?
CLA stands for Contributor License Agreement. Some projects require contributors to sign a CLA or a similar document before they can contribute.
Contents of these documents differ from project to project. Some of them are for the mere purpose of ensuring authorship of the contributor over the contribution, or that they are authorized to submit it (for example, the DCO of Linux). However, some other documents require that you grant them the permission to relicense your contribution, or even transfer your copyright to them. In that case, they may change the license of your contribution later without your consent, or even incorporate it into proprietary software.
If the project you are contributing to requires that you sign a document as such, make sure you read its content. If you find it unacceptable, you may create your own fork under the same license without having to follow its CLA or any documents alike.
Can I revoke my license?
No. Free software licenses are irrevocable. Once users receive your software, they have perpetual permission to practice their rights under the license, even if you cease distribution of your project or take down its public repository.
Can I modify an existing license or draft a new license?
Modifying a license is in practice drafting a new license. We strongly discourage doing so. If your purpose is to grant additional permission, refer to this question; if your purpose is to add further restrictions, refer to this question. If you wish to draft a new license anyway, do bear the following in mind:
Firstly, when drafting a new license, you need to consider various legal matters such as legal effect and license compatibility. Legal issues can affect how others are willing to reuse your project in their own projects.
Secondly, you can't give your license a name like "GNU Non-commercial License," "Apache No-derivative License" or "Mozilla Personal-use License." Names like GNU, Apache and Mozilla are trademarked: doing this will lead to trademark infringement.
Thirdly, if you wish to adopt text from other licenses into your new license, you may need a copyright license over the text. As far as we are concerned, GNU, Mozilla and Apache permits reuse of their license texts, but prohibits usage of their trademark as we mentioned above. Additionally, GNU forbids reusing the preamble and appendix of their licenses.
Finally, if you are drafting a new license for a project already published under another license, you need to make sure you have the right to relicense it. Refer to this question to learn the requisites of doing so.
Can I grant additional permission to an existing license?
Yes. If you wish to void certain restrictions of a license or void them under certain circumstances, you may attach to the license notice of your project a legal statement stating which exceptions are added to the license.
Additional permission is usually granted in the context of a copyleft license to exempt the effect of copyleft in some circumstances. Some example cases are: 1, 2 and (a bit more complex) 3.
Granting additional permission to a license turns its terms more permissive, which is similar to changing the license of your project. Therefore, you have to ensure that you have the right to do so. Refer to this question to learn the requisites of doing so.
Can I add further restrictions to an existing license?
Usually not in a way you expected.
A license is of integrity. Generally, when you add a restriction to a license, you can no longer state that your project is "licensed under [name of the original license]."
Sometimes, it's also not allowed to state that a project is "licensed under [name of the original license], but with XYZ restrictions." For example, if you publish your project under (A)GPLv3, and claim that it may not be used for commercial purposes, then Section 7 of (A)GPLv3 voids that restrictions.
Some licenses do allow some restrictions to be added along, but the restrictions you can add are very limited, and won't meet your wish to add any restrictions of your choice. For example:
- MPL 2.0 allows the author to prohibit the software from being incorporated into a project under a GNU license.
- (A)GPL allows the software to be under some additional terms that protect reputation or add extra disclaimers. In fact, the purpose of allowing these restrictions to be added to (A)GPL is to make some existing licenses compatible with it.
In summary, it is merely possible to add whatever restrictions you like to an existing license. You need to draft a new license.
Can I use multiple licenses for my project?
Yes. We call this "dual licensing."
You may state in the license notice of your project that "this project is licensed under [license A] or [license B]." That way, recipients may choose to receive it under the terms of either license A or license B.
Sometimes, developers choose to license their project under multiple licenses with similar terms. This is because despite their terms being similar, they are compatible with different licenses; and by dual-licensing their project, they make it compatible with more licenses. However, such practice is very uncommon now.
Can I allow others to pay me for an exemption from a requirement of the license?
Yes. We call this "selling exceptions."
Selling exceptions is similar to granting additional permission, except other parties are purchasing such permission. Also, such permission is usually granted exclusively, rather than publicly.
Selling exceptions is not an uncommon practice. For instance, the Qt framework is licensed under the GPL, requiring projects depending on it to be licensed under GPL consequently. However, developers may purchase an exception that allows them to publish their Qt programs as proprietary software.
How are various licenses compatible with each other?
For compatibility between two GNU licenses, refer to the GNU license compatibility matrix.
For compatibility concerning a non-GNU license, refer to our matrices below:
- Compatibility between a non-GNU license and a non-GNU license
- Compatibility between a GNU license and a non-GNU license
- Compatibility between a non-GNU license and a GNU license
Before reading the following matrices, note that:
- "BSD" includes both the BSD 2-Clause License and the BSD 3-Clause License.
- "MPL 2.0 NCE" is a temporary code we've created meaning "licensed under MPL 2.0, incompatible with secondary licenses." According to MPL 2.0, when the software is distributed along with a notice containing the Exhibit B of MPL 2.0, then it can not be incorporated to some licenses.
- "XYZ+" means the distributor allows recipients to use the software under "license XYZ or any later version of it."
- When we say "OK: Combination is under XYZ," your project must be relicensed under that license before the combination can happen. When we say just "OK," no relicensing is needed.
1. Compatibility between a non-GNU license and a non-GNU license
In this case, you want to incorporate code under a license in the first column, into your own project under a license in the first row.
| ↱ | MIT / BSD License | Apache License 2.0 | MPL 2.0 | MPL 2.0 NCE |
|---|---|---|---|---|
| MIT / BSD License | OK | OK | OK | OK |
| Apache License 2.0 | OK: Combination is under Apache License 2.0 | OK | OK | OK |
| MPL 2.0 | OK: Combination is under MPL 2.0 | OK: Combination is under MPL 2.0 | OK | TBD |
| MPL 2.0 NCE | OK: Combination is under MPL 2.0 NCE | OK: Combination is under MPL 2.0 NCE | TBD | OK: Combination is under MPL 2.0 NCE |
2. Compatibility between a GNU license and a non-GNU license
In this case, you want to incorporate code under a license in the first column, into your own project under a license in the first row.
| ↱ | MIT / BSD License | Apache License 2.0 | MPL 2.0 | MPL 2.0 NCE |
|---|---|---|---|---|
| LGPLv2.1 | OK: Combination is under LGPLv2.1 | NO | OK: Combination is under LGPLv2.1 | NO |
| LGPLv2.1+ | OK: Combination is under LGPLv2.1 or LGPLv3 | OK: Combination is under LGPLv3 | OK: Combination is under LGPLv2.1+ | NO |
| LGPLv3 | OK: Combination is under LGPLv3 | OK: Combination is under LGPLv3 | OK: Combination is under LGPLv3 | NO |
| LGPLv3+ | OK: Combination is under LGPLv3 | OK: Combination is under LGPLv3 | OK: Combination is under LGPLv3+ | NO |
| GPLv2 | OK: Combination is under GPLv2 | NO | OK: Combination is under GPLv2 | NO |
| GPLv2+ | OK: Combination is under GPLv2 or GPLv3 | OK: Combination is under GPLv3 | OK: Combination is under GPLv2+ | NO |
| GPLv3 | OK: Combination is under GPLv3 | OK: Combination is under GPLv3 | OK: Combination is under GPLv3 | NO |
| GPLv3+ | OK: Combination is under GPLv3 | OK: Combination is under GPLv3 | OK: Combination is under GPLv3+ | NO |
| AGPLv3 | OK: Combination is under LGPLv3 | OK: Combination is under AGPLv3 | OK: Combination is under AGPLv3 | NO |
| AGPLv3+ | OK: Combination is under AGPLv3 | OK: Combination is under AGPLv3 | OK: Combination is under AGPLv3+ | NO |
3. Compatibility between a non-GNU license and a GNU license
In this case, you want to incorporate code under a license in the first row, into your own project under a license in the first column.
| ⬐ | MIT / BSD License | Apache License 2.0 | MPL 2.0 | MPL 2.0 NCE |
|---|---|---|---|---|
| LGPLv2.1 | OK | NO | OK | NO |
| LGPLv2.1+ | OK | OK: Combination is under LGPLv3 | OK | NO |
| LGPLv3 | OK | OK | OK | NO |
| LGPLv3+ | OK | OK | OK | NO |
| GPLv2 | OK | NO | OK | NO |
| GPLv2+ | OK | OK: Combination is under GPLv3 | OK | NO |
| GPLv3 | OK | OK | OK | NO |
| GPLv3+ | OK | OK | OK | NO |
| AGPLv3 | OK | OK | OK | NO |
| AGPLv3+ | OK | OK | OK | NO |
Afterwords
So lengthy though the article is, there are still matters which we are yet to explain clearly.
Out of them is the most important fact that difference in licensing doesn't equate difference in choice of license. One license may result in different situations of licensing. Some examples, in SPDX identifiers, are: MPL-2.0 != MPL-2.0-no-copyleft-exception or GPL-3.0-only != GPL-3.0-or-later.
While you may not be clear about it for now, we wish to explain it clearly in future revisions.