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

Reviews

See the guideline for information on the review process.

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.

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.

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

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

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.

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.

Concept ACK

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

Concept ACK.

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

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.

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

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.

Concept ACK

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.

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.

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

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?

FWIW, here are some more sources:

• How and why to properly write copyright statements in your code
• Berne Convention

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

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

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

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:

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.

Concept ACK

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

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

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

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 #29445