Add Foundation-wide copyright guidance

[brianwarner]

This PR adds Foundation-wide copyright guidance on how to add copyright
notices to source code headers. This document is based on the guidance document
from CNCF, available here:
https://github.com/cncf/foundation/blob/master/copyright-notices.md

To be absolutely clear, do NOT modify an existing copyright line unless you put it
there, or have explicit permission from the one who did. This guidance only
applies to copyright notices which are APPENDED to the existing list of
notices.

In addition, the OpenJS Foundation Board of Directors recently approved
standardized website footers for projects to use. These include the copyright
notice, as well as trademark notices and links to Foundation-wide policies. One
notice is for projects related to Node.js, and includes a line referencing the
trademark license. The other is for projects which are unrelated to Node.js,
and omits the line.

If you have any questions, please reach out to legal-questions@openjsf.org

Signed-off-by: Brian Warner brian@bdwarner.com

[ljharb]

this seems to talk about "no notice" versus "a notice in every file", but doesn't seem to mention the far more reasonable option of "copyrights only go in the license file".

[brianwarner]

With more organizations doing automatic license scanning, an unmodified, standard license file tends to be the least error-prone. That said, projects can choose when and in which files to include these additional copyright notice lines, and this guidance applies whether they choose to put these additional lines in individual files, a single LICENSE file, or no files at all.

[ljharb]

The copyright section detection generally is a bit fuzzier for this reason; but i'm mainly concerned about any advice that suggests that it's a good idea to put boilerplate metadata in every file - that's what version control is for :-)

[brianwarner]

Agreed, yes. It gets out of date easily and has no guarantee of correctness. That's one of the reasons this recommends against doing that. But if you feel you need to, it provides guidance on how to do it properly.

[tobie]

Suggested a session on these IP-related issues at the collab summit next week here. Additional subtopics welcomed.

[brianwarner]

Unfortunately I can't make it to the collab summit, but will be around all day Wednesday to discuss. I'd be happy to take as much time is needed for this.

Please note though that I'm only the messenger and while I'm familiar with the docs and can ask questions of Foundation counsel, I don't approve changes. :-) Per the organizational bylaws, the IP policy is set by the board of directors, although I'm happy to help clarify where I can.

[tobie]

Good point, @brianwarner. See my comment about this here: #390 (comment). I feel like a joint session between the CPC and Board would be incredibly useful (if that's not already planned).

[mhdawson]

I think one of the key things is capturing the feedback from the projects to help both legal and the board understand the concerns. I see that as an ongoing process we need to make sure happens. In this specific instance, while the documents may be new, they to a large extent are based on what was in place in the JS and Node.js foundations so not necessarily "new" in terms of content.

As new projects join (like AMP) we will likely have new/different concerns and we need to get the process in place capture those and figure out how those got into updates of the existing docs like the IP policy. @brianwarner I think you in addition to the CPC board reps (myself included) need to be part of the return feedback loop as opposed to just being "messengers".

Depending on the progress on capturing/documenting concerns/recommendations at the Collab summit next week we should define next steps.

In terms of documenting current guidance based on the approved Policy in the CPC repo, I'm wondering if that can be decoupled from desired updates? My perspective is that as long as the doc is accurate based on the current IP policy it's better to have it documented versus not.

[mhdawson]

LGTM

[mhdawson]

@openjs-foundation/cpc any questions for @brianwarner on this? If not more approvals would help us get it landed.

[molant]

Where should this copyright statement live? In COPYRIGHT.md? README.md? Another file?

[boneskull]

I'm going to guess LICENSE is appropriate, but we should be specific about it. @brianwarner?

[brianwarner]

To the extent that a project wishes to add a new copyright statement, it can go in any of the above, or none of the above. Given that adding a copyright line is optional I might suggest not getting too prescriptive about it, my concern being that people may wonder if they need to move lines around. That's a situation we want to avoid, as it is ripe for error.

