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.
Practical Task Scheduling Deployment
July 20, 2016 12:00 pm CDT
One of the best things about the UNIX environment (aside from being stable and efficient) is the vast array of software tools available to help you do your job. Traditionally, a UNIX tool does only one thing, but does that one thing very well. For example, grep is very easy to use and can search vast amounts of data quickly. The find tool can find a particular file or files based on all kinds of criteria. It's pretty easy to string these tools together to build even more powerful tools, such as a tool that finds all of the .log files in the /home directory and searches each one for a particular entry. This erector-set mentality allows UNIX system administrators to seem to always have the right tool for the job.
Cron traditionally has been considered another such a tool for job scheduling, but is it enough? This webinar considers that very question. The first part builds on a previous Geek Guide, Beyond Cron, and briefly describes how to know when it might be time to consider upgrading your job scheduling infrastructure. The second part presents an actual planning and implementation framework.
Join Linux Journal's Mike Diehl and Pat Cameron of Help Systems.
Free to Linux Journal readers.Register Now!
- SUSE LLC's SUSE Manager
- My +1 Sword of Productivity
- Non-Linux FOSS: Caffeine!
- Managing Linux Using Puppet
- Control Your Linux Desktop with D-Bus
- Download "Linux Management with Red Hat Satellite: Measuring Business Impact and ROI"
- Doing for User Space What We Did for Kernel Space
- SuperTuxKart 0.9.2 Released
- Google's SwiftShader Released
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
With all the industry talk about the benefits of Linux on Power and all the performance advantages offered by its open architecture, you may be considering a move in that direction. If you are thinking about analytics, big data and cloud computing, you would be right to evaluate Power. The idea of using commodity x86 hardware and replacing it every three years is an outdated cost model. It doesn’t consider the total cost of ownership, and it doesn’t consider the advantage of real processing power, high-availability and multithreading like a demon.
This ebook takes a look at some of the practical applications of the Linux on Power platform and ways you might bring all the performance power of this open architecture to bear for your organization. There are no smoke and mirrors here—just hard, cold, empirical evidence provided by independent sources. I also consider some innovative ways Linux on Power will be used in the future.Get the Guide