[License-discuss] [Non-DoD Source] Re: "Fairness" vs. mission objectives

Eric S. Raymond esr at thyrsus.com
Wed Feb 26 00:54:00 UTC 2020

Nigel T <nigel.2048 at gmail.com>:
> There is a significant difference between deprecating and decertification.
> A deprecated api can still be used.  One removed (aka decertified) cannot.  
> The bar for decertification should be exceedingly high.
> And how is “bad” decided?  Is the limited patent clause in ECL v2 “bad” because it doesn’t go far enough?  This this form of “bad” sufficient for deprecation or even decertification?  
> Should all licenses without an explicit unlimited patent clause be “decertified” as “open source”?
> Deprecation is less damaging although deprecating a license with a significant community is unnecessarily divisive especially when these kinds of decisions are often the result of a small but vocal group more interested in ideological purity than access to code.
> Frankly even deprecation should require more than a simple board vote behind closed doors.  
> De-certification even more so.   
> You’re voting people off the open source island when decertifying.  It should be a long, arduous process requiring many checks.

Before you worry too much about zealotry, maybe you should wait to see
what licenses people choose to try tio deprecate.  I don't look at OSI
and see a collection of ideological nutcases; I am *not* worried.

If you want to be a conservative, anti-decertification voice in these
debates, go to it.  Somebody ought to be.  I don't anticipate myself
taking an extreme strance in either direction.

There are a lot of licenses I would like to see deprecated, but I
can't yet think of one I would instantly decertify.

Personally, I have kind of seized on deprecation as a concept because of cases
like...oh, the PNG Reference Library License.  A perfectly sound and
conformant license that I wouldn't dream of decertifying, but we'd
all be better off if nobody ever used it again, adopting instead some
common license wuth a better-developed interpretive tradition.
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

More information about the License-discuss mailing list