Understanding the GPL and "Copyleft"

---

In the last article I discussed the basic principles of copyright and how they related to software licenses such as the GPL and the LGPL. This time, let's examine the interaction between "open source" and "free software" licenses. Specifically, how can the potential incompatibility between different licenses affect your own development work?

License or Contract?

The GNU General Public License (GPL) is probably the most well-known of the "free software" licenses. There are two versions of the GPL still in use today: GPLv2 and GPLv3. (There is also the "Lesser" GPL or LGPLv2 and LGPLv3, which are commonly used for libraries and slightly modify the terms of their corresponding GPL versions.) The goal of these licenses is to promote "copyleft"--i.e., the idea that source code must be made freely available to anyone who wishes to use, modify, or redistribute a piece of GPL-licensed software.

Although styled as a "license," several courts in the United States have said the copyleft objectives of the GPL make it a "contract" that imposes obligations beyond the scope of a normal copyright license. For example, a federal judge in California recently held that U.S. copyright law did not prevent a third-party beneficiary under the GPL from asserting a breach of contract claim in state court. This case, Software Freedom Conservancy v. Vizio, Inc., involves allegations that the manufacturer of a "smart TV" used software licensed under the GPLv2 and LGPLv2 but did not release the full source code to the third party upon request, as required by the licenses.

The manufacturer argued the case should have been dismissed because only the copyright holder--i.e., the original developers of the software--can sue for infringement under United States law. But the judge rejected that view, noting the GPLv3 and LGPLv3 expressly created a right for third parties to "receive source code," which actually goes against the traditional function of copyright, i.e., "to limit who may reproduce" a protected work.

What You Need to Know Before "Mixing" Software Licenses

Looking at the GPL and LGPL as contracts also helps to illustrate the concept of license incompatibility. A contract imposes certain obligations on the parties to that agreement. If either party subsequently acts in a manner that violates these obligations, they may be found in breach of the contract.

The GPL itself is quite a lengthy document--more than 5,600 words--and most software developers are not trained to read or understand legal "code." But the basic idea is simple enough: If you receive any code licensed under the GPL and choose to modify and redistribute it in any way, you must also release the source code for your modifications.

The GPL is meant to prevent the use of licensed code in "proprietary" applications, i.e., software where the developer only makes an executable binary or "object code" available to users without the accompanying source code. And if you ask many "free software" advocates, they would likely tell you they want to create a world where all software is exclusively licensed under GPL terms in this manner.

Of course, that isn't the world we live in. Many developers choose to license their software under terms that do not impose any significant reciprocal obligations on subsequent users. Such "permissive" licenses like MIT and Apache typically require little more than including a notice confirming the original developer's copyright in their code. Otherwise, the recipient is free to do whatever they wish with the licensed code--including using it in a proprietary application.

So what happens when you mix GPL and non-GPL code? According to the terms of the GPL, you still have to follow all of the rules applicable to its license. Otherwise the other license may be considered "incompatible." Likewise, if the other license includes its own additional restrictions, that too could make it incompatible with the GPL.

Keep in mind, license incompatibility may be claimed by the Free Software Foundation--the authors of the GPL--but that doesn't mean these issues have been heard or decided by a court. Still, as a developer you probably want to act in good faith and not combine GPL-licensed code with another license where incompatibility has been alleged. You also need to consider that if you adopt a license that potentially conflicts with the GPL, that will discourage others from using or incorporating any changes you have made to GPL-licensed code.

But what actually creates incompatibility? In many cases it may be seemingly trivial language. For example, older versions of Python--we're talking 1.6 through 2.1--had a license that stated its terms were governed by the laws of the State of Virginia. The FSF considered that incompatible with the GPL, which does not contain any such provision. (Modern Python is released under the Python Software Foundation license, which is considered GPL-compatible by the FSF.)

Other grounds that the FSF has identified as creating GPL incompatibility include:

• requiring users to obtain separate permission from the original authors before redistributing software;
• prohibiting users from selling copies of software (or limiting the price they can charge for such copies);
• limiting the use of software to certain types of organizations or purposes; and
• the terms of the license are so vague that GPL compatibility cannot be readily ascertained.

You'll note in this list the item that says the GPL does not limit your ability to charge for copies of software developed using GPL-licensed code. Indeed, contrary to what many people believe, a "free software" license does not require you to give away your work. Nor does it prohibit you from developing commercial applications based on your work. In the next article, I'll explain this subject in greater detail, including why some software--like PyQt and Qt itself--are distributed under "dual" licensing schemes.