LICENCEs Guideline

[Carreau]

During JupyterCon sprints, one of the topic was to update our various repositories to ensure uniforme licensing terms. We got ~50 Pull-Requests about this topic and a few issues appeared or were discovered. This is thus an issue to discuss the licensing Guidelines.

A) LICENCEs files were added without consideration of Pre-existing COPYING files.

B) COPYING were renamed to LICENCE without updates of Manifest.in files leading to releases being uploaded without being Properly licensed.

C) Previous Copyright were removed or about to get removed

D) MIT project were almost relicenced as BSD without authors consents

D') Projects without licenses were added a BSD Licence without all authors approval

E) Some projects (docs, website tutorial) Got BSD and should get CC0?

F) Copyright Dates we updated to 2017

I'm Going to Focus on F in the following paragraph, but if we get a Guideline it would be good to cover other points.

According to Brian:

Here is the US law on copyright notices:

https://www.copyright.gov/title17/92chap4.html#401

tl;dr - we should use the first year of publication and don't need to
put -present as copyrights don't expire.

Jason pointed out :

• While the year is the date of the first publication, you may (should?) also list other years that significant contributions were made, as their copyright starts the year those contributions were published.

Fernando

Quick note - at the sprints in NYC on Saturday we had a brief chat about trying to simplify this as much as possible to avoid all that churn... I suggest we seek the simplest solution that is compliant with law but that avoids all the "January copyright update storm".

If simply listing file creation year is legally sufficient, I'm all for that. Like in many other areas, times of significant activity are adequately recorded by the VCS, so I don't think having a bunch of years listed in the file (or an updated endpoint) is really of any use.

And Paul

I left this as a comment in a recent JupyterLab PR that bumped the copyright verison: we moved to remove the end copyright date from files as we updated them in IPython starting back in 2012. The reason is that it keeps you from having to have a noop commit once per year that updates the whole repo's end dates. For more on this discussion, see ipython/ipython#1644

So can we get a clear guideline ni this repo and check all the PRs that have been recently made.

Note: We're asking other project to correctly use our licensing terms when they use some of our code, so let's do things properly.

[jzf2101]

Thanks for creating this issue @Carreau

[Carreau]

Response to Myself for what I would vote for:

1. Even if unnecessary use <Year>-Present to make it clear to anyone trying to modify the file.
2. Assume that "Significant changes" are recorded in VCS.
3. Provide a template file that says literally <First Publication year>-Present to make it clear to anyone using the "template".
4. Code should be BSD3 by default.
5. Repositories containing only documentation, tutorials, websites,... CC0.

The template file should be a markdown file with the LICENCE template in a triple backticks that list some of the point to manually check (existing of Copying, Manifest.in...).

Getting Licences right is a tricky process...

[Carreau]

@jzf2101 and I think we can also schedule a Bluejeans group call if we need a higher bandwidth.

[jasongrout]

Relevant information:

• US Copyright statutes: https://www.copyright.gov/title17/, with https://www.copyright.gov/title17/92chap4.html#401 specifically talking about the copyright notice
• International copyright guidelines: https://www.copyright.gov/fls/fl100.html
• GNU guidelines: https://www.gnu.org/prep/maintain/html_node/Copyright-Notices.html

Also, we've had other previous discussions on licenses recently, like:

• https://groups.google.com/forum/#!topic/jupyter/vZpWgw8zKdc
• Adopt the 3-clause BSD license template from opensource.org jupyterlab/jupyterlab#543

[Carreau]

Another suggestion, can/should we use the CodeOwner file even just for LICENCES, to enforce review by a specific team if the LICENCE file is touched ?

[jzf2101]

I'm fine with that

[jasongrout]

@Carreau - my understanding is that -Present is not correct - you get to claim copyright for substantial changes you've made, but if a repo is stagnant for a while with little or no activity, Present would not be correct.

Repositories containing only documentation, tutorials, websites,... CC0.

I think code that is meant to be examples that are copied should be CC0 (such as cookie-cutters). Most documentation (except the code samples), websites, etc. should not be CC0 in my opinion. Sometimes people do something like "the documentation is license so-and-so, and the code sample are CC0" as well.

[Carreau]

@jasongrout any other preferred thing for non-software, CC-BY ? CC-BY-SA ?(https://choosealicense.com/non-software/)

List of active (or merged) PRs that need to be checked once this is resolved (please edit):

• Create LICENSE ipython/ipython#10758
• Update LICENSE jupyterlab/mimerender-cookiecutter#63 (CC0 ified)
• Revise and rename copying.md to license nbgrader#876

[jzf2101]

We should probably also update https://github.com/jupyter/governance/blob/master/projectlicense.md when we propose appropriate changes.

[jzf2101]

Another thing that should be considered is that we should make it easy for users to find our license. GitHub indicates on the top bar of the repo page what kind of license is used if it's a text file under the name LICENSE. GitHub hasn't been able to identify our licenses when we use other conventions, see:

https://github.com/jupyter/notebook

[jasongrout]

@jasongrout any other preferred thing for non-software, CC-BY ? CC-BY-SA ?(https://choosealicense.com/non-software/)

See also the FSF guidelines for more ideas and an idea of how they do it: https://www.gnu.org/licenses/license-recommendations.html#documentation

[jzf2101]

We also should have an onboarding process for adding licenses to repos that join the jupyter orgs

[takluyver]

This is closely related to a pet peeve of mine: please don't assume that docs - or licensing - is an easy task for new contributors to work on. We aren't very interested in doing these things, so it's tempting to fob them off on new contributors, especially when we're struggling to find coding-related tasks for them. But then we get low quality contributions with a strong social pressure to accept them, because we've already misled someone into thinking that this is an easy, useful thing for them to do.