Eric S. Raymond wrote on Monday, February 24, 2020 2:10 PM > > Simon Phipps <simon.phi...@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@lists.opensource.org http://lists.opensource.org/mailman/listinfo/license-discuss_lists.opensource.org
