Three new proposed OSD terms

[Alex Bligh]

--On 07 March 2005 15:33 -0500 Chuck Swiger <chuck at codefab.com> wrote:

> You're right, of course.  However, aside from Richard Stallman, most open
> source developers seem happy with something like [1]:
>
> "THE BEER-WARE LICENSE" (Revision 42):
> <phk at FreeBSD.ORG> wrote this file.  As long as you retain this notice you
> can do whatever you want with this stuff.  If we meet some day, and you
> think
> this stuff is worth it, you can buy me a beer in return.   Poul-Henning
> Kamp

It is rather easier to right a license which is entirely permissive (or for
that matter entirely restrictive) than one which says some things are
allowed under some conditions, but not under others. Try finding a
reciprocal license that short, that is enforceable.

You will find this true not only of legal documents, but also of technical
documents. See RFCs. You will also find that those that do not accurately
distinguish between what is permitted and what is prohibited, and what is
mandatory and what is optional, store up trouble for later. Also see RFCs.

> I wonder how much shorter software licenses would be and how much easier
> they would be to understand if the compensation offered to those in the
> legal profession was inversely proportional to the number of words they
> used

I don't know anyone sensible who pays their lawyer by the word, and I know
several lawyers who spend many an hour simplifying and shortening
documents. In general, lawyers do what you pay them to do.

Whilst it is true that as far as OSI approved licenses are concerned, the
lawyer-written licenses are (probably, in general) word for word longer
than lay-written ones, I bet the discussion in court over what is
and what isn't permitted under (say) the original artistic license is
going to be orders of magnitude longer than that under (say) the MPL.
Larry Rosen makes the point better than I can in his book.

All this boils down to a philosophical point about the purpose of
licensing. Is the license there to serve as a definitive legal statement of
the rights and obligations of each contributor, distributor, user and
modifier, which provides both certainty and legal enforceability OR is it
there to set out the philosophy of "what the original author would like to
happen". If it's the latter, a license can perhaps be as simple as a
statement of aspiration, with some permissive legal effect - from this
point of view I can see both the point on license wording, and the point on
license proliferation (how many different ways do you need to say "do what
you want with it"?). But this thread started off on the assumption that the
people with problems were large corporates, who have an additional
transaction cost in assessing each license. For these, firstly I don't have
a huge amount of sympathy (they are likely to have in house legal teams,
and because of their size are likely to save more in aggregate over
conventionally licensed software) and secondly they are precisely the sort
of user/contributor who is going to be more fussed about the precise nature
of license terms anyway (and thus want the legal certainty and
enforceability) for the very reason that they are used to reading
commercial software license terms and negotiating on them. Without wishing
to single out Mr Fink of HP, I am quite sure that HP writes its own
software licenses in precise enforceable legal terms, rather than in
vague aspirational terms of dubious enforceability in the hope that
"the layman will understand them" - this should be the very last group
from whom we should be concerned about special pleading on wording (as
opposed to, say, consumer end users, where there is a clear case to be
made to ensure the license is comprehensible).

One corollary of the above is that the explanation of the license need
not be the license itself. Forrest has produced an excellent tool
to help for geeks to understand (at least a subset of) OSI licenses
in terms of what they include. It would not be a bad thing if each
approved license had to include a (non-binding) explanation in plain
English as well (the GPL attempts to do this, though inclusion as
a prologue in the license itself is arguably not necessary).

Alex