Subject: RE: de-recomendation of Larry Rosen's licenses/clarify web site
From: "Lawrence Rosen" <>
Date: Mon, 15 Aug 2005 18:34:12 -0700

        The license author, Larry Rosen, discourages the use of versions
        1.1, 1.2, and 2.0 of the Academic Free License, and recommends
        that copyright holders upgrade to version 2.1 immediately.

Of all the paraphrases in Evan's email, I think the first half of this comes
closest to the truth, but the last half is untrue. 

Earlier versions of the AFL and OSL have been superseded in my own mind by
the 2.1 versions, and they will soon in turn be superseded by version 3.0 --
now under review at license-discuss. 

Each time I rewrite a license in response to public and private comment, I
think the license improves. Sometimes I add clarifying language, sometimes I
reword entire provisions to avoid unanticipated legal problems, and I
believe each time the license satisfies more needs of more people. Many
licenses go through such a process. Even the venerable GPL is going through
it now.

But that doesn't mean that individual software authors won't see in the
earlier licenses a provision or two that they prefer. Those earlier versions
are still OSI approved, and software distributed under those licenses is
still open source. 

For a license author, or anyone else (especially a lawyer), to broadly
"recommend" a license in the absence of information about your business
model and other objectives is tantamount to practicing law without using
their eyes and ears. For that reason, I shouldn't actually say in public
that I recommend or "de-recommend" any license. And I don't think OSI should

On the other hand, I have no problem telling you that I think that AFL and
OSL version 2.1 is better than earlier versions. And I'll have no trouble
telling you that AFL and OSL version 3.0 will be better still. Whatever
"better" means.... (I write emails to license-discuss every time I propose
changing a license; you can find those explanations in the archives.)

I also have no problem recommending, when you choose a license, that you
consider among other considerations that the author of the license and the
community leaders who deal with such things at OSI, FSF and other
organizations you trust, would prefer that you avoid certain licenses. 

It appears from Laura Majerus' email that several licensors besides me are
deprecating their own earlier licenses. That's great. I hope that helps
prevent license proliferation. For my own licenses, I intend to deprecate
earlier versions every time I release a new version. But I should not
publicly recommend or de-recommend any license. That's for each of you to

/Larry Rosen

Definitions of "deprecate" found on Google:

* express strong disapproval of; deplore
* belittle; "The teacher should not deprecate his student's efforts" 

* In computer software standards and documentation, deprecation is the
gradual phasing-out of a software or programming language feature. 

* To discourage use of a feature without removing the feature from the
product. When a JavaScript feature is deprecated, an alternative is
typically recommended; you should no longer use the deprecated feature
because it might be removed in a future release. 

* belittle, as in : Have you noticed that he seems to deprecate himself just
so we have to compliment him?

* To express earnest disapproval of. This term is used to refer to obsolete
structures that ought not to be used but remain valid.

Lawrence Rosen
Rosenlaw & Einschlag, technology law offices (
3001 King Ranch Road, Ukiah, CA 95482
707-485-1242  *  fax: 707-485-1243
Author of "Open Source Licensing: Software Freedom and 
   Intellectual Property Law" (Prentice Hall 2004) 
   [Available also at]

> -----Original Message-----
> From: [] 
> Sent: Monday, August 15, 2005 3:55 PM
> To:; 
> Subject: de-recomendation of Larry Rosen's licenses/clarify web site
> Evan and all,  
> Larry Rosen has volunteered to "de-recommend" the earlier 
> versions of his licenses in response to a call from the OSI 
> license proliferation committee for people to voluntarily 
> "re-commend" their own licenses. In other words, only an 
> owner of a license can de-recommend it, not just anyone.
> Our web master is a volunteer (thank you Steve!), and I will 
> ask him to make the site clearer about what this means.  
> You'll notice a similar disclaimer on the Intel Open Source 
> License.  The Jabber Open Source License will get a 
> disclaimer soon, as the Jabber folks voluntarily 
> de-recomended it at Oscon.
> Laura Majerus
> OSI, Legal Affairs
> -----Original Message-----
> From: Evan Prodromou []
> Sent: Sunday, August 14, 2005 6:52 AM
> To:
> Cc:
> Subject: Unclear wording on the AFL disclaimer
> I actually have no clue who handles the Web design on 
>, but I thought I might post a suggestion here.
> I recently saw the following disclaimer on the AFL 2.1 page:
>         Larry Rosen has ceased to use or recommend any version of the
>         Academic Free License below version 2.1
> My read of this was:
>         Larry Rosen does not recommend any version of the 
> AFL, including
>         the 2.1 version shown on this page after this disclaimer
> After a couple of extra reads, I now think it means:
>         Larry Rosen does not recommend any version of the AFL 
> which has
>         a version number less than 2.1
> I suggest changing the wording to to the following:
>         The license author, Larry Rosen, discourages the use 
> of versions
>         1.1, 1.2, and 2.0 of the Academic Free License, and recommends
>         that copyright holders upgrade to version 2.1 immediately.
> Strangely, the disclaimer _doesn't_ appear on either the AFL 
> 2.0 or AFL
> 1.1 pages! So it should probably go on there, too.
> Finally, a link to an explanation for why the earlier license 
> versions are so flawed that they need this red-letter 
> disclaimer might be useful.
> ~Evan
> --
> Evan Prodromou
> "By God! I will accept nothing which all cannot have their 
> counterpart of on the same terms." -- Walt Whitman, "Song of Myself"