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

Fri Mar 27 20:22:44 UTC 2020

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.

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

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

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

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

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

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

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

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

> 
> - 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
> 
> 
> 
> On Fri, Mar 27, 2020 at 12:17 AM Josh Berkus <josh at berkus.org
> <mailto:josh at berkus.org>> wrote:
> 
>     All,
> 
>     A submitter to License-Review just pointed out that we actually approved
>     this license back in 2002:
> 
>     https://opensource.org/licenses/AAL
> 
>     There is absolutely no question that the AAL would not meet our license
>     requirements today.  Both the badgeware requirements and the presumption
>     of single authorship are prohibitive.  Fortunately, the AAL is also not
>     popular; in fact, I can't even find it in the Github survey stats.
> 
>     As such, I move that the license be submitted to the board for removal
>     from the list of approved licenses, possibly by creating a new category
>     of "suspended and nonreusable licenses".
> 
>     -- 
>     Josh Berkus
> 
>     _______________________________________________
>     The opinions expressed in this email are those of the sender and not
>     necessarily those of the Open Source Initiative. Official statements
>     by the Open Source Initiative will be sent from an opensource.org
>     <http://opensource.org> email address.
> 
>     License-discuss mailing list
>     License-discuss at lists.opensource.org
>     <mailto:License-discuss at lists.opensource.org>
>     http://lists.opensource.org/mailman/listinfo/license-discuss_lists.opensource.org
> 
> 
> 
> -- 
> henrik.ingo at avoinelama.fi <mailto:henrik.ingo at avoinelama.fi>
> +358-40-5697354        skype: henrik.ingo            irc: hingo
> www.openlife.cc <http://www.openlife.cc>
> 
> My LinkedIn profile: http://fi.linkedin.com/pub/henrik-ingo/3/232/8a7
> 
> _______________________________________________
> The opinions expressed in this email are those of the sender and not necessarily those of the Open Source Initiative. Official statements by the Open Source Initiative will be sent from an opensource.org email address.
> 
> License-discuss mailing list
> License-discuss at lists.opensource.org
> http://lists.opensource.org/mailman/listinfo/license-discuss_lists.opensource.org
> 

-- 
Josh Berkus