Software Licenses

Licenses which are simple, easy to understand for everyone, and don’t place undue burden on developers or users should be prefered over ones that make heavy use of hard-to-understand legalese and complicated clauses. Licenses that I like fall into two categories: public domain equivalents and permissive:

Public Domain Equivalents

These licenses are designed to make it easy to dedicate a work to the public domain. Some, like the Unlicense, are short and sweet whereas others, like the CC0, are long and full of lawyer-speak. The CC0 is long particularly because it’s designed to work without any additional interpretation required in jurisdictions that don’t allow a person to disclaim all of their rights (such as their moral rights). The Unlicense, on the other hand, requires interpretation of the intent of the licensor in those jurisdictions, though this almost guaranteed to be a non-issue, and is typically not worth worrying about. The CC0 is also additionally useful outside of software projects, whereas the Unlicense is tailored towards software projects.

Other software-specific, public domain equivalent licenses that don’t expressly put a work into the public domain but which are still easy to understand and have the same effect include the MIT-0 and the 0BSD (also known as BSD 0-Clause). These are functionally equivalent to their permissive counterparts but with the attribution requirements removed.

Note that the OSI refuses to approve public-domain licenses (though they have approved both the 0BSD/MIT-0, since they do not attempt to put a work into the public domain directly).

Permissive Licenses

These are licenses that typically allow one to do whatever they wish with a piece of software, provided that they provide attribution. Some licenses, such as the BSD 3-Clause, contain additional measures, though they are typically not onerous (in the case of the BSD 3-Clause, you’re not allowed to use the names of the copyright holders in promotional material for derivatives of the software, for example).

One of the most common permissive licenses is the MIT/Expat license which, along with its counterparts the BSD 2-Clause and the ISC licenses, is very permissive. They all let you do whatever you want with the software provided that you include the original copyright notice and license text in any copy of the source (i.e. credit the authors). They are all functionally equivalent.

CC-BY is the Creative Commons equivalent for non-software works, though it is quite verbose and challenging to read, as expected.

The ISC license is my preferred license since it’s functionally equivalent to the MIT and BSD licenses, but written much more clearly. It’s also shorter because it takes advantage of the fact that nearly every country has signed the Berne Convention to strip out unnecessary language.

A Calm and Collected Rant About the ISC License “Controversy"

The ISC license states:

Permission to use, copy, modify, and distribute this software for any
purpose with or without fee is hereby granted, [...]

Some people mistakenly hold the belief that the word “and” here is problematic, because some morons at the University of Washington tried to interpret it as meaning that you can modify the software, or you can distribute it, but you can’t distribute a modified copy of the software. It would seem to me that UW needs to increase funding for its English department because, last time I checked, “and” did not mean “exclusive or”. To illustrate how utterly idiotic this is: if we take their interpretation at face value, they are also arguing that you could modify the software but not use your own modified version. It’s absolutely absurd and I’m extremely disappointed that people in the FOSS community let UW walk all over them with this (apparently they threatened to sue the FSF, and the fact that they backed down really highlights their uselessness).

In response to input from the FSF and in a nonsensical attempt to avoid this situation from happening in the future, the ISC decided that changing “and” to “and/or” would fix this issue. I highly doubt that they actually spoke to a real lawyer when making this change, given that the use of “and/or” is considered somewhat problematic in legal contexts and, in plain English, saying “I permit you to do X, Y, and Z” carries the same meaning as “I permit you to do X, Y, and/or Z”. You could always do one, some, or all of them.

GNU and the FSF, in their infinite lack of wisdom, still think that this is problematic language and discourage the use of this license. They say nothing about the BSD-0 license even though it has the exact same language. It’s best to ignore them, since they clearly don’t know what they’re talking about.

Also, this controversy happened literally over 20 years ago with no further issues or outcries, even though it took an additional 10 years for the ISC to change the language of the license. So really this is all meaningless and dumb and stupid and there’s nothing wrong with the license.

Copyleft Licenses

I strongly dislike copyleft licenses.

They utterly fail at their stated goal, instead reinforcing copyright as a tool to get one’s way and protect one’s “intellectual property”. This results in much more hassle for developers with no true real-world gain compared to anti-copyright or permissive licenses. Read A Critique of Free Software and Free Software is an Abject Failure for more on this topic and my stance.

Ethical Licenses

These are licenses that attempt to control how one can use software based on the particular prejudices of the author(s). They say things like “this must not be used by corporations that manufacture machines for the purpose of war” or “this software may not be used for evil.” An example is the customizable Hippocratic License and the JSON License.

They are, practically, only useful in the same way Copyleft licenses are useful. That is to say, they might scare a corporation away from using something, but they largely don’t achieve anything actually meaningful on a societal level. In fact, they’re more likely to create a messier open source ecosystem and be a pain for individual programmers than anything else.

Even if a corporation is scared away from a particular piece of software by an ethical license, it’s typically not much trouble for them to make their own, proprietary version of whatever functionality they wanted. It’s especially not that hard for the largest corporations and governments, which also tend to be the most evil. Except now instead of being able to benefit from common security improvements or bugfixes, compatibility with the functionality already implemented by FOSS software, and so on, they now have their own separate, likely siloed implementation which will have its own set of vulnerabilities and issues that they may or may not care about fixing to the same degree or level of quality as an open source implementation. [Sidenote: I’d love to find more examples of this to strengthen this argument.] This is the issue that permissive licenses avoid, and one of the stronger arguments for using such licenses instead.

Not to mention that it’s usually difficult to actually comply with many Ethical licenses. While some are written well such that it’s pretty cut and dry what you can use the software for, others are not. Take this from the original JSON license for example:

The Software shall be used for Good, not Evil.

Who can say what is good versus what evil? This would likely be up to the creator of the software, but is that even enforceable? If it’s not enforceable (many say that enforceability is not even the point), and companies are largely not affected by it because they can just make their own thing or ignore the license entirely, then what is the point? From my point of view, this is largely just posturing.

Individual developers are also far more comfortable with using licenses written in easy-to-understand language and with clear ramifications. While it’s technically not wrong to say that one should carefully examine the license of any piece of software they wish to use, this isn’t practical for the majority of people. Many people are not confident in their ability to understand the oftentimes complex legal language used in many of the more complex ethical (or copyleft) licenses which likely means that they won’t be willing to work with or use a piece of software for fear of getting things wrong. Given that the goal of ethical licenses is ostensibly to make a more just and less evil software ecosystem, this issue is likely to lead to many ethically-licensed projects languishing in relative obscurity with limited reach while permissively-licensed alternatives see actual adoption and use (likely with some exceptions, but it certainly won’t be the norm, just like with copyleft). The bandwagon effect is very much real in the realm of software licenses.

In summary, the issues that ethical licenses purport to address are societal issues that are not appropriately addressed using software licensing or the copyright system. Plus, it’s also pretty easy for a corporation to just ignore the license, similar to the situation with the GPL, but with even less backing for individual developers or small groups to fight lawsuits against license violators (if they even bother with that).

Just like with many copyleft licenses, the concept of ethical licenses seems good on its face, but breaks down in the real world. Ethical licenses put a larger burden on individual developers compared to corporations while attacking a very real problem from the wrong angle. If you really don’t want evil organizations to use your software, it’s far more effective to write stuff that isn’t useful to them in the first place.