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.

[mpacer]

I am somewhat on board with CC0 for small code snippets and maybe basic templates (like cookie cutters). However, I feel like in general for docs, larger code chunks & templates (those that we don't want to BSD as part of the libraries), tutorials, and fleshed out templates that give a lot of guidance should probably default to CC-BY (not SA… which seems contrary to the purpose of BSD/MIT licenses we have previously employed).

There are lots of reasons to do that, but the few that I can think of right now:

• it signals that we consider non-software contributions to be on par with software contributions in terms of their worth as intellectual property worth establishing attribution on
• it will be easier to enforce the Jupyter trademark if we do require attaching our brand to our non-software content
  • if we consider non-software projects intellectual property worth spending time on – which I'm guessing we all do – CC0 would literally make it impossible to enforce attribution, which means a dilution of the Jupyter brand in its ability to uniquely attach itself to the IP produced by Jupyter in a way that ensures that we are the IP source
• We can encourage contributors to release their own work CC-By (e.g., tutorials) and then separately submit them to the Jupyter org where we can incorporate it & modify it as it best makes sense for our project (while continuing to attribute the original work to the author unless they decide to retroactively assign partial copyrights to Jupyter).
  • this encourages people to put their own work out there and get credit for it, while at the same time giving us a clear path for integrating it into Jupyter IP with no pressure on us to do so (since the work has already been published and not in a CC0 way so the author will still assuredly get credit)

Edit: originally it say easier to enforce if we do not require attaching our brand, which is he opposite of what I intended as the follow up section hopefully made clear. But I edited for clarity to say do.

[minrk]

Excellent points, M! I agree that our docs should be CC-BY. I do believe that *examples* (e.g. code snippets in docs) should be CC-0 to make them most accessible in whatever project.

…

-Min

On Tue, Sep 12, 2017 at 10:05 AM, M Pacer ***@***.***> wrote: I am somewhat on board with CC0 for small code snippets and maybe basic templates (like cookie cutters). However, I feel like in general for docs, larger code chunks & templates (those that we don't want to BSD as part of the libraries), tutorials, and fleshed out templates that give a lot of guidance should probably default to CC-BY (not SA… which seems contrary to the purpose of BSD/MIT licenses we have previously employed). There are lots of reasons to do that, but the few that I can think of right now: - it signals that we consider non-software contributions to be on par with software contributions in terms of their worth as intellectual property worth establishing attribution on - it will be easier to enforce the Jupyter trademark if we do not require attaching our brand to our non-software content - if we consider non-software projects intellectual property worth spending time on – which I'm guessing we all do – CC0 would literally make it impossible to enforce attribution, which means a dilution of the Jupyter brand in its ability to uniquely attach itself to the IP produced by Jupyter in a way that ensures that we are the IP source - We can encourage contributors to release their own work CC-By (e.g., tutorials) and then separately submit them to the Jupyter org where we can incorporate it & modify it as it best makes sense for our project (while continuing to attribute the original work to the author unless they decide to retroactively assign partial copyrights to Jupyter). - this encourages people to put their own work out there and get credit for it, while at the same time giving us a clear path for integrating it into Jupyter IP with no pressure on us to do so (since the work has already been published and not in a CC0 way so the author will still assuredly get credit) — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#37 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAJReUZ-b6KfouXVQ9HWWweGyIFMHFFpks5shrnLgaJpZM4PRaCt> .

[jzf2101]

Is there a way we can ensure that more complex licensing terms be easily found? As far as I know, GitHub won't highlight our license if it isn't simple.

[minrk]

Great question! One is guidelines for new repos, as you suggested above. Another is separate license files in the docs and/or examples directories as appropriate for the given repo. However, we cannot easily change licenses of sections of existing repos if we didn't follow these guidelines already.

[willingc]

It would be helpful to have a template/cookiecutter/example/checklist when starting a new project repo.

General information on Licensing for Humans (not lawyers)

Karl Fogel's book Producing Open Source, which is open source, has a lot of useful information.

• License quickstart

• How to apply a license to your software

  • This section discusses copyright dates.
  • From book: The date should show the dates the file was modified, for copyright purposes. In other words, for a file modified in 2008, 2009, and 2013, you would write "2008, 2009, 2013" — not "2008-2013", because the file wasn't modified in most of the years in that range.

• Contributor agreements, CLA, and DCO It may be worth clarifying this as well.

License for Documentation - BSD recommendation

I agree with @jasongrout re: "Most documentation (except the code samples), websites, etc. should not be CC0 in my opinion." I would expect documentation written for a project to have the same modified BSD license. Personally, I expect the documentation that I have written and their associated builds to be BSD.

For simplicity, I would even keep tutorials, cookiecutters, etc. as BSD. It's much simpler than asking each time "should this be BSD or CC0". All of these have code to some degree for generation, build, etc. and there's really no big downside AFAIK to prefer BSD.

In general, consulting an attorney with experience in open source and licensing is the best approach.

[jasongrout]

It would be helpful to have a template/cookiecutter/example/checklist when starting a new project repo.

+1

In general, consulting an attorney with experience in open source and licensing is the best approach.

Definitely +1. Whatever consensus we come to should be run by someone like that, I think.

[ellisonbg]

To try and move the discussion forward a bit. Here are the main questions related to licensing and copyright that are being discussed: 1. What license(s) should we use for documentation? Code examples? 2. How do we handle the copyright year? On the matter of (1), do folks feel like there is an emerging consensus? On the matter of (2), we have heard different answers from different folks. Would folks like me to consult our NumFOCUS lawyer on this matter? Cheers, Brian

…

On Wed, Sep 13, 2017 at 6:49 PM, Jason Grout ***@***.***> wrote: It would be helpful to have a template/cookiecutter/example/checklist when starting a new project repo. +1 In general, consulting an attorney with experience in open source and licensing is the best approach. Definitely +1. Whatever consensus we come to should be run by someone like that, I think. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#37 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AABr0OvV0e92tNmeMWO4IKjhsaM3-WiRks5siCOugaJpZM4PRaCt> .

-- Brian E. Granger Associate Professor of Physics and Data Science Cal Poly State University, San Luis Obispo @ellisonbg on Twitter and GitHub [email protected] and [email protected]

[jasongrout]

Updates from the mailing list discussion linked above, where changes were approved by a number of Jupyter project leaders:

• Replace "Project Jupyter Team" by "Project Jupyter Contributors" in our copyright notice in files.
• Move to an exact copy of the BSD license rather than one with subtle changes.

These changes were implemented in JupyterLab and approved and merged by Fernando.