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

[McCoy Smith]

From: License-discuss <license-discuss-bounces at lists.opensource.org> On Behalf Of Henrik Ingo
Sent: Friday, March 27, 2020 2:20 AM
To: license-discuss at lists.opensource.org
Subject: [License-discuss] Generic process for removing approved licenses. Re: REMOVE AAL from list of approved licenses

 

This is clearly a proposal that's been a long time coming. Whether it will be these licenses or some others, eventually OSI will be in a situation where we want to remove approved licenses.

 

Since this is a serious decision, I'd like to open a separate thread on what might be an appropriate process to implement such removals. I'll propose something to get the discussion started:

 

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

 

If you’re going down this road, the first thing you need is for the OSI Board to discuss and vote on the concept of removal or deprecation of previously approved licenses.  This thread may trigger it, although note that the candidate who ran on a platform of doing exactly this came in 4th (or 5th, if you are using alternative math) in this year’s election, so one could easily argue those results indicate that there isn’t sufficient interest within the OSI membership to do this now.

 

If the Board does vote to do this, the License Proliferation Committee of ’04-’06 might serve as a model (although one could argue the results from that process were sub-optimal).

 

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

 

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

 

I’d argue at a minimum you’d need to define the criteria *first,* then apply those criteria against the list of approved licenses, and if the criteria are met, identify those licenses who meet them.  And the criteria ought to be made public so people understand what they are and the process is fair to all.

 

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

 

#1 should be a clear criterion to apply (although given ambiguities of some provisions of the OSD, there could be debate about even that). #2 would need to consider legacy code, and how one validates that no software anywhere uses a particular license is not an insubstantial task; #3 depends on the definition of what the “spirit” is and I’m not sure you’d ever get agreement on that.

 

Steps in removal process:

 

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

 

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

 

- Alternatively the license author can propose that the license be deprecated and removed.

 

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

 

- A feedback period of 15 months is required before the actual removal takes place.

 

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

 

This is similar to what I proposed a while back (https://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2020-February/021277.html https://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2020-February/021280.html ).  I think that involuntary removal or deprecation should only happen after a private communication has been made to the license steward to upgrade, fix, or otherwise voluntarily deprecate or retire their license.  And the criteria for why that is being ask is clear, and be applied equally to all licenses that meet/fail to meet them.

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