FREE SOFTWARE: PATHS OF CO-EXISTENCE
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.
Summary
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?
