GPL Rules: Lessons from the Sandbox

Robert Fulghum’s essay, “All I Really Needed to Know, I Learned in Kindergarten,” teaches us that we can learn some valuable lessons from the sandbox: Share everything. Play fair. Don’t hit people. Put things back where you found them. Clean up your own mess. Don’t take things that aren’t yours.

If only these simple childhood rules could apply to the universe of software licensed under the General Public License, or GPL.

In the GPL universe, “Activities other than copying, distribution and modification are not covered by this license; they are outside its scope.” But almost everything that a software developer does with software invariably involves one of these activities. Does this mean that any modifications made by any software developer must be shared with the world?

Share Everything

Actually, the GPL does not require developers to share every modification. The GPL avoids that by making it clear in its FAQ that developers “are free to make modifications and use them privately, without ever releasing them.” (Let’s ignore for now the legal issue of whether a side document like the FAQ can be properly imported into the contract/license that is the GPL).

This applies to organizations too. An organization can make a modified version and use it internally without ever releasing it outside the organization.

Play Fair. Don’t Take Things That Aren’t Yours

The flip side is that once you release or distribute your modifications to the GPL-ed software, you are no longer free to do whatever you like. “If you distribute copies … you must give the recipients all the rights you have. You must make sure that they, too, receive or can get the source code. And you must show them these terms so that they know their rights.”

That is the quid pro quo for using GPL-ed software. The GPL requires that “you must cause any work that you distribute or publish, that in whole or in part contains or is derived from the Program or any part thereof, to be licensed as a whole at no charge to all third parties under the terms of this license.” This is commonly called the “copyleft” provision of the GPL, where copyright law is used to “guarantee your freedom to share and change free software.”

Rules of Distribution

The GPL considers it distribution if it involves “third parties.” Organizations can make a modified version internally without releasing the source code. But companies and individual developers, especially those working as independent contractors, need to understand what constitutes “distribution,” who are “third parties” and what constitutes using the software “internally” to avoid triggering the distribution clause (unless they don’t care if the program is freely distributed, ofcourse).

Let’s examine some scenarios:

Some began to wonder if MySQL, a popular open source database providerconsidered to be strongly committed to the GPL, was rethinking that commitment based on this language published on its Web site: “When your application is not licensed under either the GPL-compatible Free Software License … or approved by the OSI, and you intend to distribute MySQL software (be that externally to customers or internally within your organization), you must obtain a commercial license to the MySQL product.” Enough users complained to cause MySQL to remove the language from its Web site.

Thus, the independent contractor may find himself trapped between a rock and a hard place if he needs to maintain proprietary control over the code. Agreeing that the project is “work for hire” means losing ownership rights in relation to the hiring company; but choosing to retain his copyrights may result in losing his proprietary rights to the software.

From the company’s perspective, if the exchange of its modified software with its independent contractor, even if they work onsite, would invoke the “distribution” clause, a possible solution might be to outsource the work to independent contractors who reside in jurisdictions outside the U.S., which have different copyright rules.

However, the FAQ provides that the GPL allows the development of a modified version under a NDA where you (a) “agree not to release your changes until the client says ok” or (b) “release your changes to the client under the GPL but agree not to release them to anyone else unless the client says ok.” Both cases are permitted because no GPL-covered code is being distributed under an NDA. However, if there is an exchange of GPL-covered code between the company and an independent contractor, arguably, distribution might already have taken place under the NDA.

What if someone steals your code? If someone steals your modified version of GPL-ed code, technically it is distribution of your version. Someone once called the GPL a grand trade secret scheme. Under trade secret law, one must take reasonable measures to maintain secrecy. Once a secret is lost, it is lost forever. There is no reason why this should be different for GPL-ed code since you are allowed to keep your modifications to yourself without disclosing them. However, once theyare released, not only are the trade secrets therein lost, but so is the ability to apply restrictive licenses.

Not Child’s Play

Fulghum’s sandbox rules are generally consistent with the GPL — play fair and don’t take what’s not yours. However, under the GPL you can take what’s not yours as long as you play by the GPL rules. As long as you don’t distribute it, you can do whatever you like with GPL-ed code. But if you ever release such code, you must share with others or not play at all. So be sure you are not distributing if you intend to maintain control of the modified code.

The GPL is not child’s play. If you don’t fully understand the complexities of every potential distribution scenario, you may suffer the pitfalls of inadvertent distribution.

Beyond the sandbox in the GPL universe, we need a new set of rules:

Once the cat is out of the bag, there is no putting it back again.