Why the Public Domain Isn't a License
The notion of tossing software into the air to be blown about haphazardly by the wind is not entirely frivolous. The image is apt to describe the public domain. Software engineers use the term “public domain” as if it means a place where anyone can do anything they want with software. Public domain software has no owner. Even the government doesn't own it. It is simply “free”, as in the terms “free beer” and “free speech”.
There is such a thing as the public domain, however. In it one can find Bach's sonatas, Shakespeare's plays, the drawings of da Vinci and the design of the Eiffel Tower. These things literally are available for anyone and everyone to use without permission.
Copyrighted works enter the public domain only when they grow old and the copyrights expire. Everything else, including certainly any computer software of recent vintage, is owned by somebody somewhere. It is not “free” for the taking.
The legal monopolies for software under copyright laws last a very long time. Under current law, copyright extends for the life of the author plus 70 years; in the case of pseudonymous or anonymous works or works made for hire, copyright extends for 95 years from the year of first publication or 120 years from the year of its creation, whichever expires first. The software industry is new, so it is rare today to find any important software for which the copyright has expired. (Congress recently extended the length of copyright term in a provision that has been described derisively as a special boon to the Walt Disney Company to protect its copyrights in Mickey Mouse cartoons. That extension has been challenged in the US Supreme Court as inconsistent with the Constitutional objective to grant copyright monopolies in order to encourage the progress of science and the arts.)
Just as there is nothing in the law that permits a person to dump personal property on a public highway, there is nothing that permits the dumping of copyrighted works into the public domain, except as happens in due course when any applicable copyrights expire. Until those copyrights expire, no mechanism is in the law by which an owner of software can simply elect to place it in the public domain.
One exception can be found in section 105 of the Copyright Act. Works written by the US government cannot obtain copyright protection and so are automatically in the public domain. Court decisions and Congressional statutes are obvious examples. However, this exception applies only to works created by employees of the US government and typically not by contractors to the government. University researchers and government laboratories ordinarily own copyrights in their works and can license them to third parties.
For these reasons, the “public domain” solution for free and open-source software is largely irrelevant.
Though there is no useful “public domain” repository of computer software, it is possible for a software creator to give it away. One doesn't have to be a lawyer to craft appropriate language: “This is my software. I hereby give it away to anyone who wants it for any purpose whatsoever.”
Unfortunately, such gifts are illusory. Under basic contract law, a gift cannot be enforced. The donor can retract his gift at any time, for any reason—scant security for someone intending to make long-term use of a piece of software.
This “Give-It-Away” license provides no protection for anyone if the donated software causes harm. Obviously one cannot intentionally give away something he knows to be dangerous; that is criminal behavior. But, neither can one escape a lawsuit because his gift was only accidentally harmful. The risk of such a license is far greater than the warm feelings that enrich the soul of the giver. One important value of a license is the opportunity to disclaim warranties and distribute the software “AS IS”. If you give software away, you may retain a risky warranty obligation.
Notice also that the donor under this “Give-It-Away” license has not placed any restrictions on the gift. For example, a recipient can make secret changes to the donated software and re-release the changed version for a fee under a proprietary license. To many people in the Free Software and Open Source movement, this violates another fundamental objective: the recipients of free or open-source software should abide by the same “published source” rules as the original donor. If recipients distribute the donated software, with or without changes, they should also publish their source code. The “Give-It-Away” license doesn't force reciprocal source code publication. (Neither, for that matter, do the BSD, MIT, Apache and similar software licenses.) If you want to impose conditions on copying or distribution of software—even the minimal set of conditions allowed under the Open Source Definition—you must use a license rather than rely on a gift to the “public domain”.
Caveat emptor. Use the “Give-It-Away” license at your own risk. And don't accept gifts of software presuming they are in the public domain. If you want to give away software for any use whatsoever, use a simple license such as the MIT license.
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