Richard Fontana <> writes:
>> We're working on fixing those presentation problems; see
>I'm actually interested in seeing something more than mere
>'deprecation', which might be appropriate for certain cases of
>superseded or voluntarily-deprecated-by-steward licenses. 
>The OSI should have some sort of process for delisting
>formerly-approved licenses for reasons of failing to actually meet the
>Open Source Definition (or some future replacement of it). That is to
>say, the OSI should be willing to admit that it made a mistake, much
>as a court (while it might ordinarily apply the policy of stare
>decisis) will in certain cases overrule its prior decisions. Clearly
>for policy reasons such actions should be exceptional rather than
>common, and perhaps should be limited to certain licenses that were
>approved during a particular period in the OSI's existence (I would
>guess 2000-2005?).
>I think this is important because the existence, even in a
>'deprecated' category, of licenses that (I would argue) were
>mistakenly approved as 'open source' does some damage to the
>legitimacy of the OSI and the OSD, and to open source itself. This is
>particularly so because, as I understand it, the 'deprecated' category
>is supposed to included licenses that do clearly meet community
>standards for what's open source.
>Given that the few licenses in question are (I think) obsolete, what's
>the harm in saying "sorry, we were wrong, this license is not an open
>source license after all, and here's why"?

Someday it might be good to tackle this problem, yes.  But I think doing
the mere deprecations in clearly and effectively is a necessary first
step along that road anyway -- and doing it will involve a lot of the
basic analysis that we would need to do to take any further steps.
That's why I'm concentrating my efforts on deprecation right now :-).

License-discuss mailing list

Reply via email to