Subject: Re: super small licenses, good or bad idea?
From: Rick Moen <>
Date: Thu, 9 Jun 2011 23:19:03 -0700

(Re-post of something I attempted to post a bit over a week ago, but
didn't go out for reasons not worth going into.)

----- Forwarded message from Rick Moen <> -----

Date: Tue, 31 May 2011 17:04:27 -0700
From: Rick Moen <>
Subject: Re: super small licenses, good or bad idea?
Organization: If you lived here, you'd be $HOME already.

Seems to me that license-review was not the right mailing list, so 
I'm quoting Jon's entire post and replying below.

Quoting Jon Mayo (

> I like to put a license that fits in a small comment in code I post on
> paste sites or short little C examples I leave on my website/blog.
> Sometimes I just make these examples public domain, but that seems to
> have issues in places outside of the US, so I was looking for
> something as small as saying "No copyright claimed, this work is in
> Public Domain, yadayda". There is the fair license (
> ) , while small, it is
> strangely worded. Fair License:
> <Copyright Information>
> Usage of the works is permitted provided that this instrument is
> retained with the works, so that any entity that uses the works is
> notified of this instrument.
> I had my own idea for a small license based on the Fair license, I
> called it the "Fair Enough" license. I realize that license
> proliferation is troublesome, so I have avoided using this license
> much or I try to dual license if I do toy around with using this
> license, but here's the text for your review:
> Copyright 2011 <Your Name>
> Modification and redistribution is permitted if unmodified license is included.
> The works are without warranty.
> (some version I use 'or' some I use 'and', because I'm not sure which
> is right. I think both mean the same thing here because I'm giving
> permission for A and B, but I'm not requiring you to do anything with
> that permission)
> Here's my question, are these micro-licenses (which I consider
> MIT-like) sufficient enough to apply to small projects (generally a
> single source file). Or are they full of flaws and it will just
> backfire in my face if I try to run with this?

I include my own analysis of this matter towards the bottom of . 
Sorry about length, but there was a lot to go through.

Here's the section I have in mind:

  Please consider well-known licences: The Fair License[1] is only three
  lines and OSI-certified as open source. However, there are good reasons
  to think the MIT License[2], which is extremely clear, well-known, and
  tested, but is about 20 lines long, is probably the briefest licence
  that's legally safe:

  Like the Fair License, the MIT License includes a warranty disclaimer in
  all capital letters. However, unlike Fair License's disclaimer, MIT's
  disclaimer deems it insufficient to say merely "without warranty of any
  kind", but goes on to enumerate the several types of warranty not
  granted (both express and implied, including merchantability, fitness
  for particular pupose, and non-infringement). Also, there's a disclaimer
  of liability for 'claim, damages, or other liability', again, listing
  several theories of law such liability might arise from and not merely
  saying 'any'. All of that in capital letters.

  Why? Because of legal requirements for disclaimers[3] in (especially) USA
  law, which heavily restrict warranty disclaimers for reasons of consumer
  protection. Without that particular form of disclaimer, coders (and
  downstream reusers of code) may find themselves saddled with unintended
  warranty obligations.

  In general, the MIT License's explicit listing of rights conveyed and
  not conveyed, and of obligations specifically disavowed, is safer
  because it was written with legal tradition in mind, to head off mishaps
  that might otherwise occur, and that _have_ in fact occurred without that
  wording. Programmers ignore that legal experience at their peril.


As you'll see elsewhere on the page, I point out that one-line licences 
that are clearly open source (per OSI criteria) are eminently possible
but ill-advised because of warranty exposure.  Even if you, yourself,
have reason to not fear warranty obligations, you are poorly providing
for the interests of anyone making derivative works.

I also point out that a TWO-line licence that's clearly open source and
_attempts_ to disclaim warranty is equally easy to write, but the above
analysis pleads for using a well-known, widely understood permissive
licence (such as, notably, MIT License) instead -- because there is high
value in using a well-known, extremely clear, tested licence rather than
a one-off, and because ultra-brief disclaimers of warranty are likely to
be ineffective.

It seems as if many programmers have a recurring urge to write
ultra-brief one-off permissive licences.  I don't expect my analysis to
dissuade all of them -- but perhaps a few.

----- End forwarded message -----