<div dir="ltr"><div dir="ltr">On Fri, Mar 27, 2020 at 4:23 PM Josh Berkus <<a href="mailto:josh@berkus.org">josh@berkus.org</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><br>
> - If the discussion on license-review seems to support the view that the<br>
> license should be removed, because it fullfils some criteria that should<br>
> be defined, the license removal committee can proceed to a removal process.<br>
<br>
We should have a new committee, with a new list or whatever, called<br>
license-deprecation or similar.  Having these discussions on<br>
license-review would be confusing and potentially contentious.<br></blockquote><div><br></div><div>As long as the list is open but I don't see why it wouldn't work under license-review.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">> - The criteria for removal could be: 1) license does not in fact conform<br>
> with the OSD (was erroneously approved), 2) does not appear to be used<br>
> for any currently available/working software, 3) (this one is<br>
> contentious) license is de-facto only used in ways that go against the<br>
> spirit of OSD / software freedom.<br>
<br>
Since none of our current problem licenses are (3), maybe we could skip<br>
that criterion?  It seems too subjective to actually employ.  Here's my<br>
suggested criteria based on yours:<br>
<br>
1. license does not in fact conform to the OSD (was erroneously approved)<br>
<br>
2. does not appear to be used for any currently available/working<br>
software *and is redundant with more popular licenses* (added condition<br>
mine).<br></blockquote><div><br></div><div>I would keep 3 as a safety net because 1 is often debatable.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">> - If any existing users are found, OSI will discuss whether they can and<br>
> are willing to move to a better license. Also it is possible that a<br>
> project using the license doesn't object to removal even if they<br>
> continue to use it.><br>
> - If the license author can still be found, OSI will discuss whether the<br>
> author is willing to publish a new version that would comply with our<br>
> current view of the OSD. In this case the license should be superceded<br>
> rather than removed. (I think at this point we should focus on removing<br>
> licenses considered mistakes. Reducing the number of licenses is a<br>
> separate concern.)<br>
<br>
We'll need to have a documented workflow for what happens if the users<br>
or the authors object to deprecation.  What does a contested feedback<br>
process look like?<br></blockquote><div> </div><div>One that will likely be ignored by the board if it sees fit.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">
> - Alternatively the license author can propose that the license be<br>
> deprecated and removed.<br>
<br>
- At this point, if the committee feels that it makes sense to proceed<br>
with removal, they will submit a deprecation request to the Board.<br>
<br>
- The Board will vote and approve or reject the deprecation.  If<br>
approved, the license will be marked as deprecated in the OSI catalog,<br>
with a link to a place where license users can supply feedback on the<br>
deprecation.<br></blockquote><div><br></div><div>Deprecation is a good first step in the process and should be a possible end point.  Especially if criteria 1 is in debate and criteria 3 is not violated.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">> - After the following steps have been taken, OSI will document the<br>
> outcome and conclusions so far, and propose that the license be removed<br>
> from the list of approved licenses. This notification will be sent to<br>
> license-review, the affiliate members list, a list of corporate<br>
> sponsors/interested parties (if it exists?), other stakeholders like<br>
> Linux distributions, media, etc... For best publicity, it makes sense to<br>
> batch together all concurrent removal proposals into one notification.<br>
<br>
Good.  Presumably we'd put these reasons on the wiki with the rejected<br>
license reasons?<br>
<br>
I think, though, that we should leave the "required publicity" up to the<br>
committee.  For a license that was never adopted, sending out a blast to<br>
every single OSI channel seems like overkill.<br></blockquote><div><br></div><div>No.  The more visible and onerous a process the better.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">> - A feedback period of 15 months is required before the actual removal<br>
> takes place.<br>
<br>
Why?  I think we should let the committee set the removal period.  For<br>
example, say we find out that literally nobody still uses the AAL, and<br>
that it was abandoned by the developer who proposed it shortly after<br>
drafting.  Why would we wait 15 months?<br></blockquote><div><br></div><div>Because removal should be an onerous and difficult process.  Far more onerous than approval.</div><div><br></div><div>Removal vote by the board should also be public and allow for debate by both defenders and opponents of the license at that meeting.  </div><div><br></div><div>If the board prefers to have a separate meeting for removal votes that would be fine but anyone interested should be allowed to attend and submit a request to provide testimony to the board like one could at a public hearing before say a city council vote.  Board member votes should be on record.</div><div><br></div><div>The current license approval process at the board level is very opaque.  </div><div><br></div><div><b>The license removal process should not be.</b></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">
On the other hand, if a license is in use by a large community, I can<br>
imagine this taking *more* than 15 months.<br></blockquote><div><br></div><div>If it is being used be a large open source community it shouldn't be removed but stay in a deprecated state if criteria 3 isn't being violated.</div><div><br></div><div>Deprecated licenses won't provide much in terms of precedent for any new licenses so maintaining the current state of affairs shouldn't cause issues.</div></div></div>