The Viral Clause: Why the GPL Requires Derivative Works to Be Open Source, but the MIT License Does Not

A software developer deciding to import an open-source package faces a choice that dictates what they can actually do with the resulting application, and when they next get to distribute it. The moment a proprietary codebase links to an external library, the legal framework governing that library attaches to the project. The software industry often markets "open source" as a unified concept, but the reality is a strict legal bifurcation between permissive licenses that allow developers to commercialize their work and copyleft licenses that force them to share it. The distinction rests entirely on a few paragraphs of legal text that trigger when a developer decides to ship their code to the public.[1][2]

The Massachusetts Institute of Technology released the MIT License in 1988 to solve a specific problem: how to share academic software without imposing downstream legal burdens. The resulting document is famously brief. At just 172 words, it grants anyone the permission to "use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software." The license imposes exactly two requirements: the original copyright notice and the permission notice must remain intact in all copies. A developer can take an MIT-licensed library, embed it in a closed-source commercial product, and sell it without ever revealing their own source code.[2][4][6]

The GNU General Public License (GPL), currently on version 3.0 published in June 2007, operates on an entirely different mechanism. Authored by the Free Software Foundation, which was established in 1985, the GPL is a "copyleft" license. It grants users the freedom to run, study, and modify the software, but it attaches a viral condition to distribution. Under Section 5 of the GPLv3, if a developer creates a "derivative work" based on a GPL-licensed component and distributes it, they must license the entire resulting work under the GPL. They cannot keep their additions proprietary.[1][7]

"Copyleft is triggered by distribution and creating a derivative work; therefore, companies must be careful of engaging in these two acts," writes Theresa Gue in the University of Illinois Journal of Law, Technology, & Policy. The mechanism is designed to prevent corporations from enclosing open-source commons. If a company modifies a GPL program for internal use only, the viral clause remains dormant. The obligation to release the source code only activates when the software is conveyed to a third party outside the organization.[5]

The tension in the software industry centers on the legal definition of a "derivative work." The GPLv3 text states that if you convey a work based on the program, you must license the entire work "as a whole" to anyone who comes into possession of a copy. But modern software development rarely involves copying and pasting source code directly. Instead, applications dynamically link to external libraries, calling their functions at runtime while keeping the files separate on the disk.[1][5]

Whether dynamic linking creates a derivative work remains a heavily contested legal question. The Free Software Foundation argues that linking a proprietary application to a GPL library creates one single combined program, thereby triggering the copyleft clause across the entire codebase. Many corporate lawyers disagree, arguing that an application communicating with a library through standard interfaces remains a separate work under United States copyright law. Because courts have rarely tested this specific boundary, enterprise development teams often ban GPL components entirely to avoid the risk of forced open-sourcing.[1][5]

The MIT License bypasses this ambiguity entirely. Because it explicitly permits sublicensing and does not contain a share-alike clause, the legal definition of a derivative work is irrelevant to downstream users. A company can statically link, dynamically link, or directly modify MIT-licensed code without risking their proprietary intellectual property. This legal certainty has driven the massive adoption of permissive licenses in modern web development ecosystems, where a single application might pull in 500 different dependencies.[2][3]

The software industry is not abandoning copyleft, but it is isolating it to specific layers of the stack. Infrastructure projects, such as the Linux kernel, continue to rely on GPL version 2.0 to ensure that hardware manufacturers contribute their modifications back to the community. However, at the application layer, permissive licenses have become the default standard. Developers want the utility of open-source components without the legal overhead of tracking distribution triggers and derivative work boundaries.[1][2]