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

[Nigel T]

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.

> On Feb 25, 2020, at 10:36 AM, Karan, Cem F CIV USARMY CCDC ARL (USA) via License-discuss <license-discuss at lists.opensource.org> wrote:
> 
> Eric S. Raymond wrote on Monday, February 24, 2020 2:10 PM
>> Simon Phipps <simon.phipps at opensource.org>:
>>> What I'd propose here is that we explore a process for deprecation of
>>> licenses by someone other than the license steward.  Maybe it would
>>> start with a substantiated request endorsed by several regular list
>>> members, and then follow the same
>>> discussion-followed-by-committee-review process as approval. The
>>> decision to involuntarily deprecate a license would then finally be reviewed by the Board.
>> +1.  That seems eminently sensible to me.
>> --
>>       Eric S. Raymond < Caution-http://www.catb.org/~esr/ > 
> 
> OK, so if someone asks us to accept a license because a similar one was accepted in the past, and we've decided that it was a mistake to accept the license in the past, does that mean that we should start reviewing all currently accepted licenses to see if there are others with similar problems?  Basically, are we proposing to start a house cleaning project?
> 
> As for deprecating a license, what would be the process for it?  Something like the following?:
> 
> - License is reviewed and found to be 'bad' and can't be fixed for some reason.
> - Reason is fully and clearly summarized and explained on a webpage somewhere so that other license designers can learn from it.
> - Announcement on multiple venues (which ones?) that the license will be deprecated.
> - A waiting period is announced during which any new projects that attempt to use the license are rejected (how long a waiting period?  Who is deciding to do the rejection?  What happens if one group continues to accept the license, but another stops? Other questions?)
> - Once the waiting period is up, the license is deprecated, and moved into a historical archive somewhere, with the reasoning behind why it was deprecated (again, so that designers of new licenses know what to avoid) is described.
> 
> I personally believe that it is important to explain **why** a previously accepted license is being deprecated.  Right now, we rely in part on institutional knowledge; e.g., someone on the list remembers a similar discussion from 15 years ago, dredges it up, and brings the rest of us up to date.  Unfortunately, license designers often don't have the time to go through 15 years worth of mailing list archives to really figure things out; providing a succinct case law gets them up to speed quickly, while keeping us from going crazy having to find the same old discussions over and over again.
> 
> Thanks,
> Cem Karan
> 
> ---
> Other than quoted laws, regulations or officially published policies, the views expressed herein are not intended to be used as an authoritative state of the law nor do they reflect official positions of the U.S. Army, Department of Defense or U.S. Government.
> 
> 
> 
> _______________________________________________
> License-discuss mailing list
> License-discuss at lists.opensource.org
> http://lists.opensource.org/mailman/listinfo/license-discuss_lists.opensource.org