That said, LICENSE would be a great option, as many license texts include a template copyright line and it's a logical place to look.

But again, just to be sure, I'd suggest we hold off on being too explicit here, as it could be interpreted counter to "it is optional, add it if you feel you need to, but be absolutely certain not to change anything that's already there."

[boneskull]

I would agree with @tobie (comment) in that I want the directions to be prescriptive, so I don't have to think about it--even if the details are somewhat arbitrary.

[mcollina]

LGTM

[mikesamuel]

Could we explain these acronyms?

Whether a project uses a
<abbr title="Developer Certificate of Origin">[DCO][]</abbr>
or a
<abbr title="Contributor License Agreement">CLA</abbr>

[DCO]: https://developercertificate.org/

[boneskull]

@brianwarner

I think I mentioned this before, but this hasn't always been the case.

The JS Foundation had the original author of Mocha and AFAIK every contributor to reassign the copyright to the JS Foundation.

I'm going to assume that means we need to change the copyright notice (in LICENSE file) from:

Copyright (c) 2011-2018 JS Foundation and contributors, https://js.foundation

to

Copyright (c) 2011-2020 OpenJS Foundation and contributors, https://openjsf.org

???

If this is the case, please add guidance for those projects that the Foundation does retain the copyright to.

[brianwarner]

Hey @boneskull,

Yes, correct, my understanding is that the foundation's stance on copyright has gone through a number of iterations. The current one is more permissive than the prior two iterations, where now adoption of a CLA is optional, with the decision to be made by the project's maintainer(s).

Because the JS Foundation merged into the OpenJS Foundation, it is factually accurate to update "JS Foundation" to "OpenJS Foundation." This came up in another comment thread, and we can add this to the document when we revise it.

[brianwarner]

Could we explain these acronyms?

Whether a project uses a
<abbr title="Developer Certificate of Origin">[DCO][]</abbr>
or a
<abbr title="Contributor License Agreement">CLA</abbr>

[DCO]: https://developercertificate.org/

I just pushed a patch which expands these acronyms and links to the upstream documents.

[brianwarner]

Hey @boneskull,

Yes, correct, my understanding is that the foundation's stance on copyright has gone through a number of iterations. The current one is more permissive than the prior two iterations, where now adoption of a CLA is optional, with the decision to be made by the project's maintainer(s).

Because the JS Foundation merged into the OpenJS Foundation, it is factually accurate to update "JS Foundation" to "OpenJS Foundation." This came up in another comment thread, and we can add this to the document when we revise it.

I just pushed a patch which explicitly adds this into the guidance.

[mikesamuel]

Should projects encourage .git/hooks/pre-commit and/or use CI/CD checks to flag content that doesn't comply. Is this something that could be templatized?

[boneskull]

somebody could write a linter that checks for this stuff, but it seems like it should be updated so rarely that it's probably not worth the bother..

[brianwarner]

I would be inclined to agree with @boneskull here, changes to these lines should be a rarity.

[mikesamuel]

Are these required on all source files?

I agree that, once present, they're unlikely to change, but if they are per-file boilerplate, then a linter might be useful for new source files.

[ljharb]

Please let's not require the ancient and obsolete-in-the-wider-ecosystem practice of per-file boilerplate.

[brianwarner]

@molant I'm checking on this specific situation, and will get back to you when I get an answer. Thanks for raising it.

[brianwarner]

@molant Ok, got an answer for you.

Because JS Foundation merged into the OpenJS Foundation, it would be factually correct to update this to OpenJS Foundation. However, since these notices are informational in nature and optional, it is up to the maintainer of the file whether to update this specific line.

In other words, it can't hurt to update it, but it is not required either.

Does this help?

[mikesamuel]

@brianwarner @ljharb If the lawyercats agree that per-file (C) boilerplate is unnecessary and that having it on old files and not putting it on new doesn't put the new files in a different legal category than the old, that addresses my concerns.

[brianwarner]

