Add Satoshi Nakamoto's white paper to doc directory #7443

pull aantonop wants to merge 1 commits into bitcoin:master from aantonop:master changing 1 files +0 −0
  1. aantonop commented at 5:11 PM on January 29, 2016: none

    Satoshi's white paper is currently available on bitcoin.org, but without any clear licensing information, which makes it difficult for publishers to re-publish.

    Some research shows however that the white paper is licensed under MIT. Satoshi posted the paper in the original repository on SourceForge, as part of bitcoin-0.15. That release had an MIT license attached which covers "associated documentation files". This clearly establishes an MIT license for the white paper. See https://web.archive.org/web/20091127010808/http://sourceforge.net/projects/bitcoin/files/

    I request that we add the white paper back into the bitcoin repository, under the same MIT license that Satoshi had chosen. This will clarify licensing for anyone wanting to include the white paper in any publication and help spread the white paper more broadly. The white paper belongs in this repository, just as Satoshi intended. It is the clearest documentation of the philosophy and origins of this project and it should be part of "doc".

    The paper is 184 KB, adding only 0.2% to the repository size.

  2. Add Satoshi Nakamoto's white paper to doc directory 58a52099e5
  3. laanwj added the label Docs and Output on Jan 29, 2016
  4. jonasschnelli commented at 5:41 PM on January 29, 2016: contributor

    ACK. We have signaled that Core is independent from bitcoin.org and keeping Satoshis white paper in Cores repo is the logical next step.

  5. kanzure commented at 5:44 PM on January 29, 2016: contributor

    Well, the reason why the paper was not already in the repository wasn't because of a lack of clarification about its licensing. Clarifying the licensing status of the paper does not merit inclusion of the PDF file into this particular version control repository.

    The whitepaper you seek to include is already included on bitcoin.org at https://bitcoin.org/bitcoin.pdf, which seems reasonable considering the website charges itself with extended documentation and historical items. I am not presently convinced that duplication is warranted. License clarification can trivially occur through bitcoin.org, too, which I recommend you go ask them to do regardless of whether your branch is merged.

    PDF files are build artifacts, not source code. Ideally we should avoid committing build artifacts into the repository. Changes to PDF files are difficult to diff, and somewhat meaningless (have you ever hacked around in the PDF file format? I have, sadly....). And even if we did have some expectation of future updates, PDF diffs aren't well tracked by git and its diff tools.

    Another issue that I would be concerned about is why only one paper and not others? Which papers are going to merit inclusion into the source code repository? It's already an inefficient use of git to include PDF files, so "it's inefficient" cannot be used when others request other PDFs to be added after this one. So for this reason if anyone does merge this pull request's branch, then I recommend making it policy to not evaluate papers for inclusion into the repository in the future-- it's the wrong task for a source code repository anyway.

    We have an increasingly well-maintained source code repository here, focused on delivering source code to developers for developing, building and maintaining Bitcoin Core. ((I notice that a link to the paper is not provided in doc/README.md so that seems like a good alternative to this pull request.))

    Btw, if for whatever reason we were to include the file in the repository, then I would insist on changing the values of GIT_AUTHOR_NAME and GIT_AUTHOR_EMAIL.

    Also, if anyone has the version of bitcoin.pdf from before 427c63b364c6db914cf23072a09ffd53ee078397b7c6ab2d604e12865a982faa it would be interesting to make that public, thanks whoever you aren't.

    I don't think it's entirely necessary to include this in the Bitcoin Core repository, but it's not particularly harmful as long as we commit to not becoming a repository of academic Bitcoin PDFs.....

    I don't really buy the argument that "bitcoin.org is independent and therefore the paper should be included"; their independence should be irrelevant in this decision, because if they were deleting their copy of the file, then Bitcoin Core could host the PDF on its website instead.

    Allllsooo..... I don't mean to nitpick, but "add the white paper back into the bitcoin repository"-- your link is not to the subversion repository.

  6. paveljanik commented at 7:39 PM on January 29, 2016: contributor

    Was the paper really part of the repository? I see it in the project files, but nowhere in the source code repository.

    Please file an issue to Bitcoin Core web to not link to bitcoin.org for the bitcoin.pdf file and link to its local copy instead.

    NACK

  7. laanwj commented at 8:57 AM on January 30, 2016: member

    I'd say the paper is easy enough to find for those that want to find it (there's even translations in various languages).

    The documentation in doc/ is meant to be documentation of the software (about using, writing, and buildilng it) not so much the bitcoin system in general. There's better sources for that.

    So light NACK from me, this is too meta, we don't include a copy of the bips repository in the source repository either.

    A repository with academic papers could be useful, but it doesn't need to be in the source tree.

    Edit: I do agree with @aantonop that the paper is important and we could at least link to it somewhere, say, in the general section in README.md. Searching the repository, I can't find any reference to it.

  8. btcdrak commented at 4:12 PM on January 30, 2016: contributor

    @aantonop The paper is published in dozens of places already do a google search with quotes "A purely peer-to-peer version of electronic cash would allow online"

    a few examples

    The only person who could make a copyright or licensing claim is the author himself. It's fairly reasonable to assume that's unlikely.

  9. btcdrak commented at 4:32 PM on January 30, 2016: contributor

    @aantonop It is not possible for anyone to license the document, except for the copyright owners themselves. Adding the file to the bitcoin repo will not make it MIT licensed. That said, I think it's fairly reasonable to assume fair use.

    In any case, I have added a mirror to https://bitcoincore.org/bitcoin.pdf since it makes sense to have the white paper available from as many places as possible.

  10. aantonop commented at 4:36 PM on January 30, 2016: none

    Whether the author is likely to make a copyright claim or not doesn't enter into the consideration of publishers, or authors under contract with publishers. All content has to have clear licensing and provenance or it won't be published. No publisher will take the risk, no matter how remote and no author will violate their contract that requires them to source licenses for anything included in their work. I wish copyright didn't work that way, but that's how it works.

    The lack of clear licensing (not everyone will do the wayback research) is an impediment to publication, especially print publication. I have overcome this impediment with research, but many others will simply decide not to re-publish the paper. I will re-publish it in my book, but I want to make it easier for other authors to include it in other books, hence this PR.

    I could go and ask other places to make the licensing clear, but I think this repository might be the best place to include it under MIT, as the authoritative source. Satoshi chose to include the PDF in the original project. I am not proposing this as a rule for any other papers, other PDFs or other documentation. It's a one-time only request, based on the special nature of this paper. If there is one document that best describes bitcoin, this is it and it is worth an exception to the valid concerns expressed above.

    Thank you for your consideration

  11. aantonop commented at 4:39 PM on January 30, 2016: none

    @btcdrak The author already licensed it under MIT, by including it in an MIT licensed project, as shown by the wayback machine link in the PR. Adding it to this repository will simply re-establish that license in an obvious way for others to find.

  12. aantonop commented at 4:49 PM on January 30, 2016: none

    @btcdrak

    That said, I think it's fairly reasonable to assume fair use.

    Fair use is an affirmative defense, not a license. Very few publishers will re-publish in whole something that has no clear license, hoping that a fair-use defense will apply.

    Perhaps I am not making myself clear. The issue is not the availability of the paper. The issue is the licensing of the paper, which is not clear in any of the places it is stored or on the paper itself. Short of modifying the paper to include the MIT license (perhaps as an appended page), the alternative is to include it in a repository that has the MIT license the author applied before. What I'm trying to achieve is to make it easy for publishers to find the license that this falls under, not the paper.

    Again, thank you for your comments.

  13. btcdrak commented at 5:05 PM on January 30, 2016: contributor

    @aantonop I appreciate your situation but we are also not here to satisfy your publishers legal demands :-P If MIT licensing is already established by the wayback machine archives, then surely the problem is already solved regardless of the hosted location. The difficulty in my mind with the web archive is it doesnt actually have a copy of the bitcoin.pdf, so while we can make assumptions, I think we cant say conclusively. It's therefore tricky to make the claim. IANAL. Arent there any other source repository copies of the original repo?

    [I also believe (according to legal advice I have received in the past) that documentation that does not form part of the software (as per the license wording) is not licensed by MIT (which is why special documentation licenses exist), but that's really out of scope for this PR discussion].

    While I am not opposed to the PR, I'm very wary of what you are trying to establish using the Bitcoin Core source repository.

    However, if you believe that the document is MIT and that the source repository license is good enough, then the bitcoin.org source repository already establishes MIT license https://github.com/bitcoin-dot-org/bitcoin.org/blob/master/COPYING and the PDF is located at https://github.com/bitcoin-dot-org/bitcoin.org/blob/master/bitcoin.pdf

  14. aantonop commented at 5:22 PM on January 30, 2016: none

    @btcdrak It's not about me or my publisher. I've already solved my problem. I was trying to make it easier for other authors.

    I see that this request does not have support...

  15. aantonop closed this on Jan 30, 2016

  16. btcdrak commented at 5:25 PM on January 30, 2016: contributor

    @btcdrak It's not about me or my publisher. I've already solved my problem. I was trying to make it easier for other authors.

    As i said, the license is already established according to your conditions in the bitcoin.org repository with license here https://github.com/bitcoin-dot-org/bitcoin.org/blob/master/COPYING and the PDF is located at https://github.com/bitcoin-dot-org/bitcoin.org/blob/master/bitcoin.pdf

  17. Alex-Linhares commented at 12:19 AM on February 1, 2016: none

    ACK

  18. dcousens commented at 12:22 AM on February 1, 2016: contributor

    Perhaps another repository under this organization?

  19. LivInTheLookingGlass commented at 2:40 AM on February 1, 2016: none

    Is there any reason to not include this? Looking at the comments, it seems clear the only objection (licensing) has been shot down. So why is this closed?

    If nothing else, it seems to me that we should have the paper of intent included with the project.

  20. gladoscc commented at 9:00 AM on February 1, 2016: contributor

    @gappleto97 Quite simply because docs is for developer documentation and the whitepaper doesn't really fit there. It's like putting fruity yogurt in a fruit basket.

  21. acidsploit commented at 10:15 AM on February 1, 2016: none

    ACK @gladoscc What!? What kind of nonsense is this?

  22. chuckwilliams37 commented at 1:50 PM on February 1, 2016: none

    I would include an authoritative design document in my repository - if it existed - no matter it's format, or licensing, or build/prod status. But that's just me - a patent inventor and developer.

  23. laanwj commented at 2:17 PM on February 1, 2016: member

    A link to the whitepaper was added instead: #7451

  24. BruceFenton commented at 6:29 PM on February 1, 2016: none

    ACK

    Advantage of increased views of the paper. Drawback of licensing issue seems very unlikely as the paper seems to be at the least under MIT license - more likely is that it would be considered public domain. If an author does not proactively defend a work or indicate that they consider it IP then courts very often will consider it to be public domain.

  25. LivInTheLookingGlass commented at 9:07 PM on February 1, 2016: none

    @gladoscc If we're aiming to be the reference implementation of a system, we ought to include some documentation on the system itself. This is a good start for that.

  26. seandotau commented at 9:57 PM on February 1, 2016: none

    Agree that /doc is for developer documentation and that it doesn't really fit there. However, because it is "the" paper that everyone seems to refer to, it doesn't hurt to include it. ACK if I had to choose.

  27. MarcoFalke locked this on Sep 8, 2021

github-metadata-mirror

This is a metadata mirror of the GitHub repository bitcoin/bitcoin. This site is not affiliated with GitHub. Content is generated from a GitHub metadata backup.
generated: 2026-04-19 21:15 UTC

This site is hosted by @0xB10C
More mirrored repositories can be found on mirror.b10c.me