Derivative works in software licensing present complex challenges that affect developers and legal teams. This note provides an overview of how different licence agreements characterize derivative works, influencing compliance requirements and strategic choices in software innovation and commercialization. A solid grasp of these definitions is essential to navigate legal risks and optimize licensing outcomes.
The concept of a derivative work in software is central to licensing. It determines whether modifications, plug-ins, or integrations must comply with the original licence terms. The definition varies across jurisdictions and licence families.
- Copyright law: Derivative works are adaptations or modifications of an original work. In software, this includes modified source code, translations, or extensions.
- Licence terms: Each open-source licence defines obligations differently, sometimes expanding or narrowing the scope of what counts as a derivative work.
- Practical impact: Determines whether new code must be licensed under the same terms (copyleft) or can be relicensed (permissive).
| Licence | Treatment of Derivative Works | Key Obligations | Risks | Practical Strategies |
| GPL (Copyleft) | Broad definition: any modification, integration, or linked library may be considered derivative. | Must release derivative works under GPL, including source code. | Limits proprietary use; risk of “viral” effect. | Use modular separation; consider LGPL for libraries. |
| LGPL (Lesser Copyleft) | Linking to libraries does not create a derivative work if done dynamically. | Modifications to the library itself must be GPL; applications can remain proprietary. | Ambiguity in static vs dynamic linking. | Document linking method; prefer dynamic linking. |
| MIT (Permissive) | Derivative works allowed with minimal restriction. | Must retain copyright notice. | Risk of losing attribution if notices are stripped. | Implement attribution management. |
| Apache 2.0 (Permissive + Patent) | Similar to MIT, but includes explicit patent licence. | Must retain notices and include NOTICE file. | Patent termination clause may trigger disputes. | Conduct patent clearance before integration. |
This section highlights the fundamental differences between licence types regarding derivative works, illustrated with practical examples:
- Copyleft licences (GPL): Consider almost any modification or integration as a derivative work. For example, if you modify GPL-licensed software or statically link a library, your entire project must be released under GPL, which can limit proprietary use.
- Permissive licences (MIT, Apache): Allow more freedom to modify and relicense. For instance, you can incorporate MIT-licensed code into proprietary software as long as you retain the copyright notice.
- Hybrid licences (LGPL): Provide a middle ground. For example, dynamically linking to an LGPL library does not make your software a derivative work, so you can keep your code proprietary, but modifying the LGPL library itself requires releasing those changes under LGPL.
☐ Identify whether modifications or integrations qualify as derivative works.
☐ Map licence obligations (copyleft vs permissive).
☐ Assess linking method (static vs dynamic).
☐ Retain attribution and licence notices.
☐ Review patent clauses (Apache).
☐ Document compliance in project governance.
Bottom line: The definition of derivative works in software is not uniform. Copyleft licences expand obligations, while permissive licences narrow them. Careful architectural and contractual planning is essential to avoid unintended licence contamination.
Disclaimer: This note is for informational purposes only and does not constitute legal advice. Readers should consult qualified legal professionals to address specific circumstances and jurisdictional requirements.