@mikesamuel Yep, that's correct.

[molant]

Does this help?

Yes, thanks a lot!

[boneskull]

I'm going to guess LICENSE is appropriate, but we should be specific about it. @brianwarner?

[boneskull]

somebody could write a linter that checks for this stuff, but it seems like it should be updated so rarely that it's probably not worth the bother..

[boneskull]

Do we display these in our README.md? Or web site? Or both?

[mhdawson]

Based on the discussion at the collaborator summit last week I think I was a bit confused. I thought this was directly importing the approved IP policy. As an interpretation of the policy to provide guidance we might have have more leeway to tailor.

@tobie do you have suggested changes or is that you were suggesting we have a discussion of the overall approach. If so we could set something up early in January.

[joesepi]

LGTM as "guidance."

Which makes me wonder if COPYRIGHT-NOTICES is a good name for this file. I'm not familiar with prior art in this area.

[tobie]

@mhdawson well, now that we've established that this is a guidance document that interprets the IP policy, I would suggest revisiting the document with the following goals in mind (all other things being equal):

1. Limit legalese in repositories to a maximum (legalese is there to protect the foundation, the project, the contributors, and the users; it is not decorum).
2. Be prescriptive (don't make contributors and reviewers waste cycles on having to make decisions about these issues when opening/reviewing pull requests), but explain/justify the decisions.
3. Offer clear paths for dealing with new content and migrated content.
4. Offering the possibility for projects wanting something more specific to reach out to Brian.

[tobie]

On today's CPC call we agreed to have @brianwarner and myself get together offline to revisit the document and submit an updated version.

[boneskull]

Please reformat these as fenced code blocks (without backslash escapes); it's difficult to copy-paste it. If you try to copy the raw code, you get escapes, but if you try to copy the rendered text, you lose the links.

[brianwarner]

I just pushed a patch which adds rendered HTML, markdown in code fences and without line breaks or escaped chars, and raw HTML.

[boneskull]

Please reformat footers into a fenced code block (```) so we can more easily copy/paste this into our sites.

Don't hard-wrap the code either; this breaks links

[tobie]

@brianwarner and I just chatted about this offline.

We agreed that the document should be renamed "IP Policy Guidance" and would be the single entry point for anything related to copyright/patent issues for OpenJSF projects.

We agreed that we could split up the document in two sections:

1. a super short TL;DR

The goal of that document would be to address the requirements of the vast majority of projects. It would basically contain those five points:

1. Don’t change copyright lines unless you put them there
   
1. If you do need to add a copyright line, see the guidance below.

2. Only use the open source licenses that are pre-approved in the IP policy
3. If you need to use a different license, please ask the board

4. Add the standard footer to your project website
5. If in doubt on anything related to the IP policy, please see below and/or ask


2. a section for those wanting do dig deeper

This would contain the already submitted text (which is essentially the standard Linux Foundation copyright guidance document), potentially reframed as more of an FAQ.

Next steps:

• @brianwarner to add the above TL;DR to the doc
• @brianwarner to rename the doc to "IP Policy Guidance".
• @tobie to have a look at the whole document and reformat it so that the two sections are clearly labeled, separated, and explained/introduced.
• @tobie to address all pending issues that are resolved by this change.
• @tobie to raise issues that aren't with @brianwarner.
• If changes are deemed substantial, @brianwarner to get the document re-checked by legal.
• Re-request reviews from everyone.

[tobie]

I'm not sure how to best incorporate my suggested changes here so I currently added the proposed alternative text to a dedicated branch.

There are attribution issues with my proposal in its current state (@brianwarner is the main author of the whole thing, I just pruned and remixed it a bit). This will be fixed when I add it to this PR, but since the changes are important, pushing those changes to this PR or adding them as a code suggestion didn't feel like the right way to proceed.

Should I open a new PR with this rewrite proposal?

Would appreciate your thoughts.

[tobie]

With #618 now merged, should we close this?