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 bed.
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 protection.
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.
