GPL: Viral Infection or Just Your Imagination?

Most of us are afraid of getting infected with a virus, whether it comes from a common cold or an attachment in our e-mail. Are open-source licenses viral in nature? Can they infect downstream users? The question is the subject of considerable debate.

Companies refer to open-source software as “potentially viral software” in the end-user licenses that accompany their proprietary software. The end-user license includes limitations against using the proprietary software with open-source licensed software. On the other hand, advocates of open-source licensing argue that drafters of those end-user licenses have a vested interest in creating fear of using open-source software.

Just as a computer virus cannot jump out and infect a person, license terms that apply to one software program cannot simply jump to another software program.

The viral nature of open-source licensing nearly always applies to the General Public License. This is in part due to the terms of the GPL and also partly due to the position statements made by the authors of the GPL.

Constraints Against Constraints

The GPL contains “constraints against constraints.” For example, section two of the GPL allows for modifications and distribution of a GPL-licensed work if the licensee causes any work to be licensed as a whole at no charge to all third parties under the terms of the GPL. This is often problematic for companies that need to distribute their products using a license that is not consistent with the GPL.

Such a company might worry that GPL license terms would spread from GPL software to its developed software and prevent the company from licensing under a proprietary license or other license inconsistent with the GPL.

The downstream constraint against restraints is intentional. The authors of the GPL — the Free Software Foundation, or FSF — think of it as freeing the software. The FSF position is that all software should be “free software.” It should be licensed such that it is freed for all who might encounter it without constraints.

The only exception is a necessary constraint against downstream recipients adding their own constraints to the license terms. The FSF refers to this as “copyleft.” Those same authors also argue that all software should be licensed under such free software licenses because it is morally wrong to do otherwise.

It is worth noting that any license-propagation capability of the GPL is also a capability of any other software copyright license — and any copyright license, for that matter.

Making Derivative Works

The copyright laws give an author exclusive rights to make derivative works. Creating a derivative work is a copyright infringement absent some license from the author — or current copyright holder — of the original work. For example, suppose I wrote a screenplay from a book, and then a movie made from my screenplay was shown in a theater. The screenplay is a derivative work of the book, and the movie is a derivative work of the screenplay.

Each of those derivative works and the public display of the movie in the theater must be licensed — else they would be copyright infringements of the rights of each upstream contributor. Depending on the license I obtained, distribution of my screenplay could be constrained.

For example, suppose I obtained a license from the book copyright holder requiring me to pay a certain royalty and to limit public display of the work on Sunday. The limitations would apply to me and to all downstream licensees — the movie studio that licensed my screenplay subject to the book license and the theater that licensed the movie from the studio for public display.

As should be apparent from the above example, the movie is not “infected” by the book license; that is just the way licensing works.

Trade Secrets and Contracts

Software is no different. If I create software that is a derivative work of your software, I need a license from you to copy and distribute my derivative work. However, if my work is not a derivative work under copyright laws, you have no right to exclude me from copying and distributing my software, so I do not need a license.

Of course, you might have some other ways to limit my actions, such as a trade secret right or a contractual right. Contractual limitations that reach beyond copyright rights are common in software license contracts. For example, the shrink-wrap contract might include a license to use a software package but preclude reverse engineering or require other limitations that one party might impose with the other party’s consent.

For contractual limitations to apply to a software user, the user must have assented to the contract. Notably, the GPL and many other open-source licenses are not contracts requiring assent, but rather are licenses granted.

What Does It All Mean?

What does all this mean to someone about to invest in developing a complex software system that is to be marketed under the business model of the developer’s choosing? If the software system is a derivative work of a prior work owned by another, a copyright license to the prior work is needed.

If the software system is not a derivative work, a copyright license is not needed unless there is some other relationship between the parties that creates other obligations. This is true regardless of the nature of the licenses obtained for the prior work. This is also true regardless of the opinions of the author of the prior work.

Contrary to what some operatives might want us to think, the GPL and other open-source licenses do not have some special magic feature that allows them to infect other software. They have license limitations that apply to derivative works, just like any other copyright license.

If the license limitations are not acceptable, whether it is the GPL or a restrictive end-user license, the choice is to avoid using that software or to negotiate a different license.