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.
|Non-Linux FOSS: libnotify, OS X Style||Jun 18, 2013|
|Containers—Not Virtual Machines—Are the Future Cloud||Jun 17, 2013|
|Lock-Free Multi-Producer Multi-Consumer Queue on Ring Buffer||Jun 12, 2013|
|Weechat, Irssi's Little Brother||Jun 11, 2013|
|One Tail Just Isn't Enough||Jun 07, 2013|
|Introduction to MapReduce with Hadoop on Linux||Jun 05, 2013|
- Containers—Not Virtual Machines—Are the Future Cloud
- Non-Linux FOSS: libnotify, OS X Style
- Lock-Free Multi-Producer Multi-Consumer Queue on Ring Buffer
- Linux Systems Administrator
- RSS Feeds
- Introduction to MapReduce with Hadoop on Linux
- Validate an E-Mail Address with PHP, the Right Way
- Weechat, Irssi's Little Brother
- Tech Tip: Really Simple HTTP Server with Python
- New Products
- Poul-Henning Kamp: welcome to
1 hour 6 min ago
- This has already been done
1 hour 7 min ago
- Reply to comment | Linux Journal
1 hour 52 min ago
- Welcome to 1998
2 hours 41 min ago
- notifier shortcomings
3 hours 4 min ago
4 hours 41 min ago
- Android User
4 hours 43 min ago
- Reply to comment | Linux Journal
6 hours 36 min ago
9 hours 25 min ago
- This is a good post. This
14 hours 38 min ago
Free Webinar: Hadoop
How to Build an Optimal Hadoop Cluster to Store and Maintain Unlimited Amounts of Data Using Microservers
Realizing the promise of Apache® Hadoop® requires the effective deployment of compute, memory, storage and networking to achieve optimal results. With its flexibility and multitude of options, it is easy to over or under provision the server infrastructure, resulting in poor performance and high TCO. Join us for an in depth, technical discussion with industry experts from leading Hadoop and server companies who will provide insights into the key considerations for designing and deploying an optimal Hadoop cluster.
Some of key questions to be discussed are:
- What is the “typical” Hadoop cluster and what should be installed on the different machine types?
- Why should you consider the typical workload patterns when making your hardware decisions?
- Are all microservers created equal for Hadoop deployments?
- How do I plan for expansion if I require more compute, memory, storage or networking?