With the noise about the likely to fail GPL 3.0, it is easy to forget that we are still dealing today with existing GPL and its infectious brethren. The issue for those licenses is: can other software coexist with free and open source licenses? The answer is yes, but only with care.

FSOS approaches are defined by a philosophy implemented in licenses. Some FOSS licenses merely implement that approach as to their own code, but others force their terms (and philosophy) on third party software. These "viral" or "infectious" licenses undermine coexistence.

Coexistence implies two or more persons or products being together in the same place or system peacefully despite their differences. For software, it entails being able to have software that interacts with, or uses, FSOS software despite differences in licensing philosophy and approach. But coexisting with free and open source software entails coping with FSOS license terms in each license used in a system.

Many open source licenses make this easy because they are permissive, like the BSD license. Permissive licenses approximate openly dedicating the code to the public domain. They should be philosophically preferred.

Other licenses are pass-through. In a pass-through license the terms must be passed through to only as to the original licensed material. License terms for new material are at the option of the party who adds the material.

Then there are the viral licenses. These are the most restrictive. They provide that, in defined circumstances, a licensee's use is conditional on applying the license to the original work and to new code. The GPL claims: "To protect your rights, we need to make restrictions ... These restrictions translate to certain responsibilities for you ...." Shades of the novel: 1984.

Let's look at paths of coexistence with viral licenses.

Path 1: End user modification
Since current licenses do not impose terms on end user modifications, end users are safe today. Distributors can distribute works that are not derivative of an FSOS work, but that enable the end user to create a derivative for its use.

Path 2: Distributing non-expressive elements
Viral provisions often are limited to works that are copies or derivative works of the original. A path to coexistence is to design software distributed in a manner that does not contain expression of the original work.
This may seem trivial, but the most valuable aspects of software are often not protected expression. Ideas and approaches are not copyrighted expression. Thus, code extracted from another's work is not expression if it fits one of three characteristics:

  • What is used is so abstract or so changed from the original that it simply uses the unprotected idea, rather than the expression.
  • What is used is so narrow and related to machine functions that it is merged with the function and an unprotected process.
  • What is used is found in so many unprotected works that it does not constitute expression.

Path 3:Distribution outside the scope
Viral licenses impose their terms only on code that connects to the free software in a particular way. Avoiding that particular connection avoids the viral effect.
For example, viral terms often cover "derivative works." This is a copyright law term. A work is not a derivative work unless it contains expression from the work from which it allegedly derives. It is not a derivative work simply because it interacts with the other work or uses ideas from it, regardless of how the links or other connection occurs technically.

Path 4: Relying on exceptions
One can also rely on exceptions from the owner of the copyright or obtain a separate agreement devoid of FOSS restraints. The task is to identify sources of code and to obtain clearance from that source. Free software licenses are private documents. The person who controls the copyright can grant broader rights or exceptions. In fact, many FOSS programs are dual licensed - available with and without viral terms.
The most significant exception deals with the Linux kernel. Torvalds made clear early that the viral terms of GPL did not apply to applications operating in "user space" even though those applications made calls to or otherwise linked with the operating system kernel.

Path 5:Distancing strategies
A distancing strategy places valuable code in a safe harbor, even if other code is used to link to it and, perhaps, constitute a derivative work. The connecting code is "sacrificed code" that may fall under viral terms. Whether, as distributed, the code constitutes a derivative work does not matter, so long as the interaction between it and the "Protected Program" falls into a safe harbor of permitted coexistence.

So, there are ways around the threat to coexistence. But I wonder why they are needed. Why does a movement that refers to itself as free and open, try to impose restrictions on others to act freely or openly?

Written By:Jay Godse On July 3, 2008 10:32 AM

This is a thought-provoking article. I have a few questions.

1) Is the term "derivative work" used in copyright law different from the term "derivative work" used in licenses such as GPL?

2) You say that Linus Torvalds made an exception for Linux user-space applications linking to kernel or system calls. Can you point me to a web URL that describes that exception (perhaps by a blog posting if you prefer)?

3) The distancing strategies using a safe harbor is interesting because it provides vendors of proprietary software more opportunity to use GPL software without having to expose their software. I have heard of it before, but never from a legal expert. Can you point me to any URLs that talk about this (perhaps in another blog posting if you prefer)?

I have published a page at describing other aspects of managing software IP. This is a good complementary site.

Written By:Jeffrey Bolden On March 17, 2011 2:54 PM

>> So, there are ways around the threat to coexistence. But I wonder why they are needed. Why does a movement that
>> refers to itself as free and open, try to impose restrictions on others to act freely or openly?

Because you are confusing free as in beer with free as in freedom. To quote Richard Stallman, "The fundamental difference between the two movements is in their values, their ways of looking at the world. For the Open Source movement, the issue of whether software should be open source is a practical question, not an ethical one. As one person put it, 'Open source is a development methodology; free software is a social movement.' For the Open Source movement, non-free software is a suboptimal solution. For the Free Software movement, non-free software is a social problem and free software is the solution."

Or to choose the very definition:

Free software is a matter of the users' freedom to run, copy, distribute, study, change and improve the software. More precisely, it means that the program's users have the four essential freedoms:

The freedom to run the program, for any purpose (freedom 0).
The freedom to study how the program works, and change it to make it do what you wish (freedom 1). Access to the source code is a precondition for this.
The freedom to redistribute copies so you can help your neighbor (freedom 2).
The freedom to distribute copies of your modified versions to others (freedom 3). By doing this you can give the whole community a chance to benefit from your changes. Access to the source code is a precondition for this.

"non viral" licenses would result in software that violated all 4 of those freedoms. In what way does that advance the movement? The "users" of free software are not just the 2nd tier down but every tier thereafter. When MIT released the "free" X server in the 1980s under the "free" MIT license (a non viral license) X was effectively closed. The actual X's that ran on Unix desktops were all proprietary and the MIT X consortium code was simply a code base to make operating system writers have a good reference code base to start from. Which forced another whole free software project (XFree86) to be created for users to genuinely have a free X server.