INSTA-LEADS: Our Full-Service B2B Marketing Program Delivers Sales-Ready Leads Click to Learn More!
Welcome Guest | Sign In
ECommerceTimes.com

GPL Rules: Lessons from the Sandbox

GPL Rules: Lessons from the Sandbox

The General Public License does not require developers to share every modification. The GPL avoids that by saying 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).

By Philip H. Albert LinuxInsider ECT News Network
12/24/04 5:00 AM PT

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, of course).

Let's examine some scenarios:

  • Distribution to End Users. This is clearly a distribution outside the organization and, hence, the GPL distribution clause would apply.
  • Distribution to Employees. The FAQ makes it clear that organizations can modify the software internally without being subject to the copyleft provision. The legal justification for this prong under copyright law is that work done by an employee is considered "work for hire" owned by the company, so there is technically no "distribution" to "third parties."
  • Some began to wonder if MySQL, a popular open source database provider considered 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.

  • Distribution by/to Independent Contractors. The GPL could be problematic for independent contractors. U.S. copyright law deems work by independent contractors not to be "work for hire" unless the parties expressly agree in writing that the work will be considered a work made for hire. Independent contractors who retain copyright ownership in their work and install it on customers' or end users' computers invoke the distribution clause and may be required to release their work under the GPL, or at least be required to permit others to do so.
  • 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.

  • Distribution to a Party Bound by a Non-disclosure Agreement. Just because someone has a non-disclosure agreement (NDA) in place doesn't mean you can stop them from disclosing and redistributing your GPL-ed software. This is because under the GPL, you cannot place restrictions on the GPL-ed software (modified or not) that are more restrictive than those imposed by the GPL. An NDA that prevents them from distributing the source code would offend the provisions of the GPL and mean you infringed on the copyright of the original GPL-ed code you derived from, absent having some other license.
  • 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.

  • Distribution to Subsidiaries. The law treats subsidiaries as separate entities even if they are owned by the same parent company. Therefore, any distribution or publication of the modified software to another subsidiary will constitute distribution and invoke the copyleft provisions.
  • 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 they are 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:

  • Your secrets are safe but only with your immediate family (employees), not your extended family (subsidiaries).
  • Do not share your secret, even with your closest friends (independent contractors).
  • Once the cat is out of the bag, there is no putting it back again.


    Phil Albert, a LinuxInsider columnist, is a patent attorney and partner with the San Francisco office of the intellectual property law firm Townsend and Townsend and Crew LLP.


    This story was originally published on October 5, 2004, and is brought to you today as part of our Best of ECT News series.


    Facebook Twitter LinkedIn Google+ RSS
    Salesforce Premier Success Resource Kit
    Tech News Alerts from ECT News Network