<div dir="ltr"><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Mar 27, 2020 at 10:22 PM Josh Berkus <<a href="mailto:josh@berkus.org">josh@berkus.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Henrik,<br>
<br>
Thank you for proposing a process for this! Lemme add my $0.02 on what<br>
I would picture as a process.<br>
<br>
> - There should be a formally elected person or committee with authority<br>
> even just to (formally) start discussion about removing a specific<br>
> license. This is to protect and ease tensions in situations where 1 list<br>
> member proposes a license for removal and a proponent or user of that<br>
> license is therefore forced to forcefully defend it.<br>
<br>
I think we should have a license deprecation working group, appointed by<br>
the Board. However, *any* OSI member or contributor should be able to<br>
propose licenses for deprecation to this group. Just as anyone in the<br>
world can propose a new license for approval.<br>
<br></blockquote><div><br></div><div>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.</div><div><br></div><div>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".<br></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
> - As this process doesn't exist yet, I'm not saying that Josh' proposal<br>
> is out of place. But if such a gatekeeping process existed, this would<br>
> not be counted as a proposal to act. In such a situation Josh may have<br>
> phrased his email differently, for example as a question: "Why was this<br>
> approved back in 2002?" or "Is anybody using this license?".<br>
<br>
Disagree with you here, any member should be able to propose license<br>
deprecation to the committee. As the AAL has just shown, there's a huge<br>
backlog of unexamined licenses from the early years, and if block<br>
proposals from interested contributors, then the actual full review of<br>
the catalog is never going to happen. It's also not a terribly open<br>
source way to do this.<br>
<br></blockquote><div><br></div><div>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.</div><div><br></div><div>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.<br></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
> - 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>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.<br></div><div></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
> - 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 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.</div><div><br></div><div>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.)<br></div><div></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
> <br>
> Steps in removal process:<br>
<br>
- Someone, a committee member or a contributor, will propose to<br>
license-deprecation that a license needs to be deprecated and why<br>
<br>
> - OSI (license removal committee) will document the exact reasons why<br>
> license is proposed for removal.<br>
> <br>
> - OSI will spend reasonable efforts to find out whether license is still<br>
> in use.<br>
> <br>
> - In particular, OSI will contact the original author/submitter of the<br>
> license and all projects that at the time of approval were using or<br>
> intending to use the license.<br>
<br>
"will attempt to contact", given that most of the licenses we're talking<br>
about here are 15-20 years old.<br>
<br>
> - 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>
<br></blockquote><div><br></div><div>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.<br></div><div></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid 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>
<br></blockquote><div><br></div><div>To clarify, your added points are only for the scenario that the license author proposed to deprecate and remove?<br></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid 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>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.</div><div><br></div><div>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.<br></div><div><br></div><div></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
> - 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>
<br></blockquote><div><br></div><div>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.</div><div><br></div><div>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.<br></div><div><br></div><div>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.<br></div><div></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid 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>
<br></blockquote><div><br></div><div>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.<br></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
> <br>
> - After 15 months, the license removal committee, having considered all<br>
> feedback it has received, and taken into account potential newly found<br>
> projects where license is in use, can decide to remove the license from<br>
> the list of approved licenses.<br>
> <br>
> - Removed licenses will be listed on a separate page on <a href="http://opensource.org" rel="noreferrer" target="_blank">opensource.org</a><br>
> <<a href="http://opensource.org" rel="noreferrer" target="_blank">http://opensource.org</a>>, together with the decision and justification<br>
> that caused them to be removed.<br></blockquote></div><div dir="ltr" class="gmail_signature"><br></div><div class="gmail_signature">henrik <br></div></div>