This blog post appeared elsewhere in 2013, but the link is now broken, so I revived it here.
It’s cold and flu season, and what better time to try to
eliminate the “viruses” from open source software licensing?
Open source advocates can be pedantic about terminology, and
flame wars about using the right words are tedious. Many in the technology world are put off by
wars of words, because they don’t think they are important. But eradicating the word “viral” from
discussions of open source licensing is long overdue, because this word has
skewed and limited understanding of open source licensing principles.
I have heard several stories about how this term began to be
associated with free software in general, or the GPL in particular, and I
hesitate to repeat any of them because I can’t verify them. But one thing is clear: when people in the
technology business, particularly lawyers, want to describe a class of open
source licenses, they often use the word “viral.” Unfortunately, the word is not only
inflammatory, it is inaccurate. For
lawyers, inflammatory is part of the game, but inaccuracy is a sin.
First, we need to know the right term. There are options: free software, copyleft, reciprocal, hereditary. I have always thought “hereditary” the most accurate, but it hasn’t caught on. So, these days I suggest “copyleft.” A copyleft license is one that requires, as a condition of distribution of software binaries (or in the case of licenses like AGPL, a lower threshold such as making them available via a network), that the distributor make the corresponding source code available under the same licensing terms. A copyleft license “sticks” to the copyright of the software; no matter how many downstream distributions occur, the license terms stay the same. To a lawyer, this is like an “easement” — an encumbrance that runs with title, no matter how many times the property is sold. Copyleft licenses include GPL, LGPL, MPL, EPL, and a smattering of others.
Unfortunately, using the word “viral” to describe this
concept is misleading, and leads to unnecessary fears. In all the years I have been advising clients
in this area of law, the single most significant misconception about copyleft
licenses is due, I think, to the use of this word.
Here is what companies worry about. In GPL discussions,
combining GPL code with other code in a single program is often referred to as
creating a “derivative work.” That is
because GPL says if there is any GPL code in a given program, all of the code
in the program must be made available under GPL. Anything else is a violation of GPL. Companies, with visions of viruses dancing in
their heads, worry that if GPL and proprietary code are combined into a single
program, the GPL licensing terms “infect” the proprietary code, and the
proprietary code is automatically licensed under GPL. The author of the proprietary code then
worries that it will be obligated to provide the source code to its own
proprietary code. This is a software
company’s equivalent of unleashing the big scary monster that hides under the
But this is simply not how copyleft works.
In fact, if a company were to combine GPL and proprietary
code in a way that violates GPL, the result is that GPL has been violated — no
more, no less. What that means, legally,
is that the author of the GPL code may have remedies for violation of GPL, and
if the license is terminated as a result, remedies for unlicensed use of the
GPL software. Both of these,
essentially, are copyright infringement claims.
The legal remedies for a copyright infringement claim are damages
(money) and injunction (stop using the GPL code).
In fact, there is simply no legal mechanism for GPL
“infecting” proprietary code and changing its licensing terms. For software to
be licensed under a particular set of terms, the author has to take some action
that reasonably leads a licensee to conclude that the licensor has chosen to
offer the code under those terms. In
contrast, combining proprietary and GPL code in a single program in violation
of GPL is a license incompatibility — meaning the two sets of terms conflict,
and cannot be satisfied simultaneously. The better analogy for this kind of
licensing incompatibility is a software bug, rather than a software virus. Just think of the robot on the old TV show Lost in Space flailing his arms and
saying “DOES NOT COMPUTE,” and you get the idea.
For the law geeks (me included), I should explain that I
have long been on alert to find any formal legal underpinnings for the “virus”
model. The only ones I have found are Pickett v. Prince, 207 F. 3d 402
(7th Cir. 2000) and Anderson v. Stallone, 11 USPQ2D 1161 (C.D. Cal.
1989). Both of these cases discuss the
principle that an unauthorized derivative work is not entitled to copyright
But these cases both involve very different facts from your
typical GPL compliance problem. First,
in each of these cases, the infringing derivative work arguably did not meet a
threshold level of creativity necessary for legal protection. The law sets this
threshold very low. Any self-respecting blob of proprietary code would easily
meet this threshold. Second, in each of these cases, the putative owner of the
infringing derivative work was trying to sue the author of the infringed
underlying work — something that requires a fair amount of good-old-fashioned
chutzpah. These facts cannot reasonably be extrapolated to the situation where
the developer of a proprietary software module, which has been inappropriately
combined with a GPL software module, tries to enforce its rights in the
proprietary code standing alone, against a third party. The analog would be where a proprietary
developer takes a blob of GPL code, changes one line of it, then sues the GPL
author for copyright infringement — which would be nonsense. In other words,
this legal construct “does not compute.”
So, let’s dispense with this idea once and for all. Meanwhile, drink plenty of fluids, keep the tissues handy, wash your hands regularly, and we can win against the viruses.