doc: Bump copyright years to present (headers only)

maflcko commented at 11:49 am on January 5, 2023: member

The copyright years have many issues:

They may be wrong. For example, this can happen when code is moved from one file to a different one without taking over the copyright years. Or it may happen when the wrong years are inserted by a script or developer.
They are redundant. git already tracks the author date for every line of code in every commit.
They are not needed to establish “copyright”, see https://www.linuxfoundation.org/blog/copyright-notices-in-open-source-software-projects/, or https://reuse.software/faq/#years-copyright. Also, anyone who needs them for legal reasons would need to discover the ground truth themselves anyway. For example, with git blame, or git log ..., or by other means.
They cause pointless churn. See for example commit 306ccd4927a2efe325c8d84be1bdb79edeb29b04, or drive-by contributions bumping them.
Many modern open source software projects never added them in the first place, or already removed them, see section below.

In theory they can be removed completely. While this should be legally fine, some contributors raised legal uncertainty. So instead, bump each year range one final time to -present and leave the initial year untouched.

Moreover, a URL redirect is resolved in the second commit.

Finally, the _COPYRIGHT_YEAR build constant is kept untouched, and still expected to be bumped every year, see for example commit 06dd571534c8ecdf7ade77546fcf3a56b3651f68. In theory it could be bumped to -present as well, but this change would cause user-visible changes, so discussion should be done in a separate thread.

Examples of removed years in other projects:

https://github.com/facebook/react/commit/b87aabdfe1b7461e7331abb3601d9e6bb27544bc (Done before accepting external contributions?)
https://github.com/curl/curl/commit/2bc1d775f510196154283374284f98d3eae03544 (Not legally reviewed?)
…

Examples of no years in other projects:

DrahtBot commented at 11:49 am on January 5, 2023: contributor

The following sections might be updated with supplementary metadata relevant to reviewers and maintainers.

Reviews

See the guideline for information on the review process.

Type	Reviewers
Concept ACK	1440000bytes, hebasto, achow101, pinheadmz, hernanmarino
Stale ACK	fanquake

If your review is incorrectly listed, please react with 👎 to this comment and the bot will ignore it on the next update.

Conflicts

Reviewers, this pull request conflicts with the following ones:

#26940 (test: create random and coins utils, add amount helper, dedupe add_coin by jonatack)
#26863 (test: merge banning test from p2p_disconnect_ban to rpc_setban by brunoerg)
#25361 (BIP324: Cipher suite by dhruv)
#24545 (BIP324: Enable v2 P2P encrypted transport by dhruv)
#23561 (BIP324: Handshake prerequisites by dhruv)
#23233 (BIP324: Add encrypted p2p transport {de}serializer by dhruv)

If you consider this pull request important, please also help to review the conflicting pull requests. Ideally, start with the one that should be merged first.

DrahtBot renamed this:
~~doc: Remove copyright years~~
doc: Remove copyright years
on Jan 5, 2023

DrahtBot added the label Docs on Jan 5, 2023

real-or-random commented at 2:44 pm on January 5, 2023: contributor

The interesting question is one is allowed to do this.

Let’s ask the license first. The license in COPYING is (emphasis mine):

The MIT License (MIT)

Copyright (c) 2009-2023 The Bitcoin Core developers Copyright (c) 2009-2023 Bitcoin Developers

Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the “Software”), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:

The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software. (…)

So if you read that literally, then at least the license only cares about the “above” copyright notice (in COPYING) and not these in the source files… Good. But all the files say they’re covered by the license, too. Hm.

Okay, now what about the law?

Let’s look at some examples:

US:

