Understanding GPL’s “Infectiousness”: Myths, Mechanics, and License Compatibility

Introduction

The GNU General Public License (GPL) is the most widely used open‑source license. When a copyright holder distributes software under GPL, the software is offered to anyone under the same GPL terms. If a developer combines GPL‑covered code with their own code and distributes the combined work without technical isolation, the developer’s code becomes part of a GPL‑covered work and must be licensed under GPL.

What “infectiousness” means

GPL v2 §2 requires that the entire work, including any part derived from the program, be bound by the GPL and be freely usable by third parties. GPL v3 §5 imposes the same requirement on the whole work as a single entity. In practice this means that when the distributed software (the target software) contains both the developer’s code and GPL code, the whole becomes a derivative work subject to GPL.

An explicit exception exists: if the developer’s code is technically isolated from the GPL code (e.g., placed in a separate process, communicated via IPC, or linked dynamically with a clear isolation boundary), the two are treated as independent programs and the developer’s code is not automatically subject to GPL.

Common misunderstandings

It is easy to misinterpret the GPL’s “infectiousness” as a virus that spreads from file to file. The GPL does not examine individual source files; it looks at the overall software product. The “infection” only occurs when GPL‑covered code is linked or combined with other code without isolation, causing the entire combined product to be licensed under GPL.

Essence of infectiousness

The GPL’s primary concern is the license under which the final software is offered to users. If your code links to a GPL file (e.g., fileA) without isolation, the combined set of files (e.g., fileB‑I) forms a single work that must be distributed under GPL, regardless of the license you would otherwise apply to your own code.

To avoid this, you can either:

Introduce technical isolation (separate processes, socket communication, or dynamic linking with a permissive interface).

Replace the GPL component with an independently licensed implementation that provides the same functionality, then link to the replacement.

Typical software composition

Modern applications often incorporate many third‑party components with different licenses (GPL, LGPL, Apache, MIT, BSD, public domain, etc.). If a GPL‑covered component (e.g., componentB) is present alongside other components ( A‑F) without isolation, the entire application must be released under GPL because GPL is the most restrictive compatible license.

To keep the overall product under a more permissive license, the GPL component must be isolated or removed. Isolation can be achieved by:

Running the GPL code in a separate executable and communicating via well‑defined protocols.

Using dynamic linking with a library that has an LGPL or permissive license.

When isolation is in place, the remaining code can be licensed under Apache, MIT, BSD, or a commercial license without violating GPL.

Changing the license in practice

Because “infectiousness” only affects the combined product, you can change the license of future versions by replacing or isolating the GPL component. A real‑world example is the Cygwin project, which switched from GPL to LGPL starting with version 2.5.2, allowing downstream code to remain closed‑source while still using the library.

License changes are not retroactive: previously released versions retain their original license. Courts have upheld this principle. In a 2019 Guangdong case, the court ruled that a version released under GPL v3 could not have the GPL removed retroactively; only later versions could change the license, and only after the GPL‑covered code was removed or all contributors consented.

Conclusion

The GPL’s “infectiousness” does not act like a biological virus. It influences the licensing of the final combined software based on compatibility among the various licenses involved. Understanding that the GPL governs the whole work—not individual files—helps developers decide when to isolate GPL components, how to structure multi‑license projects, and how to manage license changes without violating legal obligations.