Allocation of the Risks
A license serves to allocate risks between the licensor and the licensee; it is an essential purpose of license warranty provisions. The BSD license, for example, contains the following clause:
This Software is provided by the copyright holders and contributors “AS IS” and any express or implied warranties, including, but not limited to, the implied warranties of merchantability and fitness for a particular purpose are disclaimed. In no event shall the copyright owner or contributors be liable for any direct, indirect, incidental, special, exemplary, or consequential damages (including, but not limited to, procurement of substitute goods or services, loss of use, data, or profits, or business interruption), however caused and on any theory of liability, whether in contract, strict liability, or tort (including negligence or otherwise) arising in any way out of the use of this software, even if advised of the possibility of such damage.
The important thing to notice is all risks under the BSD license are borne by the licensee. No matter how dreadful the software, no matter what damage it causes to your computer or your business, no matter what promises the licensor advertised about the usability or functionality of the software, the licensee accepts the software “AS IS” without any warranty.
All other open-source licenses I've read contain similar disclaimers. The licensee bears all the risks associated with using the software and creating derivative works from it.
I think the above is a fair allocation of risks, except for one risk that isn't expressly mentioned in the BSD license: the risk that the licensor isn't authorized to grant the license to the software in the first place. The BSD license (because of the “including, but not limited to” language) excludes this warranty of non-infringement.
Without a warranty of non-infringement, if the licensor doesn't actually own the copyright to the software he or she licenses or isn't acting under the authority of a license from someone who does own the copyright, the licensee, not the licensor, is accepting the risk of a lawsuit for copyright infringement when he or she accepts the software.
Here's how I corrected that problem in a new license I'm writing called the Academic Free License:
Licensor warrants that the copyright in and to the Software is owned by the Licensor or is distributed by Licensor under a valid current license. Except as expressly stated in the immediately preceding sentence, the Software is provided by the Licensor, distributors and copyright owners “AS IS”, without warranty of any kind, express or implied, including but not limited to the warranties of merchantability, fitness for a particular purpose and non-infringement. In no event shall the Licensor, contributors or copyright owners be liable for any claim, damages or other liability, whether in an action of contract, tort or otherwise, arising from, out of or in connection with the Software.
In the first sentence of that warranty clause, the Academic Free License allocates the risk of copyright infringement to the licensor rather than to the licensee. Between the licensor and the licensee, I'm convinced that the licensor is in a far better position to know whether he owns the copyright or has the software under a license that allows him to license it to others. The licensee, on the other hand, has no information on which to base a decision whether to accept the risk of copyright infringement. The Academic Free License, therefore, allocates that risk to the only party capable of determining the degree of risk.
For example, if the licensor knows he wrote the software himself, he owns the copyright. But if he merely copied the software from someone else or created the software while working as an employee of another company, he cannot honestly warrant against non-infringement.
Licensees may be unwilling to accept open-source software without some assurance from the licensor that they are not infringing. The absence of such assurances may inhibit the acceptability of open-source software. With a warranty of non-infringement, like the one I wrote for the Academic Free License, licensees can rely reasonably on the license language to protect themselves from accusations that they didn't care about who actually holds the copyright.
What would happen if the licensor gave that warranty of non-infringement but didn't actually own the copyright or didn't actually have a valid license to distribute the software? Damages for breach of warranty can be substantial. In appropriate situations, a licensee can recover for any loss resulting from the breach, the difference between the value of the software accepted and the software delivered, and even incidental and consequential damages.
I'm interested in your thoughts about whether open-source licenses should include warranties of non-infringement of copyright. Please send your comments via e-mail to firstname.lastname@example.org. I'll report on the results of this informal survey in a later column.
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.
|Where's That Pesky Hidden Word?||Aug 28, 2015|
|A Project to Guarantee Better Security for Open-Source Projects||Aug 27, 2015|
|Concerning Containers' Connections: on Docker Networking||Aug 26, 2015|
|My Network Go-Bag||Aug 24, 2015|
|Doing Astronomy with Python||Aug 19, 2015|
|Build a “Virtual SuperComputer” with Process Virtualization||Aug 18, 2015|
- A Project to Guarantee Better Security for Open-Source Projects
- Concerning Containers' Connections: on Docker Networking
- Problems with Ubuntu's Software Center and How Canonical Plans to Fix Them
- My Network Go-Bag
- Firefox Security Exploit Targets Linux Users and Web Developers
- Doing Astronomy with Python
- Build a “Virtual SuperComputer” with Process Virtualization
- diff -u: What's New in Kernel Development
- Three More Lessons
- Calling All Linux Nerds!