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.
Fast/Flexible Linux OS Recovery
On Demand Now
In this live one-hour webinar, learn how to enhance your existing backup strategies for complete disaster recovery preparedness using Storix System Backup Administrator (SBAdmin), a highly flexible full-system recovery solution for UNIX and Linux systems.
Join Linux Journal's Shawn Powers and David Huffman, President/CEO, Storix, Inc.
Free to Linux Journal readers.Register Now!
|Secure Desktops with Qubes: Introduction||May 27, 2016|
|Chris Birchall's Re-Engineering Legacy Software (Manning Publications)||May 26, 2016|
|ServersCheck's Thermal Imaging Camera Sensor||May 25, 2016|
|Petros Koutoupis' RapidDisk||May 24, 2016|
|The Italian Army Switches to LibreOffice||May 23, 2016|
|PeaZip||May 20, 2016|
- Download "Linux Management with Red Hat Satellite: Measuring Business Impact and ROI"
- Chris Birchall's Re-Engineering Legacy Software (Manning Publications)
- The Italian Army Switches to LibreOffice
- Linux Mint 18
- Petros Koutoupis' RapidDisk
- ServersCheck's Thermal Imaging Camera Sensor
- Oracle vs. Google: Round 2
- The FBI and the Mozilla Foundation Lock Horns over Known Security Hole
- Privacy and the New Math
Until recently, IBM’s Power Platform was looked upon as being the system that hosted IBM’s flavor of UNIX and proprietary operating system called IBM i. These servers often are found in medium-size businesses running ERP, CRM and financials for on-premise customers. By enabling the Power platform to run the Linux OS, IBM now has positioned Power to be the platform of choice for those already running Linux that are facing scalability issues, especially customers looking at analytics, big data or cloud computing.
￼Running Linux on IBM’s Power hardware offers some obvious benefits, including improved processing speed and memory bandwidth, inherent security, and simpler deployment and management. But if you look beyond the impressive architecture, you’ll also find an open ecosystem that has given rise to a strong, innovative community, as well as an inventory of system and network management applications that really help leverage the benefits offered by running Linux on Power.Get the Guide