Skip to content

docs: Bump copyright year automatically#510

Closed
pquentin wants to merge 2 commits intopython-trio:masterfrom
pquentin:docs-bump-year
Closed

docs: Bump copyright year automatically#510
pquentin wants to merge 2 commits intopython-trio:masterfrom
pquentin:docs-bump-year

Conversation

@pquentin
Copy link
Copy Markdown
Member

As a follow-up to #465 after @Fuyukai's #465 (comment).

@codecov
Copy link
Copy Markdown

codecov bot commented Apr 23, 2018

Codecov Report

Merging #510 into master will increase coverage by 0.04%.
The diff coverage is n/a.

Impacted file tree graph

@@            Coverage Diff             @@
##           master     #510      +/-   ##
==========================================
+ Coverage   99.27%   99.32%   +0.04%     
==========================================
  Files          89       89              
  Lines       10405    12578    +2173     
  Branches      721     1235     +514     
==========================================
+ Hits        10330    12493    +2163     
- Misses         58       66       +8     
- Partials       17       19       +2
Impacted Files Coverage Δ
trio/_util.py 98.74% <0%> (-1.26%) ⬇️
trio/tests/test_highlevel_open_tcp_listeners.py 99.29% <0%> (-0.71%) ⬇️
trio/__init__.py 100% <0%> (ø) ⬆️
trio/_highlevel_generic.py 100% <0%> (ø) ⬆️
trio/_core/tests/test_ki.py 100% <0%> (ø) ⬆️
trio/_signals.py 100% <0%> (ø) ⬆️
trio/_core/tests/test_local.py 100% <0%> (ø) ⬆️
trio/_core/__init__.py 100% <0%> (ø) ⬆️
trio/_threads.py 100% <0%> (ø) ⬆️
trio/_core/_local.py 100% <0%> (ø) ⬆️
... and 15 more

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 7f15b7f...a1e59df. Read the comment docs.

@pquentin pquentin requested a review from njsmith April 23, 2018 04:50
@njsmith
Copy link
Copy Markdown
Member

njsmith commented Apr 26, 2018

I'm sorry I've been procrastinating so much on making a decision here! I am being indecisive because this is obscure legal stuff that probably doesn't matter too much or... does it? Well, probably not enough to actually talk to a lawyer. But then I have to decide! Etc. But that's still no excuse to leave you hanging.

So, as far as I understand:

  • Copyright notices don't really... do that much. They don't need to be present, or accurate, for copyright to apply. But they can give you a somewhat better position in court if you do have to go to court, and they're cheap, so people generally use them: https://en.wikipedia.org/wiki/Copyright_notice#Reasons_to_include_an_optional_copyright_notice
  • Once a copyright notice is added, they can never ever be removed (b/c all the standard OSS licenses require that they be kept as a condition of having a license at all). Technically this even applies to copyright statements that are flat-out inaccurate. Unless the courts decided it didn't, I guess, because of some public interest consideration or something, look I'm not an IP lawyer.
  • There is a rule for what they're supposed to look like: https://en.wikipedia.org/wiki/Copyright_notice#Form_of_notice_for_visually_perceptible_copies
    • Basically: "ⓒ [year] [owner]", where "year" is the "year of first publication", which is awkward here because it was originally intended for like, books, which are generally published once and then never changed. I think for our purposes basically any content changes count as a "new publication". Maybe?

Options:

  • Merge this. I have some nervousness that automatically changing the year will lead to an incorrect notice that can never be removed. I guess in fact it's sort of inevitable since all software eventually becomes unmaintained. OTOH that's a long time from now and by definition will be someone else's problem. Also, seriously Nathaniel no-one cares about these technicalities. Practically every package on PyPI has broken licensing because setuptools doesn't provide any way to comply with a term that's present in every OSS license. This has literally zero practical consequences.

  • Decide to just keep it 2017 forever because again, who cares, and that's certainly not wrong. This is also a very popular strategy (more because of laziness than intention).

  • Put something like "Copyright Ⓒ 2017 and later, Nathaniel J. Smith and contributors", and figure that that will be accurate forever.

@pquentin pquentin changed the title Docs bump year docs: Bump copyright year automatically Apr 26, 2018
@smurfix
Copy link
Copy Markdown
Contributor

smurfix commented Apr 26, 2018

Put something like "Copyright Ⓒ 2017 and later, Nathaniel J. Smith and contributors", and figure that that will be accurate forever.

+1

@pquentin
Copy link
Copy Markdown
Member Author

Thanks! Okay, that's much more complicated than I thought it could be. :) The issue I have with keeping 2017 is that it makes it look like the docs are stale, so I would also be happy with option 3. Closing for now.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants