[License-discuss] Generic process for removing approved licenses. Re: REMOVE AAL from list of approved licenses

[Nigel T]

On Fri, Mar 27, 2020 at 4:23 PM Josh Berkus <josh at berkus.org> wrote:

>
> > - If the discussion on license-review seems to support the view that the
> > license should be removed, because it fullfils some criteria that should
> > be defined, the license removal committee can proceed to a removal
> process.
>
> We should have a new committee, with a new list or whatever, called
> license-deprecation or similar.  Having these discussions on
> license-review would be confusing and potentially contentious.
>

As long as the list is open but I don't see why it wouldn't work under
license-review.


> > - The criteria for removal could be: 1) license does not in fact conform
> > with the OSD (was erroneously approved), 2) does not appear to be used
> > for any currently available/working software, 3) (this one is
> > contentious) license is de-facto only used in ways that go against the
> > spirit of OSD / software freedom.
>
> Since none of our current problem licenses are (3), maybe we could skip
> that criterion?  It seems too subjective to actually employ.  Here's my
> suggested criteria based on yours:
>
> 1. license does not in fact conform to the OSD (was erroneously approved)
>
> 2. does not appear to be used for any currently available/working
> software *and is redundant with more popular licenses* (added condition
> mine).
>

I would keep 3 as a safety net because 1 is often debatable.


> > - If any existing users are found, OSI will discuss whether they can and
> > are willing to move to a better license. Also it is possible that a
> > project using the license doesn't object to removal even if they
> > continue to use it.>
> > - If the license author can still be found, OSI will discuss whether the
> > author is willing to publish a new version that would comply with our
> > current view of the OSD. In this case the license should be superceded
> > rather than removed. (I think at this point we should focus on removing
> > licenses considered mistakes. Reducing the number of licenses is a
> > separate concern.)
>
> We'll need to have a documented workflow for what happens if the users
> or the authors object to deprecation.  What does a contested feedback
> process look like?
>

One that will likely be ignored by the board if it sees fit.

> - Alternatively the license author can propose that the license be
> > deprecated and removed.
>
> - At this point, if the committee feels that it makes sense to proceed
> with removal, they will submit a deprecation request to the Board.
>
> - The Board will vote and approve or reject the deprecation.  If
> approved, the license will be marked as deprecated in the OSI catalog,
> with a link to a place where license users can supply feedback on the
> deprecation.
>

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.


> > - After the following steps have been taken, OSI will document the
> > outcome and conclusions so far, and propose that the license be removed
> > from the list of approved licenses. This notification will be sent to
> > license-review, the affiliate members list, a list of corporate
> > sponsors/interested parties (if it exists?), other stakeholders like
> > Linux distributions, media, etc... For best publicity, it makes sense to
> > batch together all concurrent removal proposals into one notification.
>
> Good.  Presumably we'd put these reasons on the wiki with the rejected
> license reasons?
>
> I think, though, that we should leave the "required publicity" up to the
> committee.  For a license that was never adopted, sending out a blast to
> every single OSI channel seems like overkill.
>

No.  The more visible and onerous a process the better.


> > - A feedback period of 15 months is required before the actual removal
> > takes place.
>
> Why?  I think we should let the committee set the removal period.  For
> example, say we find out that literally nobody still uses the AAL, and
> that it was abandoned by the developer who proposed it shortly after
> drafting.  Why would we wait 15 months?
>

Because removal should be an onerous and difficult process.  Far more
onerous than approval.

Removal vote by the board should also be public and allow for debate by
both defenders and opponents of the license at that meeting.

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.

The current license approval process at the board level is very opaque.

*The license removal process should not be.*


> On the other hand, if a license is in use by a large community, I can
> imagine this taking *more* than 15 months.
>

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.

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/attachments/20200329/0acea1db/attachment.html>