Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add Foundation-wide copyright guidance #414

Closed
wants to merge 5 commits into from
Closed

Add Foundation-wide copyright guidance #414

Changes from 1 commit
Commits
Show all changes
5 commits
Select commit Hold shift + click to select a range
ce2df3d
Add Foundation-wide copyright guidance
brianwarner Nov 26, 2019
5ab2059
Rename file to reflect new contents
brianwarner Jan 24, 2020
2bb2635
Add essential IP Policy guidance
brianwarner Jan 27, 2020
9134b13
Update formatting to make it easier to read/copy
brianwarner Jan 27, 2020
13c5f53
Add definition of abbreviations
brianwarner Jan 27, 2020
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
138 changes: 138 additions & 0 deletions COPYRIGHT-NOTICES.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,138 @@
<!-- SPDX-License-Identifier: CC-BY-4.0 -->

# Copyrights and OpenJS Foundation projects

## Ownership of Copyrights in OpenJS Foundation Contributions

When source code, documentation and other content is contributed to an Open JS Foundation
project, the copyrights in those contributions remain owned by the original
copyright holders.

The copyrights are not _assigned_ to OpenJS Foundation. Instead, they are _licensed_ for
distribution as part of the project. Whether a project uses the DCO or a CLA,
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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/

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@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.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

the original copyright holders retain their copyrights.

## Copyright Notices

OpenJS Foundation does not require or recommend that every contributor include their
copyright notice in contributed files. [See below for more details on why
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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".

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Member

@ljharb ljharb Nov 26, 2019 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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 :-)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Contributor

@tobie tobie Dec 4, 2019 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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).

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

not.](#why-not-list-every-copyright-holder)

Instead, OpenJS Foundation recommends using a more general statement in a form similar to the
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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."

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

following (where XYZ is the project's name):

- **Copyright The XYZ Authors.**
- **Copyright The XYZ Contributors.**
- **Copyright Contributors to the XYZ project.**

These statements are intended to communicate the following:
- the work is copyrighted;
- the contributors of the code licensed it, but retain ownership of their copyrights; and
- it was licensed for distribution as part of the named project.

By using a common format, the project avoids having to deal with names of
copyright holders, years or ranges of years, and variations on the (c) symbol.
This aims to minimize the burden on developers and maintainers as well as
redistributors of the code.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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..

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@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?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@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.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@mikesamuel Yep, that's correct.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Does this help?

Yes, thanks a lot!


## What if I want my copyright notice included?

Please note that it is _not wrong_, and it is acceptable, if a contributor
wishes to keep their own copyright notices on their contributions. The above is
a recommended format for ease of use, but is not mandated by OpenJS Foundation.

If you are contributing on behalf of your employer, you may wish to discuss with
your legal department about whether they will require you to include a copyright
notice identifying them as the copyright holder in contributions.

## What about Third Party Code?

If a file only contains code that originates from a third party source who
didn't contribute it themselves, then you would _not_ want to add the notices
above. (In a similar vein, you wouldn't add a notice identifying you as the
copyright holder either, if you didn't own it.) Just preserve the existing
copyright and license notices as they are.

If, however, you add copyrightable content to a pre-existing file from another
project, then at that point you could _add_ a copyright notice similar to the
one above.

## Don't Change Someone Else's Notice without their Permission

You _should not_ change or remove someone else's copyright notice unless they
have expressly permitted you to do so. This includes third parties' notices in
pre-existing code.

## Why not list every copyright holder?

There are several reasons why OpenJS Foundation doesn't require or recommend trying to list
every copyright holder for contributions to every file:

- Copyright notices are not mandatory in order for the contributor to retain
ownership of their copyright.
- Copyright notices are rarely kept up to date as a file evolves, resulting in
inaccurate statements.
- Trying to keep notices up to date, or to correct notices that have become
inaccurate, increases the burden on developers without tangible benefit.
- Developers and maintainers often do not want to have to worry about e.g.
whether a minor contribution (such as a typo fix) means that a new copyright
notice should be added.
- Adding many different copyright notices may increase the burden on downstream
distributors, if their license compliance processes involve reproducing
notices.
- The specific individual or legal entity that owns the copyright might not be
known to the contributor; it could be you, your employer, or some other entity.

## Copyright notices for website footers

Please use one of these standard footers, which have been approved by OpenJS
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Foundation legal counsel and the Board of Directors:

### For nodejs.org, and projects which reference Node.js

> Copyright [OpenJS Foundation](https://openjsf.org) and \[project
name\] contributors. All rights reserved. The [OpenJS
Foundation](https://openjsf.org) has registered trademarks and uses
trademarks.  For a list of trademarks of the [OpenJS
Foundation](https://openjsf.org), please see our [Trademark
Policy](https://trademark-policy.openjsf.org/) and [Trademark
List](https://trademark-list.openjsf.org/).  Node.js is a trademark of
Joyent, Inc. and is used with its permission.  Trademarks and logos not
indicated on the [list of OpenJS Foundation
trademarks](https://trademark-list.openjsf.org) are trademarks™ or
registered® trademarks of their respective holders. Use of them does not
imply any affiliation with or endorsement by them.
>
> [The OpenJS Foundation](https://openjsf.org/) \| [Terms of
Use](https://terms-of-use.openjsf.org/) \| [Privacy
Policy](https://privacy-policy.openjsf.org/) \| [OpenJS Foundation
Bylaws](https://bylaws.openjsf.org/) \| [Trademark
Policy](https://trademark-policy.openjsf.org/) \| [Trademark
List](https://trademark-list.openjsf.org/) \| [Cookie
Policy](https://www.linuxfoundation.org/cookies/)

### For projects unrelated to Node.js:

> Copyright [OpenJS Foundation](https://openjsf.org) and \[project
name\] contributors. All rights reserved. The [OpenJS
Foundation](https://openjsf.org) has registered trademarks and uses
trademarks.  For a list of trademarks of the [OpenJS
Foundation](https://openjsf.org), please see our [Trademark
Policy](https://trademark-policy.openjsf.org/) and [Trademark
List](https://trademark-list.openjsf.org/).  Trademarks and logos not
indicated on the [list of OpenJS Foundation
trademarks](https://trademark-list.openjsf.org) are trademarks™ or
registered® trademarks of their respective holders. Use of them does not
imply any affiliation with or endorsement by them.
>
> [The OpenJS Foundation](https://openjsf.org/) \| [Terms of
Use](https://terms-of-use.openjsf.org/) \| [Privacy
Policy](https://privacy-policy.openjsf.org/) \| [OpenJS Foundation
Bylaws](https://bylaws.openjsf.org/) \| [Trademark
Policy](https://trademark-policy.openjsf.org/) \| [Trademark
List](https://trademark-list.openjsf.org/) \| [Cookie
Policy](https://www.linuxfoundation.org/cookies/)
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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


## Getting help

If you have a question about this policy or how to implement it, please reach out to [legal-questions@lists.openjsf.org](mailto:legal-questions@lists.openjsf.org).