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.

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

Handling dates in copyright headers #1534

Open
justaugustus opened this issue Jan 26, 2022 · 11 comments
Open

Handling dates in copyright headers #1534

justaugustus opened this issue Jan 26, 2022 · 11 comments
Assignees
Labels
good first issue Good for newcomers

Comments

@justaugustus
Copy link
Member

justaugustus commented Jan 26, 2022

From @/swinslow in #1532 (comment):

(@justaugustus for visibility, I'm no longer employed by the LF, so I'm not speaking on their behalf here in any official way) :)

The LF's general guidance to projects over the past few years has been to recommend a copyright notice form that omits the year. I had previously written up a blog post that describes a "generalized" copyright notice format in some detail, which was related to earlier guidance for CNCF.

The main reason for this recommendation was to avoid the sort of question raised here: e.g. developers wondering every January whether or not to bump the notice up to the next year; with the real answer depending on an analysis of copyrightability of particular contributions that generally goes beyond what folks want to get into. And since the year is not mandatory in order for a work to be copyrighted, some projects have made the decision to omit it.

Keep in mind the caveats that (1) there's nothing wrong with including the year, this was just one recommendation; and (2) you'd never want to modify a copyright notice that names a particular third party without their consent.

Hope this helps :)

From @laurentsimon in #1532 (comment):

Thanks for the feedback. Let's discuss this in an issue and address it via a PR if we decide to update the dates or remove them entirely. @justaugustus can you create a tracking issue?

From @david-a-wheeler in #1532 (comment):

Given the previous comments from @/swinslow , we might want to change all copyright statements to something like:

// Copyright Security Scorecard Authors

See Copyright Notices in Open Source Software Projects. I believe the legal requirement for the copyright statement (with the date) ended in the US in 1976 :-).

@justaugustus justaugustus self-assigned this Jan 26, 2022
@naveensrinivasan naveensrinivasan added good first issue Good for newcomers help wanted Community contributions welcome, maintainers supportive of idea but not a high priority labels Jan 26, 2022
@singhsaurabh
Copy link

As a new in OpenSource Community, I would like to take this ticket to work on.

@singhsaurabh
Copy link

I would like to understand more on this ticket.
Thank You

@justaugustus justaugustus removed the help wanted Community contributions welcome, maintainers supportive of idea but not a high priority label Feb 22, 2022
@justaugustus
Copy link
Member Author

DISCLAIMER: I am not a lawyer

A few thoughts, some of which will echo kubernetes/repo-infra#248:

  • generated files should not require dates in the copyright header
  • most files probably do not require dates in the copyright header
  • OpenSSF projects should probably use Copyright OpenSSF Authors instead of Copyright <project> Authors moving forward

@justaugustus
Copy link
Member Author

  • generated files should not require dates in the copyright header

From Ed Warnicke in kubernetes/repo-infra#247 (comment):

Out of curiosity... are you checking for copyrights in generated files? I ask, because typically I tend to think of copyright checks as linting, and linters aren't supposed to lint generated files. Typically linters don't lint generated files, detecting that they are generated by looking for the pattern at the top of generated files:

^// Code generated .* DO NOT EDIT\.$

Per https://pkg.go.dev/cmd/go#hdr-Generate_Go_files_by_processing_source

@justaugustus
Copy link
Member Author

I would like to understand more on this ticket.

So I guess to more concretely answer this, a few things need to happen:

  1. Scorecard maintainers (@naveensrinivasan @azeemshaikh38 @laurentsimon me) need to decide if it's fine to elide the copyright date in all files (I'm personally fine with it)
  2. OpenSSF and scorecard maintainers need to decide if it's preferred to use OpenSSF Authors as the copyright holder for content in this repo and potentially elsewhere
  3. Someone (@singhsaurabh) will update the copyright headers in this repo (as well as any tests that enforce them) based on the decisions on 1 and 2

@laurentsimon
Copy link
Contributor

I'm fine with all the above.

@singhsaurabh
Copy link

Thanks @justaugustus

@azeemshaikh38
Copy link
Contributor

@singhsaurabh I have added this item in our bi-weekly. If you drop by, we can discuss this over call.

@singhsaurabh
Copy link

Thank you @azeemshaikh38

singhsaurabh pushed a commit to singhsaurabh/scorecard that referenced this issue Mar 7, 2022
singhsaurabh pushed a commit to singhsaurabh/scorecard that referenced this issue Mar 7, 2022
justaugustus pushed a commit to singhsaurabh/scorecard that referenced this issue Mar 8, 2022
@caniszczyk
Copy link

You can infer the LF stance from CNCF's copyright header policy, we updated it not so long ago:
https://github.com/cncf/foundation/blob/main/copyright-notices.md#copyright-notices

There's also information here:
https://www.linuxfoundation.org/blog/copyright-notices-in-open-source-software-projects/

@justaugustus
Copy link
Member Author

justaugustus commented Nov 30, 2022

Based on the feedback from @caniszczyk here and @mkdolan here, we should be fine to move forward with:

  • Non-generated files: Copyright [YYYY] OpenSSF Scorecard Authors
  • Generated files: Copyright OpenSSF Scorecard Authors

Some discussion and changes to this effect have started in #2428.

@afmarcum afmarcum moved this to In Progress in Scorecard - NEW Mar 7, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
good first issue Good for newcomers
Projects
Status: In Progress
Development

No branches or pull requests

6 participants