Three new proposed OSD terms

[Steve Quinn]

Has something happened to the mailing list????  Last message I received was dated yesterday at 2:50pm. 

-----Original Message-----
From: Alex Bligh [mailto:alex at alex.org.uk] 
Sent: Monday, March 07, 2005 2:53 PM
To: Chuck Swiger; Steve Quinn
Cc: license-discuss at opensource.org; Alex Bligh
Subject: Re: Three new proposed OSD terms



--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

--
No virus found in this incoming message.
Checked by AVG Anti-Virus.
Version: 7.0.308 / Virus Database: 266.6.2 - Release Date: 3/4/2005
 

-- 
No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.308 / Virus Database: 266.6.4 - Release Date: 3/7/2005