17 U.S. Code § 506 - Criminal offenses (d) Fraudulent Removal of Copyright Notice.— Any person who, with fraudulent intent, removes or alters any notice of copyright appearing on a copy of a copyrighted work shall be fined not more than $2,500.
(https://www.law.cornell.edu/uscode/text/17/506)

I guess removing the date is altering the noting. And okay, I suspect the intent here is not fraudulent but you want to risk it?

Germany:

UrhG, Section 39 (translated) Alterations of work (1) The holder of a right of use is not permitted to alter the work, its title or designation of authorship (section 10 (1)), unless otherwise agreed. (2) Alterations to the work and its title to which the author cannot refuse consent based on the principles of good faith are permitted.

Note that the exception in (2) does not include the designation of authorship. So there’s a good chance that removing the date would violate (1).

Bad enough but what about a few hundred other jurisdictions? And the law of which jurisdiction does apply here? That was a difficult question even before the Internet and it’s much more difficult now, and even more difficult with projects like these which can be download from almost every jurisdiction in the world (probably from servers in different jurisdictions) and has contributors from different jurisdictions, for some of which we don’t even know the jurisdiction, e.g., the original author of the software.

International copyright law is pretty much not helpful. That’s how it is and I think we need to accept this.

But I’m not a lawyer, I just happen to be interested in legal stuff a little bit. So here’s what you should do: Talk to a lawyer, e.g,, try to contact a Bitcoin legal defense fund and see what they think. In libsecp256k1, we also would like to simplify the license handling. (It’s actually on my list to contact someone for libsecp256k1.) Maybe an expert lawyer has some clever suggestion. For example, I could imagine to simply introduce a rule that says to never update copyright notices. (That certainly won’t alter them!) That’s even simpler than this PR.

But again, an expert response will certainly be more helpful than mine.

maflcko commented at 3:22 pm on January 5, 2023: member

Yeah, I don’t mind having a lawyer double check this change. However, if there is legal doubt that this change can be made, likely most other changes (even those not touching the notices) will require legal review as well, which would bring the open source project to a halt or at least cause a significant bottleneck.

For example, bumping the copyright might equally be questionable. I see that you suggest to never update the notices. Though, that will be impossible to implement in practice when code is moved from one file to another and the notice in the two files is not char-by-char-equal. I guess you could have another rule to forbid moving code from now on, but what about major rewrites of a piece of code. What about minor modifications to the code. …?

In any case, if there is a legal basis for a rule to never modify the notice, or modify it only on “specific” occasions, we’d also need a legal basis to decide whether it is fine to just leave the “latest” version of the notice or if we have to restore any or all previous iterations. All lines I am touching in this pull request have been heavily modified or “invented” out of thin air by someone other than the original author. (Not going to list the commits here to avoid blame, but there are commits to add “missing” notices to files that didn’t have one. There are commits that change the notice text from “Bitcoin” to “Bitcoin Core”, or other copy-edits. Finally, there are commits to modify the year ranges, even the starting year).

Again, I don’t object having a legal double check here, but I’d be surprised if they reached a different conclusion than the previous legal reviews done by the legal teams of Meta, Microsoft, Google, LLVM, Linux Foundation, etc …

unknown approved

unknown commented at 3:32 pm on January 5, 2023: none

Concept ACK

After reading the links provided by PR author and a few Q&A on https://opensource.stackexchange.com/, I agree with the changes in this PR.

Changing copyright notice and removing year should not have any legal issues IMO.

real-or-random commented at 3:40 pm on January 5, 2023: contributor

Again, I don’t object having a legal double check here, but I’d be surprised if they reached a different conclusion than the previous legal reviews done by the legal teams of Meta, Microsoft, Google, LLVM, Linux Foundation, etc …

If there was legal review at all. And if the review was sound. And Ignoring the legal implications/taking the risk may be totally reasonable for some projects.

And I think it really depends on the case. For example in facebook/react@b87aabd, Facebook is the only copyright holder and the original author. They can do whatever they want. (Whose right could they possibly be violating?) The curl change doesn’t look like it got legal review. In case of the Microsoft, Google, and LLVM examples, they never had a year in the notice, so they didn’t alter it.

For the blog post by the Linux Foundation: Yes, the best advice for new projects is simply omit the notice entirely. (I highly recommend this to everyone!) But the situation here is different. And the referenced blog post literally says:

Don’t change someone else’s copyright notice without their permission

You should not change or remove someone else’s copyright notice unless they have expressly (in writing) permitted you to do so. This includes third parties’ notices in pre-existing code.

Though, that will be impossible to implement in practice when code is moved from one file to another and the notice in the two files is not char-by-char-equal.

In that case you could probably move the notice along with the moved code. :shrug: But yeah, I totally agree the entire issue is annoying.

After reading the links provided by PR author and a few Q&A on opensource.stackexchange.com, I agree with the changes in this PR.

Have you read this one? https://opensource.stackexchange.com/questions/6582/can-i-remove-some-copyright-holders-from-headers-and-replace-them-by-a-generic

maflcko commented at 3:55 pm on January 5, 2023: member

They can do whatever they want. …

Yeah, looks like I missed that they did the change before any external contributions were accepted (at least via GitHub). Edited OP.

sillsm commented at 11:40 pm on January 12, 2023: none

Hi,

I’m Max. I am the general manager for COPA and I helped form the Bitcoin Legal Defense Fund. I am not the Bitcoin project’s lawyer, but I have been doing open source licensing and policy for a while, so hopefully I can volunteer some thoughts to help close the PR.

I agree with Marco’s proposal and I think it’s fine. Files don’t need years on them for any reason, so if it’s easier to manage the project without them, remove them. There’s an argument that they are good pieces of evidence for when files were authored. But as long as you don’t squash the history, the removed years will still be preserved forever in the git history. Ultimately, the git history is a better reflection of authorship information than years.

Just my two cents, again, I’m not your lawyer, but happy to chat through any questions.

maflcko renamed this:
~~doc: Remove copyright years~~
doc: Remove copyright years (headers only)
on Jan 13, 2023

fanquake commented at 11:01 am on January 13, 2023: member

Concept ACK

real-or-random commented at 1:16 pm on January 13, 2023: contributor

Just my two cents, again, I’m not your lawyer, but happy to chat through any questions.

Thanks for your help!

Here’s a question: What would be your response to the doubts I’ve raised above (namely, that modifications to copyright notices are restricted in many jurisdictions)?

hebasto commented at 1:43 pm on January 13, 2023: member

Concept ACK.

sipa commented at 4:13 pm on January 13, 2023: member

What about not removing the existing years in notices, but adding “, and later (see source control)”? On the off-chance that there is some legal concern somewhere about changing existing notices, this avoids the problem, while also avoiding the project maintenance burden of updating them (as well as being more explicit about where years, if at all relevant, can be found).

maflcko commented at 4:21 pm on January 13, 2023: member

not removing the existing years in notices, but adding …

Might be too verbose, so maybe just replace the end of the range with “-present”. However, this still leaves the problem that the beginning of the range might be wrong, etc.

I am thinking that either:

This change is fine as-is
This change is not fine as-is, because it may “modify” a notice in a strict sense. However, then all other modifications (code movements, year bumps, etc) may also not be fine. So doing this change as-is isn’t making anything worse.

sipa commented at 4:26 pm on January 13, 2023: member

@MarcoFalke Yeah, perhaps, IANAL. I’d like to see @real-or-random’s comments addressed a bit more thoroughly before proceeding with anything really.

sillsm commented at 4:45 pm on January 13, 2023: none

Hi @real-or-random it’s a good point. It’s prohibited to tamper with copyright management information (CMI) in many jurisdictions, including the U.S. However, that applies to recipients of a copyrighted work that don’t otherwise have rights to it. You all do have the rights to modify contributions how you see fit, as the project maintainers, through the MIT license.

Consider the problem from the beginning. Why doesn’t your local copyright law prevent you from refactoring a file contributed by another? Surely it can’t be permissible to completely modify or change beyond recognizability another’s work of authorship, but the law is in place to prevent you from modifying a year? What if the year was entered as a string in the middle of a function? Does it become illegal to refactor the function?

The resolution to this apparent problem is that the project maintainers receive contributions to the project under the MIT license. This acts as an implicit CLA under an inbound=outbound theory. Maintainers have the right to copy, modify, or distribute contributions, and modifications include removing years, or saying xxxx-present. Both of which are completely acceptable, and neither of which are compelled by law. And to reiterate, the original state of the files are preserved in the git history in any case. This should take care of concerns raised by “The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.” because in effect, they are, through the git history.

In summary, the Bitcoin project is licensed under an MIT license. And years do not have a specially protected status separate from the rest of contributions under any jurisdiction’s copyright law. You may modify them as you wish in the best interests of the project, including removing them.

achow101 commented at 4:51 pm on January 13, 2023: member

Concept ACK

maflcko commented at 4:56 pm on January 13, 2023: member

meta note: Please don’t merge this yet. I’ll rebase on the current master branch next week to account for any new files added in the meantime.

maflcko added the label Needs rebase on Jan 13, 2023

DrahtBot removed the label Needs rebase on Jan 13, 2023

maflcko force-pushed on Jan 23, 2023

fanquake approved

fanquake commented at 5:51 pm on January 23, 2023: member

ACK fa626c1c627aca985df619594675dc8f8406745a

real-or-random commented at 6:45 pm on January 23, 2023: contributor

In summary, the Bitcoin project is licensed under an MIT license. And years do not have a specially protected status separate from the rest of contributions under any jurisdiction’s copyright law. You may modify them as you wish in the best interests of the project, including removing them.

Thanks, I can follow that argument.

In the end, I still think that the maintainers should weigh the benefits against the drawbacks here. Removing the years may very well be fine, but it still comes with some non-zero risk (due to all the jurisdiction involved etc., and due to the fact that you can never be absolutely sure etc.) But on the other hand, the years are obviously annoying (the opening post makes that pretty clear). So there’s no “100% certain legal” as there’s no “0% overhead” for maintenance.

So this how I view things:

Current state (with years): No additional legal risks (in addition to what the maintainers already do) and years are annoying for devs
Adding “-present” (or not ever touching copyright notices again): Little additional legal risk and very little annoyance
Removing years (this PR): Some additional (probably small) legal risks and minimal annoyance

I tend to think that the optimal trade-off here is probably option 2 but not 3.

I think that project is a bit special, in particular because there have been legal threats / action against people in the past. If you ask me, I’d personally rather err on the side of “legal safety” and accept a bit of overhead for devs. (Keep in mind that legal action against devs will create a huge overhead for them!)

For example, bumping the copyright might equally be questionable. I see that you suggest to never update the notices. Though, that will be impossible to implement in practice when code is moved from one file to another and the notice in the two files is not char-by-char-equal.

If the solution is adding “-present”, I think one could just take the largest range (e.g., you move code from file A with “2018-present” into file B with “2020-present”, change B into “2018-present”. But yeah, I guess there’s no perfect solution here…

sipa commented at 7:57 pm on January 23, 2023: member

I agree with @real-or-random here; it really feels that just adding “-present” and then not updating further gets us 95% of the benefit, with only a fraction of the risks involved.

sipa commented at 10:13 pm on January 23, 2023: member

@sillsm Thank you for the comments. I’m however not convinced about one thing you bring up:

This should take care of concerns raised by “The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.” because in effect, they are, through the git history.

Not all copies of the software include git history (e.g. source tarballs don’t). Could that form an issue?

maflcko commented at 10:15 am on January 24, 2023: member

I am happy to change it to “-present”, or pick any of the other alternatives, even closing this pull and continue with the current thing (run a scripted diff to bump). The maintenance overhead of any alternative (at least the ones mentioned in #26817 (comment)) for the next few decades is likely less than the time spent discussing here. That overhead shouldn’t play a role when trying to answer the legal question. Though, closing this pull (or picking an alternative) should be done on a legal basis, otherwise we’ll be stuck with the legal ambiguities and risks, if there are any. I understand that it will not be possible to get a 100% definitive legal answer for each jurisdiction. However, picking one alternative over another without even a hint that it would be legally safer in any jurisdiction doesn’t seem ideal either. Moreover, if one alternative over another is picked theoretically on a legal basis, it should be considered whether that legal reasoning will apply in practise.

e.g., you move code from file A with “2018-present” into file B with “2020-present”, change B into “2018-present”

I think it is safe to say that this rarely or never happened in the past and likely won’t happen unless this is enforced with a bot. (For context: Search the history for the stuff mentioned in #26817 (comment). Moreover, since opening this pull request there haven been several files added to the master branch and still open pull requests that don’t include a header notice at all. So it is pretty clear that we don’t have any reviewer looking out for copyright stuff.) Generally, I think that any alternative that involves changing or requires to “not” change the years in the header, based on a presumed legal rationale, is likely going to expose future contributors to legal risks on that rationale. So when picking one alternative over another legally, we should also make sure that the overall legal risks (current+future) are minimized.

If people prefer the “-present”, my suggestion would be to make it “2009-present” for all files. This will mean that both ends of the range are wrong, unless a file’s content has been touched both in 2009 and the present year, but from a maintenance perspective it is no worse than no range.

My summary: (1) From what I read, there doesn’t seem to be a legal basis to prefer one alternative over another (lmk if I missed it) (2) Thus, my preference would be to do something that is “static” (remove the years or do 2009-present) (3) If there is legal basis to do something else, it should ideally come with applicable rules to implement and refer to in the future, and/or elaborate the legal risks of failing to apply the rules.

maflcko added the label Brainstorming on Jan 24, 2023

maflcko removed the label Brainstorming on Jan 27, 2023

maflcko added the label Needs rebase on Jan 27, 2023

DrahtBot removed the label Needs rebase on Jan 27, 2023

DrahtBot added the label Needs rebase on Jan 27, 2023

maflcko force-pushed on Jan 30, 2023

maflcko commented at 9:59 am on January 30, 2023: member

Rebased to account for a removed file in the master branch.

For reference, I also added a commit in the previous force push to replace the http URL with an https URL.

DrahtBot removed the label Needs rebase on Jan 30, 2023

maflcko force-pushed on Feb 1, 2023

pinheadmz commented at 4:24 pm on February 1, 2023: member

concept ACK verified scripted-diff @MarcoFalke once this change is merged, is there any need to keep copyright_header.py at all any more?

bitcoin deleted a comment on Feb 2, 2023

maflcko commented at 8:19 am on February 2, 2023: member

once this change is merged, is there any need to keep copyright_header.py at all any more?

No idea. It has an “insert” command, which may still be useful if someone wants it?

maflcko force-pushed on Feb 2, 2023

hebasto commented at 11:20 am on February 5, 2023: member

FWIW, here are some more sources:

If understand correctly, the copyright comments should look like this:

0// SPDX-FileCopyrightText: © 2009 The Bitcoin Core developers
1// SPDX-License-Identifier: MIT

ghost commented at 4:53 pm on February 5, 2023: none

My comment was deleted for some reasons. This PR can still be me merged.

maflcko commented at 11:26 am on February 6, 2023: member

FWIW, here are some more sources: If understand correctly, the copyright comments should look like this:

While your source claims to be a lawyer, they share their personal preference/opinion (on the years issue at least), or did I simply miss the legal references? Also, it doesn’t really answer the question what to do when moving code. Bitcoin Core may be unique in that most of the code was released in a very few files (main.cpp, etc) initially and then split out into smaller files. Some of those new files do not have the “right” year taken over. For example, picking a file that likely isn’t copyrightable anyway, to avoid blame: https://github.com/bitcoin/bitcoin/blob/aff75463e2c75a7a969cdaa535c7be05fd146420/src/kernel/cs_main.cpp#L1

In theory, 2009 would be more accurate in this case. However, I wonder how we’d want to review every code change to pick the earliest year.

maflcko force-pushed on Feb 6, 2023

hernanmarino commented at 7:44 pm on February 10, 2023: contributor

Concept ACK

hernanmarino approved

bitcoin deleted a comment on Feb 12, 2023

contrib: Remove year_range_to_str

This is needed for the next commit.

In a follow-up commit, the "update" command can be removed.

fa5d6f8be5

contrib: Resolve URL redirect

While touching the headers, the URL redirect can be flattened.

Both URLs point to the same content, but the http-one redirects to the
https-one.

fa0f837274

scripted-diff: Bump copyright years to present

-BEGIN VERIFY SCRIPT-
 ./contrib/devtools/copyright_header.py update ./
-END VERIFY SCRIPT-

fab01bff09

maflcko renamed this:
~~doc: Remove copyright years (headers only)~~
doc: Bump copyright years to present (headers only)
on Feb 16, 2023

maflcko force-pushed on Feb 16, 2023

maflcko commented at 8:38 pm on February 16, 2023: member

Adjusted title, description and commits according to IRC discussion and comment #26817 (comment)

DrahtBot added the label Needs rebase on Feb 17, 2023

DrahtBot commented at 11:33 pm on February 17, 2023: contributor

🐙 This pull request conflicts with the target branch and needs rebase.

maflcko commented at 3:22 pm on February 20, 2023: member

Closing as up for grabs. Should be easy to rebase, if someone wants to, given that most is a scripted diff

maflcko closed this on Feb 20, 2023

maflcko deleted the branch on Feb 20, 2023

paplorinc commented at 8:56 am on February 19, 2024: none

I’ve opened a similar issue proposing to remove all of these inconsistent and hard to maintain headers and replace them with simple SPDX-License-Identifier https://github.com/bitcoin/bitcoin/issues/29445

doc: Bump copyright years to present (headers only) #26817

Reviews

Conflicts