The GNU project’s Four Freedoms present the essential components of Free software: freedom to use the program for any purpose, freedom to study and change the program’s source code, freedom to redistribute the author’s version of the code, and freedom to distribute your modifications. While not everyone who publishes their source code for others to use cares about freedom as the FSF defines it, these principles also motivate common open-source licenses. This post will discuss a surprisingly common obstacle to software freedom and show how you can avoid it in your own projects.​ Most open-source licenses are designed to ensure freedom. However, some developers insist on publishing their work under licenses that start from a well-known license and tack on some behavioral incentives. These certainly don’t actually prevent software users from engaging in the proscribed behaviors; rather, they just prevent people — even those who are unlikely to be affected by the behavioral incentives — from using these projects. These clauses are essentially flourishes of ego, pauses for laugh lines that are intended to force us to stop and acknowledge how clever the author is. It’s not funny, though, that projects distributed under these novelty license agreements — and projects that depend on libraries so distributed — are unavailable to any users or developers who care about freedom (or those who care about the liability induced by vague contractual terms).

Some examples

Probably the most infamous example is the JSON.org license, which adds “This Software should be used for Good, not Evil” to the MIT license, and which Douglas Crockford apparently intended as a joke about the absolutist moral language used to promote Bush-era foreign policy. (One must note that this joke was almost stale when he wrote the license in 2002; it certainly appears dated in 2014, now that American drone killings have been full of sophisticated nuance for years.) I can’t imagine that this clause has prevented anyone from doing evil with serialized Javascript objects; rather, it just motivated attorneys to ask for exceptions to the license, forced other developers to eschew Crockford’s library, and inspired wheel-reinvention.

A more insidious example is the long-abandoned (but surprisingly ubiquitous) Colt library, which bundles an old fork of the FreeHEP AIDA library that was apparently initially distributed under the LGPL with usage restrictions. Since Colt isn’t compatible with the current upstream AIDA interfaces and since the usage restrictions make the license for Colt non-free, there is no way to include Colt or projects that require it in Fedora. (As an aside, you obviously can’t add usage restrictions when redistributing something originally licensed under the LGPL; additional restrictions are incompatible with the LGPL. If your goal is to distribute a new work with usage restrictions, the LGPL is probably an inappropriate starting point.)

Finally, Haïkel Guemar reminds me of an especially silly software license, which allows completely unrestricted rights to everyone except Richard Stallman. Stallman, however, is explicitly prohibited from using the software for any purpose. (I’m sure Stallman is heartbroken that he’s unable to use a toy 6502 assembler.)

Conclusions

Behavioral incentives and other morality clauses have no place in open-source licensing. (Put another way, if you can’t use the software for any purpose, why do you care whether or not you can distribute derivative works?) If you care about making your work freely available, you should recoil at behavioral incentives in putatively open-source licenses in the same way you’d be horrified by:

  1. proprietary licenses for development tools that prohibit you from working on certain kinds of software,
  2. proprietary licenses for systems software that forbid you from talking about how well the system works without clearing it with the manufacturer first, or
  3. laws that make trivial programs illegal if they could be used to circumvent copy-protection measures.

To ensure that anyone can freely use and build on your work, if that is your aim, don’t introduce incentives or morality clauses into your license. License it under a free and open-source license. Use a well-known license with well-understood legal implications; your bespoke license is unlikely to solve any new problems, but is likely to be vague enough to create uncertainty and inhibit adoption of your work. Do not bundle code or libraries distributed under restrictive licenses. (Not bundling code at all is actually a good practice.) Finally, only (transitively or immediately) depend on libraries that are freely licensed.

  fedora, free software, legal, licensing, open source • You may reply to this post on Twitter or