pruning "dead" licenses

[Ernest Prabhakar]

Hi Russell,

On Dec 13, 2004, at 7:13 PM, Russell Nelson wrote:

> John Cowan writes:Eric S. Raymond scripsit:
>>> To the extent that we can promote freedom and get better outcomes by
>>> pruning licenses, I'd sacrifice "diversity" without a qualm.
>>
>> What does "pruning" mean?  Does it mean decertifying, delisting, or
>> de-emphasizing?
>
> I'm shooting for decertifying and would accept delisting.
> De-emphasizing is a done deal (in that we accept that it will be done,
> in some fashion).

I've been trying to follow this thread as best I can, but I'm still 
confused as to the primary purpose of this exercise. Maybe I'm missing 
the point, but it seems to me like "decertifying" is a technical 
solution to what is really a -marketing- issue.

That is, we want to limit the number of active listed licenses 
presented to users.  But "decertifying" implies to me that any license 
which has been de-certified is legally forbidden from using the OSI 
mark, and in fact is just as much in violation as a commercial license 
wrongly misappropriating the mark.   That's an awfully heavy stick to 
use.  Especially since many other organizations treat OSI Certification 
as the guarantor of "open sourceness" (for better or worse), and thus 
there's secondary legal implications.

When I personally look at the OSI list, I'm trying to answer one of 
three questions:

a) Can I feel comfortable that the software I've just downloaded is 
licensed under reasonable terms?

b) Which licenses should I consider when releasing my own open source 
project?

c) Am I allowed to use the OSI mark when advertising my project/product?

As best I can tell, this conversation seems to be motivated by (b).  
But I'm still concerned about (a).   If I download an ancient project 
under some obscure license, I would still feel much better knowing that 
it was OSD compliant -- and that fact may well affect my ability to use 
it due to various secondary  legal and procedural concerns.

 From this perspective, I would vote for categorizing licenses into 
"Active" vs "Legacy". I would also support an additional annotation  of 
"Reusable" to indicate licenses which people should consider for (b).  
For example, the MPL is designed to be reusable whereas the NPL was not 
(and may well be Legacy).

Here's how I'd break it down.  Does this make sense?

-- Ernie P.

OSI Certified Open Source Licenses

This is a list of currently active OSI  Certified licenses. See our 
<Legacy license page> for a list of licenses the OSI believes are no 
longer in active use.

I.  Reusable Licenses

The following OSI  Certified licenses are designed for you to use with 
code you write and want to release under an open source license.

BSD
GPL v3
OSL
AFL
CPL
....

II.  Consumable Licenses

The following OSI  Certified licenses also fully conform to the Open 
Source Definition, but  were written for use by a particular copyright 
owner.  In generally, you will not want to release your own code under 
these licenses unless you have a direct relationship with the author of 
the license.  However, you can use code released by others under this 
license with the confidence that they conform to the values of the Open 
Source Definition.

Apache Public License 2.0
Apple Public Source License 2.0
...

[separate page]

III.  Legacy Licenses

The following licenses have been superseded, or are otherwise 
deprecated, though they still have been certified as conforming to the 
Open Source Definition.   In general, if you find software using a 
license on this list you should check to see if you can instead license 
it under an <active open source license> (since most open source 
licenses allow end-users to relicense software under a newer version of 
that license).

GPL v1, v2
BSD w/advertising clause
APSL 1.0, 1.1, 1.2
Netscape Public License