The copyright holders of the code can change its license terms or add an exception, and nobody else can. If one author wrote it all, that author decides. If many people contributed, you need each holder's approval for their part. Borrowed GPL code from other authors cannot be freed by you. Not legal advice.
Definition: why holders matter
A license is a permission granted by the copyright holder. Outsiders cannot widen it. The GNU FAQ makes the point in its discussion of exceptions that let a GPL program link to a nonfree library. It says the copyright holders alone for the program can legally release their software under these terms. If you wrote the whole program yourself, and your employer or school does not claim the copyright, you are the copyright holder and can authorize the exception. If you use parts of other GPL covered programs by other authors, you cannot authorize the exception for them. You must get the approval of those copyright holders.
The FAQ adds that when other people modify the program, they do not have to make the same exception for their code. It is their choice.
Common situations
| Situation | Who can decide |
|---|---|
| Solo project, you wrote everything | You, unless an employer or school claims copyright |
| Employee wrote it on company time | Check the employment terms; the employer may hold the rights |
| Many contributors, no assignment or grant | Each contributor for their contribution |
| Project copies GPL files from another project | The authors of those files |
| Downstream fork modifies your code | They can add terms for their own changes, within your license |
Why contributor paperwork exists
If a project wants flexibility later, such as adding an exception or offering a second license, it has to have the rights to do so. Projects handle this in different ways. Some ask contributors for an agreement that grants broad rights. Others use a lighter sign off at commit time that records the right to submit the work under the project license. The two are not the same, and neither is automatic. See our post on the Developer Certificate of Origin for the lighter approach.
Steps before you change a license
- List all copyright holders. Use the commit history and any copyright files, not guesses.
- Check for employer claims on contributors' work.
- Check for borrowed code: files copied from other projects carry their own licenses.
- Decide the path: get written consent from each holder, rewrite the parts of those who cannot be reached, or keep the license.
- Record the consents with the date.
- Update license files, headers and package metadata together so tools read the same answer.
Why package consumers care
If a library you depend on changes its license, the new terms usually apply to new releases. The old versions you already received keep the terms they came with. That is why your inventory should record the license per version, and why upgrades can trigger a fresh review.
Try it yourself
The continuous monitoring demo shows how changes to components are surfaced over time. Click through it and look at how a version change appears, since a license change arrives with a version change.
Click through it at your own pace, or open it full screen.
Safeguard's SBOM and dependency scanning, plus policies and gates, help you notice and review components when versions change. A free scan is available at gold.safeguard.sh/scan.
Quick check
Can a company add a linking exception to a GPL project it forked?
Just for code it holds the copyright to. The FAQ says you cannot authorize the exception for parts written by other authors.
Do downstream modifiers have to keep my exception?
No. The FAQ says it is their choice whether to make the same exception for their own code.
Does an employer hold the copyright to my code?
It can. The FAQ's wording assumes your employer or school does not claim the copyright. Check your agreement.
Sources
Last reviewed: 19 October 2026.
