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

Ensure up-to-date copyright years #9070

Closed
lkuper opened this issue Sep 9, 2013 · 10 comments
Closed

Ensure up-to-date copyright years #9070

lkuper opened this issue Sep 9, 2013 · 10 comments
Labels
C-cleanup Category: PRs that clean code up or issues documenting cleanup.

Comments

@lkuper
Copy link
Contributor

lkuper commented Sep 9, 2013

People don't consistently update the year in the copyright block when they edit a file. Could we either (a) just globally update them all to the latest year when the year changes (as suggested by @thestinger on IRC), or (b) if we really have to have per-file copyright granularity, have tidy check that the copyright year matches the last-modified date of the file?

@thestinger
Copy link
Contributor

cc @brson - probably just have to ping Mozilla's legal department and see if we could handle the copyright year on a project basis rather than a file basis

As far as I know, we only have the per-file headers to avoid mistakes if someone extracts a portion of the project, and to keep it clear which files are under different licenses.

@brson
Copy link
Contributor

brson commented Jan 8, 2014

I've been given advice that the entire copyright line, including the date is legally all but worthless, so it basically doesn't matter whether we keep them up to date or not. It was suggested that we continue to do it on a best-effort basis and not sweat it, though I guess that's not too satisfying since putting any effort into something useless is kinda silly.

@brson
Copy link
Contributor

brson commented Jan 8, 2014

Having them be inconsistent also just rubs one the wrong way too. If anyone feel strongly we should add some automation here we can still consider it.

@ahmedcharles
Copy link
Contributor

Just curious, where's the check code that runs during the build to verify line lengths? That's probably easy to update to check the header of each file?

@brson
Copy link
Contributor

brson commented May 28, 2014

@ahmedcharles src/etc/tidy.py and src/etc/licenseck.py

steveklabnik added a commit to steveklabnik/rust that referenced this issue Jan 21, 2015
@frewsxcv
Copy link
Member

frewsxcv commented Feb 2, 2015

/cc @gerv since he was consulted in #21481

IANAL, but realistically I wouldn't think there's much of a difference if the year in the header is off by a couple years.

@gerv
Copy link

gerv commented Feb 2, 2015

The policy I recommend is:

  • Don't bother to update them
  • If someone does update them in a patch, ignore it (i.e. accept the patch without comment)

The actual copyright status of the file is unaffected by what it says at the top, so people for whom it's actually important when the copyright expires (i.e. no-one) will have to do more research in any case.

@frewsxcv
Copy link
Member

frewsxcv commented Feb 2, 2015

@gerv Sounds very sane in my opinion. Given that response, this can be closed?

@lkuper
Copy link
Contributor Author

lkuper commented Feb 2, 2015

Yeah, since filing this bug over a year ago I came to realize (from working on another project) that the dates in the files really don't matter. I also think it can be closed.

@alexcrichton
Copy link
Member

Ok, thanks for the info @gerv!

flip1995 pushed a commit to flip1995/rust that referenced this issue Jul 18, 2022
Make sure bors success depends on metadata_collection

r? `@xFrednet`

Currently bors runs the `metadata_collection` but merges before the run is finished, because the bors success dummy step didn't depend on it. This also makes sure that the `metadata_collection` test is run at the same time as the other base runs to not produce overhead.

changelog: none
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
C-cleanup Category: PRs that clean code up or issues documenting cleanup.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

7 participants