This has been discussed in #1819#pullrequestreview-2770098094/
See individual commit messages for further rationale. I can squash the commits if this will be cleaner.
This doesn’t touch all the “License” and “License-Code” headers yet. Let’s first agree on the changes, and then we can implement them.
After staring at this section and some BIP preambles for a while, a further suggestion is to drop “License-Code” entirely. It’s used only by five BIPs so far (BIP 98, BIP 116, BIP 117, BIP 330, BIP 340), and I think it creates more ambiguity than it tries to resolve:
For BIP98, BIP116, and BIP 117 (some comments below apply to all of them but I list them only once):
BIP330:
BIP340:
I feel that this just relying on this text in BIP3 would be a sufficient solution (here in the version after this PR but the one before was also good):
Each auxiliary source code file or source directory should specify the license under which it is made available as is common in software (e.g., with a
SPDX-License-Identifier: <SPDX License Expression>comment, a license header, or a LICENSE/COPYING file). It is recommended to make any test vectors available under CC0-1.0 or FSFAP in addition to any other licenses to allow anyone to copy test vectors into their implementations without introducing license hindrances. Licenses listed in the License-Code header apply to all source directories, source code files, and test vectors provided with the BIP except those where a LICENSE file in a directory or the file header states otherwise.
If we stick to something like this, then licensing will be less ambiguous, and we should just drop License-Code.
It could still be rephrased a bit to say “each auxiliary code file or directory made available under different terms than what is specified in the License header” to clarify that the License header is meant to apply to all kinds of aux files, unless specified otherwise. And we’ll need a note that old BIPs may have a License-Code header and simply refer to BIP2.
You could say that should belong to a larger overhaul of the legal stuff in BIP3 (see https://github.com/murchandamus/bips/pull/2#discussion_r1778882507 and https://github.com/murchandamus/bips/pull/2#issuecomment-2388682834), but I don’t think that’s the case. Dropping the header (only for new BIPs, of course) is purely an “editorial” thing and doesn’t go into the actual legal issues, so I’d say it belongs to BIP3.
You could also say that I’m quite late with this comment, and I can’t really argue against that…
409-*either* license. In other words, the license list is an "OR choice", not an "AND also" requirement.
410+In this case, the BIP (including all auxiliary files) is made available under the terms of both Creative Commons CC0 1.0
411+Universal as well as the MIT License, and anyone may modify and redistribute it provided they comply with the terms of
412+*either* license, at their option. In other words, the license list is an "OR choice", not an "AND also" requirement.
413+See the [SPDX documentation](https://spdx.dev/ids/) and the [SPDX License List](https://spdx.org/licenses/) for further
414+details.
I wholly support all of the improvements of the content, but if you end up touching this again, it would be preferable if diffs were minimized by leaving line-breaks in the same places even when lines are shortened or lengthened by edits affecting a single line as that makes it easier for reviewers to identify what exactly is changing.
0In this case, the BIP (including all auxiliary files) is made available under the terms of both Creative Commons CC0 1.0 Universal as well as the
1MIT License, and anyone may modify and redistribute it provided they comply with the terms of
2*either* license, at their option. In other words, the license list is an "OR choice", not an "AND also" requirement.
3See the [SPDX documentation](https://spdx.dev/ids/) and the [SPDX License List](https://spdx.org/licenses/) for further
4details.
429+common in software (e.g., with a [`SPDX-License-Identifier: <SPDX License Expression>` comment](https://spdx.dev/ids/),
430+a license header, or a LICENSE/COPYING file). It is recommended to make any test vectors available under CC0-1.0 or
431+FSFAP in addition to any other licenses to allow anyone to copy test vectors into their implementations without
432+introducing license hindrances. Licenses listed in the License-Code header apply to all source directories, source code
433+files, and test vectors provided with the BIP except those where a LICENSE file in a directory or the file header states
434+otherwise.
Good changes, but in the future, please don’t reformat text passages to adhere to a specific line length. Instead leave the line breaks in the same places (especially the line breaks of otherwise unchanged lines). Due to the shifted line breaks, this edit that adds and changes only a few words (+auxiliary, +SPDX-License-Identifier: <SPDX License Expression> comment, GNU-All-Permissive ↦ FSFAP) appears in the diff viewer as if the whole paragraph had been rewritten.
0Each auxiliary source code file or source directory should specify the license under which it is made available as is common in
1software (e.g., with a [`SPDX-License-Identifier: <SPDX License Expression>` comment](https://spdx.dev/ids/), a license header, or a LICENSE/COPYING file). It is recommended to make any test vectors available
2under CC0-1.0 or FSFAP in addition to any other licenses to allow anyone to copy test vectors into their
3implementations without introducing license hindrances. Licenses listed in the License-Code header apply to all source
4directories, source code files, and test vectors provided with the BIP except those where a LICENSE file in a directory
5or the file header states otherwise.
450-It is recommended that BIPs that include literal code be licensed under the same license terms as the project it
451-modifies. For example, literal code intended for Bitcoin Core would ideally be licensed (or dual-licensed) under the MIT
452-license terms.
453+It is recommended that source code included in a BIP (whether within the text or in auxiliary files) be licensed under
454+the same license terms as the project it is proposed to modify, if any. For example, changes intended for Bitcoin Core
455+would ideally be licensed (also) under the MIT License.
Nit, should you end up editing further:
0It is recommended that source code included in a BIP (whether within the text or in auxiliary files) be licensed under the same license terms as the project it
1is proposed to modify, if any. For example, changes intended for Bitcoin Core would ideally be licensed (also) under the MIT
2License.
Thanks for taking the time to put together this proposal to improve BIP 3. I heartily agree with all your suggestions including that we should drop the License-Code header for future BIPs. Thank you for taking the time to write the detailed motivations in the commit messages. I went through all the proposed changes commit by commit and support the content of all of the edits. If you touch it again, I’d request that the changes be amended to drop the reformatting of line lengths to minimize the diffs.
If you would like to add also text to drop the License-Code header I’d also support that, otherwise, I can add that as a follow-up to this PR.
SPDX doesn't have an official identifier for "public domain", at least
not for the simple "This document is placed into the public domain"
declarations used in some BIPs, see
https://wiki.spdx.org/view/Legal_Team/Decisions/Dealing_with_Public_Domain_within_SPDX_Files
for the rationale provided by their legal team. The rationale is sound,
but It's possible to create "user-defined" identifiers of the form
LicenseRef-X. This is a good idea here to make sure that all SPDX
expression will be formally valid.
And in our case, all "PD" BIPs match the following pseudo regex, so
there's not much potential for confusion:
"This (document|BIP|work|proposal) is (hereby)? (placed)? in the
public domain."
So it makes sense to keep using a single identifier for all of these.
That's a bit of legal nitpicking, sorry. CC0 contains something like a
public domain dedication along with a fallback license, so it's neither
entirely. Some call it a "legal instrument". I prefer not calling it
anything.
I think that requirement is not helpful. I don't think hat including
additional licenses will be overwhelming to the reader. If anything, it
will obfuscates the actual licensing conditions. (Anyway, this should be
super rare.)
The actual reason why I suggest this is that I think that's a great
default choice for a new BIP, so it's a perfect example. CC0-1.0 is a
great liberal choice for the BIP document (and test vectors etc.), and
MIT is the common choice for code in our ecosystem. Putting both BIP and
code under the "OR" avoids any confusion about which part is licensed
under which terms and also avoids any hassle when reorganizing, e.g.,
when moving code out of the BIP Markdown file to a separate file etc.
But I don't want this PR to recommend a license, so let me sell this
change as an editorial change to an example, which is warranted because
the MIT is much more known than FSFAP, in particular in this ecosystem.
Sorry for the changing line breaks! I don’t like this either, but the line breaks were so consistent that I assumed you wanted me to reformat… I changed it back (first force-push to https://github.com/bitcoin/bips/commit/a50e1ca7e1633b4383839af7d2159d1bee22bc80) and also added a change to the “Header Descriptions” section, which I had overlooked (second force-push to https://github.com/bitcoin/bips/commit/88d29188c62dfafc94ac92b5f59d310a20bcef3d).
As a side note, what I highly recommend for new texts and BIPs is Semantic Line Breaks (also called Semantic Linefeeds or Ventilated Prose), i.e., having a line break after each substantial unit of thought. This makes it so much easier to reorganize thoughts during editing, and it also keeps the diffs clean. A similar, but slightly worse (if you ask me) advice is having full sentence per line, see also here.
If you would like to add also text to drop the License-Code header I’d also support that, otherwise, I can add that as a follow-up to this PR.
I’m happy to take care of it next week. I suggest a follow-up PR because this PR is ready from my side now. But I can also add commits here if you prefer that. Just let me know.
478 #### Not Acceptable Licenses
479
480 All licenses not explicitly included in the above lists are not acceptable terms for a Bitcoin Improvement Proposal.
481-However, BIPs predating this proposal were allowed under other terms, and should use these abbreviations
482-when no other license is granted:
483+However, BIPs predating this proposal were accepted under other terms, and should use one the following identifiers.
In commit 0cc4d26e675392b49b32, missing word
0However, BIPs predating this proposal were accepted under other terms, and should use one of the following identifiers.