Update license guidelines for projects #66
Conversation
These changes come from discussion at jupyter#37 and on the mailing list thread https://groups.google.com/forum/#!topic/jupyter/vZpWgw8zKdc Summary of changes: * Update primary license name to 3-Clause BSD License to reflect the opensource.org and spdx.org primary names for the license * Make copyright owner “Project Jupyter Contributors” to reflect discussion in the mailing list thread. We do not view this as a change, but rather as a clarification of our shared copyright model. * Wrap all columns to 78 or fewer characters * Update BSD conditions to be enumerated with numbers, following the text on opensource.org and spdx.org * In condition 3, replace “Jupyter Development Team” with the exact license text “copyright holder”. * We previously had, in the disclaimer section, a sentence starting with “IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS…”. OWNER is now replaced with HOLDER, to reflect the license text on opensource.org and spdx.org * Update the per-file license statement with “Project Jupyter Contributors” and “3-Clause BSD License” terminology.
This also clarifies that for a particular project, its copyright is shared by its contributors (not necessarily *all* Jupyter contributors).
|
According to governance rules, this PR needs approval by 2/3 of the steering council, with at least 80% voting, to be merged. For our current size of 17, that means at least 14 total votes and at least 12 positive votes. Count my vote as 1. Of course community discussion is welcome as well. |
|
And of course, comments or suggestions are also encouraged and invited, not just an up-or-down vote. |
| Instead, Project Jupyter source code is the collective copyright of its | ||
| contributors. If individual contributors want to maintain a record of what | ||
| changes or contributions they have specific copyright on, they should indicate | ||
| their copyright in the commit message of the change when they commit the |
There was a problem hiding this comment.
I don't have an objection to this language because it specifically says this is to maintain a record. It still remains the case that a copyright holder's rights are intact irrespective of whether they explicitly say so.
The language in this clause does make it sound a little bit like those copyright notices should be in commit messages, but I think a close reading of this is actually correct, so I am not proposing a change. I am commenting here for clarity and also to invite disagreement if I've misunderstood.
There was a problem hiding this comment.
I had the same thoughts - the existing language was technically fine (though a bit awkward grammatically?), so I hesitated to change it too much.
|
|
||
| Copyright (c) YEAR Project Jupyter Contributors. |
There was a problem hiding this comment.
should YEAR here remain a placeholder, or do we put 2015, cribbing from the proposed deletion?
There was a problem hiding this comment.
Good question. I figured the year would change depending on when that specific repo was started, so I left it a placeholder.
| (also known as New or Revised or 3-Clause BSD), as follows: | ||
|
|
||
| - Copyright (c) 2001-2015, IPython Development Team | ||
| - Copyright (c) 2015-, Jupyter Development Team |
There was a problem hiding this comment.
does this deletion retroactively change the copyright that used to be there? I would have thought that any previous BSD license copyrights would remain in place, but maybe it's not a big deal here.
There was a problem hiding this comment.
I think probably Jupyter Development Team can be (optionally?) changed to Project Jupyter Contributors. I think any other copyrights probably ought to be left in place, and the Project Jupyter Contributors copyright should be appended. Thoughts?
There was a problem hiding this comment.
I think any other copyrights probably ought to be left in place, and the Project Jupyter Contributors copyright should be appended.
Makes sense to me.
|
cookies for anyone coming here from the Steering Council email list. 🍪 |
|
🍪 🍪 🥛 🍰 🍫 🎁 ☕️ |
|
Update: we've had 9 votes, all positive (as well as a bit of discussion). If you haven't voted, please vote or make a suggestion. I notice that the github approval mechanism does not have a way to vote negative, but we can count the "request changes" option as a negative vote. |
|
@jasongrout - I will abstain on this vote (I don't know enough about this topic). |
|
Good point, I hadn't considered abstaining. It seems reasonable that abstaining adjusts the total universe of voting members, so the threshold statement above becomes: According to governance rules, this PR needs approval by 2/3 of the steering council, with at least 80% voting, to be merged. For our current size of 17 minus one abstaining, that means at least 13 total votes and at least 11 positive votes. |
|
I think it does make sense for abstains to reduce the universe size
…Sent from my iPhone
On Sep 25, 2019, at 12:44 PM, Jason Grout ***@***.***> wrote:
Good point, I hadn't considered abstaining. It seems reasonable that abstaining adjusts the total universe of voting members, so the threshold statement above becomes:
According to governance rules, this PR needs approval by 2/3 of the steering council, with at least 80% voting, to be merged. For our current size of 17 minus one abstaining, that means at least 13 total votes and at least 11 positive votes.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or mute the thread.
|
Note that you should probably define a deadline for voting, unless this is a first-past-the-post system, as a winning condition (11 of 13 votes) can be made losing (11 of 17 votes) by late voters. |
Good point. I'm going by the book here (i.e., the governance docs have an explicit voting threshold for governance repo changes), which does not have a deadline mechanism for votes. |
On the other hand, to address your point more directly - perhaps after it passes the quorum threshold of 80%, a reasonable thing to do is to then set a timeframe for any remaining votes before calling the decision. |
There was a problem hiding this comment.
This fits our spirit in embracing the copyright owners as the "Project Jupyter Contributors". Thank you @jasongrout for pushing this through.
|
Thank you to everyone that responded. We now have quorum (13), with all positive votes, which means that this PR is approved. I'll leave it open until Monday for any remaining dissenting votes or more discussion, then merge Monday if there are no objections. Thanks again everyone! |
|
Thanks Jason for the ping. Approved. |
|
Quorum reached, merging. |
|
Thanks Kyle! |
|
And thanks again everyone else for participating and adding your thoughts! |
This follows up on conversation in #37 and the mailing list discussion about updating our project license and copyright terms to be more clear and conform better to the opensource.org and spdx BSD license pages.
Fixes #37
Summary of updates
Update primary license name to 3-Clause BSD License to reflect the opensource.org and spdx.org primary names for the license
Make copyright owner “Project Jupyter Contributors” to reflect discussion in the mailing list thread. We do not view this as a change, but rather as a clarification of our shared copyright model.
Wrap all lines to 78 or fewer characters
Update BSD conditions to be enumerated with numbers, following the text on opensource.org and spdx.org
In condition 3, replace “Jupyter Development Team” with the exact license text “copyright holder”.
We previously had, in the disclaimer section, a sentence starting with “IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS…”. OWNER is now replaced with HOLDER, to reflect the license text on opensource.org and spdx.org
Update the per-file license statement with “Project Jupyter Contributors” and “3-Clause BSD License” terminology.
I also edited our copyright policy explanation for grammar and to clarify that for a particular project, its copyright is shared by its contributors (not necessarily all Jupyter contributors).