130

Bruce Perens (co-founder of OSI) has coined the term "crayon license":

I've been calling these "crayon licenses", taking a line from an old Monty Python sketch about a dog license with the word "dog" crossed out and "cat" written in, in crayon.

The licenses referenced are typical well-intended free software licenses that have been written by programmers in simple, easy-to-understand, non-legalese language. Some typical examples are the WTFPL and the somewhat more elaborate Artistic License 1.0.

Perens seems to imply that such licenses may pose a problem for developers using them, or for the open source community.

How can these licenses be a problem?

Or is Perens wrong about them being a problem?


This is a canonical question. New questions asking effectively the same thing as this question may be closed as a duplicate of it.

3
  • 6
    I think there is something bizarre of the second example you mention, the Artistic License. Interestingly, the OSI has approved that license, and hasn't revoked its approval after reading the quote that you linked. I find that interesting.
    – Zizouz212
    Commented Sep 17, 2015 at 21:58
  • 3
    The Monthy Python sketch in video, and its transcript. It even have a wikipedia entry.
    – Clément
    Commented Oct 18, 2017 at 1:33
  • 1
    @Zizouz212: Re the Artistic License: I strongly suspect it's a combination of several factors: 1) For historical reasons (read: because Perl), the AL was commonly used in a significant chunk of the open source community, and it would be politically difficult to retroactively declare their work non-open. 2) The license is superseded, and the AL 2.0 is unproblematic. 3) I don't think there's a lot of new software getting licensed under AL 1.0, so there's less need to revoke it.
    – Kevin
    Commented Aug 12, 2019 at 4:19

5 Answers 5

141

There are several issues:

  • License proliferation - The more licenses we have floating around, the more work everyone has to do to understand them. Case law for one license will not necessarily apply to a differently-worded license, even if they're both intended to achieve the same effect. And if everyone starts writing their own licenses, this becomes significantly worse. To get an idea of how bad the situation is already, take a gander at the Free Software Foundation's annotated list of licenses. Note the large number of licenses, and how little the FSF has to say about some of them. We do not want to make this list any longer - there are more than enough licenses to go around already.
  • Legal uncertainty - If a license is vaguely worded, it may not behave as we would like in a court of law. When you write a vague computer program, the compiler will (normally) refuse to compile it; the grammar of the programming language disallows ambiguity at the syntactic level. The program may not mean what you think it means, but it does mean something.* This is not the case when you write legal code. If it's vague, the court will have to guess, and they may guess wrong.
  • Contra proferentem - Ambiguity in a contract is normally interpreted in favor of the non-drafting party (with the rationale that it's the drafting party's fault for creating the ambiguity in the first place). It's not immediately obvious to me that this necessarily applies to an open source license, but if it does, it would greatly exacerbate the previous point.
  • You might accidentally make a non-free license - One crayon license actually in use is basically MIT/X11 + "The Software shall be used for Good, not Evil." This is considered a non-free license (don't take our word for it, the FSF agrees), and resulted in at least one bug report asking for downstream software to be removed from Debian. This caused actual person-hours to be diverted from software development to deal with silly licensing issues that never should have arisen in the first place.

* I am ignoring the issue of undefined behavior in C and C++ because they aren't really relevant to this analogy, but if you like, you can think of vagueness in a contract as like undefined behavior, but perhaps less evil.

1
  • 2
    Comments moved to chat: the comments are not for extended discussions. While fascinating, take it to chat.
    – ArtOfCode
    Commented Aug 6, 2015 at 17:46
40

In addition to the excellent (and accepted) answer posted by Kevin, I want to point out the following:

It is sometimes argued that having license behaving predictable in a court of law only matters if you want to restrict somebody. With the possible exception of a disclaimer of warranty (which may or may not be legal, depending on jurisdiction), there is no need to be too fussy about loose, permissive licenses such as WTFPL or the Unlicense. If you just want to be nice and impose no restrictions on your users, then the choice of license does not matter.

But it does:

  • Some managers of free software projects take licensing issues seriously. Something that to non-professionals looks like a lax and permissive license, may not be what it appears. Such managers may refuse to accept any contribution or pull request unless the code is licensed under terms that are recognized as compatible with project's main license. Most "crayon" licenses fail that test.

  • The public domain may be great for cultural works (at least in jurisdictions that recognize the public domain). IMHO, the public domain (or something trying to mimic it) is not a good idea for software (or for anything that is functional, rather than aesthetical). One reason the PD is dangerous for software is a nasty thing called "software patents". If you put your software in the public domain, somebody else may just go ahead and patent some method it implements, and then accuse your software of infringing their patent. Too far fetched? Well, this is what happened to a programmer named Bob Jacobsen1, so it certainly cannot be ruled out.


1) Kamind Associates, Inc. (a commercial company) sold a product named "Decoder Commander" that would "normalize" the interfaces for various types of model railway systems as part of a larger framework to let a personal computer control such a system. Katzer, the owner of that company, held various patents related to this software. At one point, Katzer sued a programmer named Bob Jacobsen for infringing those patents. The allegedly infringing software was a set of files know as "DecoderPro", that Jacobsen had made publicly available under a very permissive license (Artistic License 1.0). As it turned out, Katzer had copied those files from "DecoderPro", and modified them slightly to create "Decoder Commander".

In the end, Jacobsen prevailed in court, and the court decided that Katzer had infringed on Jacobsen's copyright. But Jacobsen's poor choice of license (Artistic License 1.0) caused him a great deal of grief.

5
  • 26
    By my understanding, a patent in the US that ends up just being "prior art" (i.e., a method that existed before the patent-holder actually developed the patent) is essentially void, as it's not a new idea. Thus, even if Jacobsen had forsaken all copyright on DecoderPro, it would seem to me that the court would still have ruled against Katzer given proof that Jacobsen's work came first. (The real grief-saver would have been registering the copyright with the Library of Congress if he didn't do that, as then there would be official government documentation of the prior art.)
    – JAB
    Commented Aug 10, 2015 at 15:56
  • 19
    Licensing and patents are orthogonal to each other. If someone wants to steal my code and patent some idea in it, he can just as well copy it if it is GPL and then claim I stole it from him. What matters for patent validity is who can prove what came first. Commented Aug 14, 2015 at 17:18
  • 20
    Jacobsen would have had a lot of grief, regardless of the license. Defending against a lawsuit, specially from a deep-pocket company, is expensive and drawn out. "Winning" but ending up broke is no fun.
    – vonbrand
    Commented Jan 6, 2016 at 12:11
  • 1
    @vonbrand idk what country Jacobsen is in or how it works in his country, but at least in the countries i'm familiar with, the loser usually have to pay the winner's court fees. (Norway, Sweden, and Denmark)
    – hanshenrik
    Commented May 26, 2019 at 21:25
  • @hanshenrik, this was a United States case, and the US does not have loser-pays rules except in cases of egregious abuse. As a US citizen, I'm glad of this -- it's hard enough for a private citizen to win a lawsuit against a corporation as it is, and those suits are already ruinously expensive for an individual, more than enough to discourage frivolity; if one had to factor in paying for expensive corporate council if one were to lose, it would make it even riskier to try to recover damages done by a deep-pocketed opponent than it is now. Commented Oct 17, 2021 at 20:56
24

Developers inside big corporations (and perhaps even smaller ones) have lawyers and managers dictating them conditions for using (professionally) external free software. A "crayon license" is very likely to be forbidden in such contexts (probably such developers have a list of acceptable licenses).

So if you want your code to be widely used, I suggest to use an established OSI labelled open-source license.

2
  • 19
    One can even argue that if you're crayon-licensing something in a way that suits your outlook, there's no good reason not to also license it under one or more OSI-approved licenses that you're reasonably happy with. Thus an amateur can use it at will under the principle "do anything you want with it", and the big corporation can be careful to adhere properly to the terms of MIT (or whatever) by keeping copyright notices intact and whatnot, which the WTFPL author considers excessively onerous. Commented Aug 21, 2015 at 19:26
  • 2
    @SteveJessop A potential example - github.com/pjreddie/darknet
    – GoodDeeds
    Commented Jul 13, 2018 at 6:18
11

An important part of the BSD license is the warranty disclaimer.

You might think it's a breath of fresh air and entertaining to the users to apply something like the WTFPL.

Then you wind up being sued because someone lost some data and they are blaming that software, arguing that its documentation amounts to some sort of guarantee about what it will or won't do.

This could happen in a jurisdiction in which a warranty disclaimer is held valid and provides protection against that sort of thing. (Thus in such an event it had been foolish not to have one in place).

Giving something away for free doesn't disrobe the giver of liability arising out of its use. E.g. if someone receives a free electrical appliance, and it starts a fire, the giver is just as liable as a seller.

9

One particular problem is that your home-knit license is probably incompatible with everything else, and thus creates an island that is useless to everybody else, even if the intent is to be very free. Read also David Wheeler's essay on the licence proliferation too.

0

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.