Record rejected licenses? #58
Comments
|
Hi @wking, Not trying to be snarky, but the OSI does not reject licenses per se, rather it never approves a license. A little background. Licenses are approved through a "License Review Process" (https://opensource.org/approval) where a "License Steward" submits a new license to "License Review" (a mailing list). Then anyone on that list (currently around 300 people) can raise issues with the license, e.g. conflicts with the OSD, ambiguity, duplicate, etc. Some Stewards may choose to respond to these issues, others may simply not follow up. For those that do not follow up, the license would simply be ignored with no vote warranted. However, if the Steward chooses to engage, they will need to address (fix, clarify or defend) the issues until they are resolved to the satisfaction of the License Review community. Once all the issues have been resolved, the OSi then crystallizes the consensuses (quietness) of the community with a vote for approval. If consensus is never achieved, then there is never a vote (to accept or reject). When it comes to licenses, OSI is not King; it is the Speaker of the House. Our role is to encourage participation, foster discussion/debate, collect/archive evidence, etc. By holding a public discussion of each license around the Open Source Definition, a consensus emerges that can then be crystallized by the OSI Board. With this approach, you probably would need to change the categories from “not (yet) considered” to “not (yet) submitted”, and from “considered and rejected" to "submitted and not (yet) voted on." You could find the latter by scraping the License Review list (https://lists.opensource.org/pipermail/license-review/) to find those that were introduced to the License Review list, but not on the current approved list. I have no way how to figure out all the licenses that might claim to be open source, but that were never submitted. Sorry this is probably not too much help for you, but I hope it makes sense. - Patrick |
|
So some cases: a. No OSI discussion. I agree that (a) is out of scope for this repo, and (b) is a low enough bar that I'm happy to consider it out of scope too. What I'm interested in here is (c). Or maybe that never happens, and the License Review Chair only puts licenses that will be approved before the Board? Folks interested in a formal ruling for a (b) license that had a not-open consensus could always ask for a formal Board decision to move it to (c). |
|
Also: e. Board considered and asked for more information. In which case it would be nice to record the request-for-info in the API too. |
|
Regarding "c", the board would never have a vote on a license that had not first reached a consensus among the community...more specifically, that the community could not find fault with. If the consensus of the community was that the license did not meet the criteria of the OSD, or if there were open issues presented by the community, unanswered by the Steward, we would not vote on it. Only when the community reaches silence (nothing left to complain about), will the chair of the License Committee introduce a motion to approve the license. I do not think any motion to approve has been defeated. But there have been many licenses introduced to License Review that never where introduced as a motion to approve during a Board meeting. So "C" would actually read, "Motion to Board for approval and defeated (possibly with public reasoning, e.g. a majority opinion piece)." There would be zero instances of this. Considering that, and what I think you are after, "B" might provide more value, "B. List discussion, but no Board decision." This would include CC0, "Do Whatever the **** you want..." etc. Again--I hope I am helping here. |
|
On Wed, Nov 01, 2017 at 11:53:43PM +0000, Patrick Masson wrote:
Regarding "c", the board would never have a vote on a license that
had not first reached a consensus among the community...more
specifically, that the community could not find fault with.
Is the community consensus always so obvious?
I do not think any motion to approve has been defeated.
If we are confident that this case will never happen, it seems like we
should drop “The OSI Board will make the final decision” from [1] and
just use “the License Review Chair considers the list to have reached
an approving consensus” as the test for approval. I expect the Board
vote is there because some licenses might deadlock the list, and you
need someone to break those ties. A slot in the API for (c) would
give a place for any licenses that fell into the
list-deadlock-board-rejected category.
Considering that, and what I think you are after, "B" might provide
more value, "B. List discussion, but no Board decision." This would
include CC0, "Do Whatever the **** you want..." etc.
But (b) is so easy to get to, and also covers active discussions. If
the CC0 is deemed not-open, can the board wrap up that consensus with
a shiny bow and say “we the board agree with the list that the CC0 is
not open for ${REASONS}. Don't ask us about it again unless you see
holes in those reasons”?
[1]: https://opensource.org/approval
|
|
Pull requests to the machine readable repo and discussion about how to collect this information are welcome. Until then, this will be closed because of a lack of historical data |
I was going to walk the minutes for motions. Would that be sufficiently complete for a first pass? |
|
You tell me :) But seriously, I have no idea how good it is or how complete it is. You may soon be the world's expert :) |
|
I'm working through the minutes now, and the 2005-09-12 minutes have acceptances, rejections, and deferrals (so all three cases I'm interested in :). And while I will aim for completeness, I think missing some rejected/deferred licenses is recoverable. If someone brings them up again, and someone else remembers the previous decision, the previous decision can always be added to this repository then. |
I don't know if the OSI has an existing policy on this, but it would be nice to have entries for licenses which have been considered by the OSI but rejected as non-open. Bonus points for listing the points from the OSD which were used as the grounds for rejection (or other reason, e.g. if it was rejected as a vanity/duplicate license), if the board comes to a consensus on that. The main reason for this would be to automatically list licenses from another list (e.g. the FSF's list) which had not been considered by the OSI. Currently you can use this API to filter out licenses which have been approved by the OSI, but you cannot distinguish between “not (yet) considered” and “considered and rejected”.
The text was updated successfully, but these errors were encountered: