A few months ago I wrote about the dangers of the Microsoft shared-source license (Linux Journal, December 2001, /article/5496), calling the shared-source license a Trojan horse. By merely looking at Microsoft's code, you could potentially “infect” your own software, leaving yourself vulnerable to a copyright infringement lawsuit by Microsoft. A reader responded that I was applying a double standard—that the exact same problem exists with the GPL. “For companies developing traditional proprietary software”, he wrote, “the act of merely looking at GPL code can put them in exactly the same position that they would be in if they looked at Microsoft shared-source licensed code.” Even worse, he claimed, the “infection” clauses of the GPL would require that the entire proprietary work that uses GPL code be licensed under the GPL, or the GPL portion removed. His analysis of the GPL is only partly correct. He is confusing three different scenarios.

1. Suppose a proprietary software company has licensed code under the GPL and then includes the GPL code in its derivative work software. The company has agreed to the GPL license and must honor its terms. A court might impose a “specific performance” remedy requiring the company to distribute the proprietary derivative work, including publishing the source code, under the GPL—typically is referred to as “GPL infection”, but here it was a risk intentionally accepted by the company.

2. Suppose the proprietary software company does not agree to the GPL license but uses the GPL code anyway in its proprietary derivative work. Under the copyright law, the company may be forced to pay damages and to stop using the code in its derivative work, but the remedy of specific performance (e.g., publication of the source code) probably would not be available. This is not GPL infection; it is simply copyright infringement.

3. Suppose an employee of the proprietary software company, without authorization from or knowledge of his or her company, intentionally or otherwise incorporates GPL code into a proprietary derivative work. (In law, if the act is intentional the employee is said to have engaged in a “frolic and detour”.) In this scenario, the company probably will not be liable for willful infringement, although it must stop using the infringing software. Again, there is no GPL infection, merely an infringement.

The creators of proprietary software should indeed exercise caution. Incorporation of someone else's copyrighted code into a software product (even when unintended) can have undesired consequences, including the potential for expensive copyright infringement lawsuits, large damage awards and injunctions against further distribution or sale of the infringing software.

Every company that produces software must engage in safe development practices. That includes making sure that the development staff understands how important it is not to copy someone else's software before reviewing with an appropriately skilled attorney the terms under which that software is obtained. If a company wants to protect the proprietary nature of its software, it must be careful to avoid infection from other proprietary software as well as from free and open-source software. The burden of implementing proper safeguards, including management time spent training staff and securing the workplace—as well as the attorney time to review licenses—are costs of doing business, which must be factored into the price of the software.

These cautions also apply to the creators of open-source and free software. Simply because software is going to be distributed for free doesn't mean that it can't be stopped cold by an infringement lawsuit.

Here are a few safeguards I recommend to my clients:

Obtain a signed copyright assignment or an explicit license for every third-party contribution to your project with language such as the following: “The undersigned author(s) hereby represents and warrants that the software is original and that he/she is the author of the software.”

If contributed software was written by an employee of another company, the express permission of that company to use the software should be obtained. The Free Software Foundation recommends an Employer Disclaimer of Rights that authorizes the employee to assign the software “for distribution and sharing under its free software policies”.

If employees have been exposed to third-party software that is proprietary and whose source code is not available for copying, it may be appropriate to assign the employees to other projects rather than risk an infringement (or theft of trade secrets) lawsuit.

As a lawyer, it is my duty to be cautious and to warn of risks. But as an advocate of free and open-source software, I also want to back off from sowing fear, uncertainty and doubt (FUD) more widely than is reasonable.

The goal of open-source development is to encourage the sharing of code and to avoid secrecy. Developers of proprietary software may need to be cautious about being exposed to other companies' source code, but the developers of free and open-source software should copy freely from other free and open-source software—within the constraints of the contributors' licenses. The result will be better software for all.

Legal advice must be provided in the course of an attorney-client relationship specifically with reference to all the facts of a particular situation and the law of your jurisdiction. Even though an attorney wrote this article, the information in this article must not be relied upon as a substitute for obtaining specific legal advice from a licensed attorney.