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

[Henrik Ingo]

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

> Henrik,
>
> Thank you for proposing a process for this!  Lemme add my $0.02 on what
> I would picture as a process.
>
> >  - There should be a formally elected person or committee with authority
> > even just to (formally) start discussion about removing a specific
> > license. This is to protect and ease tensions in situations where 1 list
> > member proposes a license for removal and a proponent or user of that
> > license is therefore forced to forcefully defend it.
>
> I think we should have a license deprecation working group, appointed by
> the Board.  However, *any* OSI member or contributor should be able to
> propose licenses for deprecation to this group.  Just as anyone in the
> world can propose a new license for approval.
>
>
Sure. But the formal process would only be initiated by the committee. This
is different from submitting a new license, where the process starts with
the submitter emailing license-review list.

I feel this is an important distinction. For example, if some troll would
propose that AGPL should be removed from the OSI list, it would not be a
correct conclusion that "OSI is now deliberating whether AGPL is open
source".



> >  - As this process doesn't exist yet, I'm not saying that Josh' proposal
> > is out of place. But if such a gatekeeping process existed, this would
> > not be counted as a proposal to act. In such a situation Josh may have
> > phrased his email differently, for example as a question: "Why was this
> > approved back in 2002?" or "Is anybody using this license?".
>
> Disagree with you here, any member should be able to propose license
> deprecation to the committee.  As the AAL has just shown, there's a huge
> backlog of unexamined licenses from the early years, and if block
> proposals from interested contributors, then the actual full review of
> the catalog is never going to happen.  It's also not a terribly open
> source way to do this.
>
>
I'm not saying you can't have this discussion or that you couldn't send
proposals to the committee. Just that those activities aren't yet part of
the formal process.

So for example here, the fact that you proposed AAL for removal, shouldn't
*yet* be held as evidence that AAL is somehow lesser open source than any
of the other licenses.



> > - 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.
>

Given that there's now a committee for approving licenses, I feel like
there should be some input from that same committee at least. But sure,
maybe there's a different set of people motivated to comb through the old
licenses that could drive the process as a separate committee.



>
> > - 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 like to postpone the activity on #2. Let's first focus on licenses
that have actual problems. Arguably, if a license isn't being used anyway,
it cannot be an urgent problem.

In my list I meant #1 and #2 more as AND requirements. Preferably both
would be true for a license to be removed. (Admittedly point #3 then
doesn't follow this logic.)


>
> >
> > Steps in removal process:
>
> - Someone, a committee member or a contributor, will propose to
> license-deprecation that a license needs to be deprecated and why
>
> > - OSI (license removal committee) will document the exact reasons why
> > license is proposed for removal.
> >
> > - OSI will spend reasonable efforts to find out whether license is still
> > in use.
> >
> > - In particular, OSI will contact the original author/submitter of the
> > license and all projects that at the time of approval were using or
> > intending to use the license.
>
> "will attempt to contact", given that most of the licenses we're talking
> about here are 15-20 years old.
>
> > - 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?
>
>
Most of my suggested process assumes that the license steward isn't
co-operative. Otoh it's a good point that we may want to think about how to
handle active opposition.


> > - 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.
>
>
To clarify, your added points are only for the scenario that the license
author proposed to deprecate and remove?



> > - 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.
>

The motivation here are the cases where no (significant) users or license
authors have been found. A reasonably wide notification is required to
prove the case that they really don't exist.

Also, the fact that OSI for the first time ever would de-certify any
license is newsworthy in itself, so at least for the first batch of
licenses there's no reason to be shy about this.


> > - 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?
>
>
Again the motivation here is to ensure that removals can't happen silently
without people noticing. We shouldn't assume that just because this group
of OSI insiders couldn't find users for a license that they don't exist
somewhere. Allowing the notification to propagate for a sufficiently long
time increases the likelihood that someone using the license would be able
to react before the final decision.

For example, say I use a less popular OSI approved license for my project,
and I know there is a chance that OSI can de-certify licenses. But I'm not
in any way active with the OSI. It should be possible for me to check the
OSI website once a year to ensure that my license isn't in the process of
being removed.

Note that the notification (at the start of the 15 minutes) does
essentially work as a deprecation. During these 15 months it would already
be fair to say "you probably don't want to use this license because..."
Also you clearly couldn't use such a license as precedent in support of
approving a new license. So I think most of the reasons why you want to
remove licenses are already addressed at this stage.


> On the other hand, if a license is in use by a large community, I can
> imagine this taking *more* than 15 months.
>
>
If we are aware of the large community, then we can work with them and have
a dialogue. The problematic case is when we are not.



> >
> > - After 15 months, the license removal committee, having considered all
> > feedback it has  received, and taken into account potential newly found
> > projects where license is in use, can decide to remove the license from
> > the list of approved licenses.
> >
> > - Removed licenses will be listed on a separate page on opensource.org
> > <http://opensource.org>, together with the decision and justification
> > that caused them to be removed.
>

henrik
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/attachments/20200329/d3892ec7/attachment-0001.html>