Unbiased License FUD

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.

Lawrence Rosen
is an attorney in private practice in Redwood City, California
(www.rosenlaw.com). He
is also executive director and general counsel for Open Source
Initiative, which manages and promotes the Open Source Definition
(www.opensource.org).

Trending Topics

Webinar: 8 Signs You’re Beyond Cron

Scheduling Crontabs With an Enterprise Scheduler
11am CDT, April 29th

Join Linux Journal and Pat Cameron, Director of Automation Technology at HelpSystems, as they discuss the eight primary advantages of moving beyond cron job scheduling. In this webinar, you’ll learn about integrating cron with an enterprise scheduler.