Open Source and the Eradication of Viruses

Open Source and the Eradication of Viruses

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 many 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.”

Finally, these cases, even if they stood for the principle that an unauthorized derivative work is not entitled to copyright protection, would mean the proprietary work would be in the public domain, rather than subject to GPL. That is a very scary result indeed -- which fortunately is simply not supported by law.

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 call a win against the viruses.

Sorry we missed you! We close comments for older posts, but we still want to hear from you. Tweet @black_duck_sw to continue the discussion.


AGPL: Out of the Shadows

| Sep 20, 2016

A while ago, I noted the slow but growing use in private business of GPL version 3. In the nearly 10 years since it was released, GPL3 has gained an uneasy acceptance in the technology industry, despite lingering concerns about its unusual patent terms and “Installation Information” requirements. 

| MORE >

Who’s Afraid of GPL3?

| Jan 25, 2013

It’s been almost six years since the release of GPL version 3. During the revision process, which lasted over two years and veered toward walk-away controversies more than once, hundreds of open source enthusiasts -- from the hackers to the fortune 100 -- contributed comments to a major drafting

| MORE >