Say It Ain’t So, Satoshi: What Rights Would The Elusive Bitcoin Developer Have in His Creation?

By Lance Koonce

So, today there area again headline stories that Bitcoin creator Satoshi Nakamoto has been revealed — this time, it is Australian professor Craig Wright. At the moment, I’ve just finished watching a session at Consensus 2016 during which Gavin Andresen gave an apparently heartfelt description of why he believes Wright is Satoshi, including watching Wright enter, on a clean computer, a key Andresen says only Satoshi could possess. After which Vitalik Buterin of Ethereum challenged this conclusion based on signaling theory (noisy signals are less likely to be honest).

We’ll need to see how this new “Breaking News” shakes out. (Although, as a complete aside, I still can’t see or write the term “breaking news” without thinking of The Daily Show’s old tagline: When News Breaks, We Fix It. Which somehow may be appropriate here, given the tortured history of this particular news story.)

I was asked several years ago what would happen if the real Satoshi showed up — would he be able to make any claims on the Bitcoin protocol, as a matter of intellectual property law? While many in the Bitcoin community might think even broaching the topic is anathema, I think it’s worth discussing as a thought experiment, especially now that the original blockchain open-source framework is proliferating in so many ways.

I you want to leap right to the punchline, then the answer is no, I don’t believe Satoshi — whether it’s Craig Wright or someone else — can claim a proprietary interest in the underlying code. Those who are steeped in open-source software development may see this as a given. But it’s actually quite an interesting ride to get to that conclusion, so if you’re interested, read on.

Be forewarned that it’s a bit of a long read, and it pretty off-topic from our normal discussions on this site about blockchain technology.

The Bitcoin Protocol is Code, And Code is Subject to Copyright Protection

The U.S. Copyright Act protects computer software as a “literary work.” The Courts have not had much difficulty determining that both source and object code is protected, meaning that no one may copy or distribute or create a derivative work from such code, without permission.

This does not mean that the underlying algorithms, ideas or processes are protected — rather, copyright protects only the expression of those underlying concepts and functionality. This makes sense: There are likely thousands of creative ways to design software that could answer the question of how to, say, calculate a 30-year fixed mortgage, but the basic mathematical calculations are not subject to such variability. Or, at any rate, we treat the math as “facts” — something discoverable about the real world, as opposed to something invented by the human mind. Those facts cannot be protected, but rather only the particular lines of code used to generate the answer. In other words, you cannot use copyright to usurp from the rest of the world the concept of a mortgage calculator, or the math that undergirds it. Nor can you copyright functional aspects of a work — that is the province of patent law.

Of course, identifying the line where concepts end and “expression” begins can be tricky. Esteemed Judge Learned Hand famously (well, “famously” among IP lawyers) discussed the “levels of abstraction” that could be used to discuss creative works: For instance, the idea of sentient robots that transform into vehicles is not protectable. Nor is the more developed concept of having those sentient transforming robots engage in a war with other sentient transforming robots over the fate of planet Earth. But once you tie together enough plot points (and explosions and battle scenes) into a script for a Michael Bay film, that plot sequence is likely creative enough for protection (no matter how tedious; and for the record, Judge Hand did not use Transformers as an example).

Drawing the line between ideas/functionality and expression is even more complicated when it comes to the “structure” of software. At what level does the structure, sequence and organization of software become merely functional (and thus unprotectable) versus expressive (and thus copyrightable)? Some courts have held that software structure at a higher level of “abstraction” than literal code can be protected; other courts have held that this would provide protection to mere functionality. In a key case between Oracle and Google involving the Java and Android operating systems, the United States Court of Appeals for the Federal Circuit held that APIs (application programming interfaces) are protectable.

When Nakamoto created the core code for Bitcoin, a copyright interest in that code almost certainly arose under US law. There was no need for him to register his software with the Copyright Office or follow any other formalities — the right simply springs into being at the moment of creation. The only requirement is that the software possess some minimal level of creativity.

Nakamoto’s copyright interest would have covered the literal code itself, certainly. It may also have covered structural elements in the software, although this is the issue mentioned above that is somewhat unsettled in the courts. Had Nakamoto wanted to exploit his code by selling or licensing it at that time, he could have done so.

Finally, although this post is focused on copyright issues, it should be noted that software may also be protected in some instances under patent law. While in some cases open source licenses reference patents, or arguably imply a patent license to the extent necessary to effect the terms of the license, typically open-source licenses are seen as addressing only copyright.

But He Gave It All Away

All available evidence suggests that Nakamoto intended, instead, that his Bitcoin core code should be used freely by anyone, without restriction. To this end, the very first “commit” (posting) of the core code, on SourceForge.com, was accompanied by an “MIT License”, that read as follows:

Copyright (c) 2009 Satoshi Nakamoto

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.

Note first that the first line of the “commit” indicates that Nakomoto claims copyright in his software, a necessary prerequisite to giving it away. He then agrees to license the code to anyone who wants to use it, subject to a single restriction discussed below.

The MIT License is a form of open-source license, meaning that software published under the license can be freely used by others for most purposes. The Open Source Initiative maintains the “Open Source Definition”, which constitutes the most widely accepted description of open-source software. The virtually nonexistent restrictions on use has spurred the development of robust commercial ecosystems around such software — think of the many applications built around Linux, Java and Android (and now Bitcoin). As one federal court has said, “[o]pen source licensing has become a widely used method of creative collaboration that serves to advance the arts and sciences in a manner and at a pace that few could have imagined just a few decades ago.” Jacobsen v. Katzer, 535 F. 3d 1373, 1378 (Fed. Cir. 2008).

Nakomoto’s MIT License contains virtually no restrictions, other than a requirement (built into the generic MIT License adopted by Nakamoto) that anyone who uses the code must ensure that the license terms accompany any subsequent use of the original code. This ensures that future users are aware that they are free to use the portions of code authored by Nakamoto.

Significantly, under the Nakamoto license, anyone can create new, commercial software derived from Nakamoto’s code, and can even claim an ownership interest in their portions of the new software that have been created.

Downstream users cannot, however, claim a copyright interest in the original code provided by Nakamoto. They are free to use and distribute (including by sale or license) their derivative software containing portions of the original Bitcoin code, as long as they include the MIT License language. If a downstream user fails to include the MIT License language with the portions of the code taken from Nakamoto, this would be a violation of the original license, and the usage would be subject to an argument that the license was void because of the failure to abide by the license’s terms. Nakamoto then could conceivably sue to stop the use of his code in the new software. The key point to remember is that the original author of the code retains a copyright interest in his work, even after granting an open-source license.

Some open-source licenses, of the “copyleft” variety, actually exploit this continuing copyright ownership to ensure the possibility of a robust open-source ecosystem (often described as a “hack” of copyright, because it uses a protectionist tool to foster free distribution). Such licenses require that any new, derivative code incorporating the original open-source code also be subject to a free, open-source license — that is, you can build on top of the original code, and use the code for commercial purposes, but you must contribute all of your new code to the open-source world as well. Companies who have taken open-source software under such a license, then incorporated it into commercial software without making the new software available under a free license, have been sued for violating the terms of the license.

So What Does This Mean?

An illustration might be helpful, so let’s use the mortgage calculator example. Learned, Inc. creates a very elegant program that calculates mortgage interest, and releases it under an MIT License. Optimus LLC is building out a mobile real estate app that allows real-time views of properties for sale, using aerial drones. Optimus decides to incorporate Learned’s mortgage calculator as a component of its app, so that the cost of a 30-year mortgage for the home in question shows up on the app’s visual display as the drone flies over a particular property. That’s perfectly fine, and it does not impact Optimus’ ability to sell its app, or claim a copyright interest in all of the other, proprietary code it has created for the app. But, Optimus cannot claim any proprietary interest in Learned’s code, and must include the open-source licensing terms with its own, larger body of code. If this was a copyleft license, rather than an MIT license, Optimus could not claim a proprietary interest in any of its code derived from Learned’s original code, and must make the new code it has created (although not necessarily the entire app, if only portions were derived from Leonard’s code) available to the world via an identical copyleft license.

Or let’s take the Bitcoin core code itself. The core code has been modified and updated by others since its initial release, pursuant to the open-source license under which it was first published. Indeed, back in 2014 in the now-discredited Newsweek article that “revealed” Dorian Nakamoto as Satoshi, Gavin Andresen was quoted as saying that 70% to 80% of the core code itself has been rewritten. Further releases of the core code have also been released subject to the MIT License, such that there is no question that the core code is currently available for all to use, for any purpose. The core code, obviously, has also been incorporated by many, many parties into new applications, some of which may well be considered proprietary by their creators.

And another that should be very clear: The concept underlying blockchain solutions clearly is not proprietary, and anyone can use that idea to create new solutions.

Notably, it is the original software creator’s choice which type of license to use, or whether to keep the original software proprietary and license only for a fee. Just as importantly, as noted, someone who has released software under an open-source license still technically holds copyright in their software — that is the very nature of a licensor-licensee relationship. Note the language of the copyright notice from Satoshi Nakamoto, above. This is different from a copyright “assignment”, whereby the original copyright interest is simply transferred to another party, leaving the original author with no remaining rights.

Crucially, this is also different from a work being dedicated or “ejected” into the public domain, at which point that work can be used by any member of the public, for any purpose, forever, and the original owner retains no copyright interest whatsoever. Many people mistake open-source licensing as analogous to dedicating software to the public domain. To the contrary, open-source licensing involves providing a work of authorship to the public to freely use, but does not convey (or relinquish) ownership in the code.

Some experts argue that it is not actually possible to dedicate a new work to the public domain, before the end of the copyright term. United States law does not provide any formal mechanism for doing so. Some countries may even prohibit the forfeiture of certain copyright interests. At the very least, an author who wants to dedicate a new work to the public domain must make his or her intentions unequivocally clear. Given this uncertainty, open-source licensing may be the better alternative; for instance, Creative Commons offers its “CC0 License” which allows authors to waive their copyright interests “to the greatest extent permitted by” applicable law and thereby place them as completely as possible in the public domain.

In light of the continuing copyright “tail” that may exist under an open-source licensing scheme such as the MIT License, there are some interesting aspects that the case of Satoshi Nakamoto highlights, and that deserve a bit of attention.

I’d Like My Software Back, Please

One thing to note about “licenses” generally, and copyright licenses in particular: Nonexclusive licenses do not give the licensee a legal right in the property being licensed. They merely allow the licensee to do something that otherwise would be unlawful (here, exploit code owned by Nakamoto). Nonexclusive licenses, without more, are technically not deemed contracts at all. Most importantly, nonexclusive licenses are typically deemed revocable at will by the licensor, and thus can be revoked at any time for any reason.

However, a nonexclusive license will be deemed a contract if it is accompanied by “consideration” on the part of the licensee. Consideration is something of value provided by the licensee in return for the license. While few cases have reached the U.S. courts regarding whether open-source license are supported by consideration, in 2008 the Federal Circuit in Jacobsen v. Katzer did address this issue, and found that there were powerful reasons for presuming that adequate consideration exists for most open-source licenses:

Traditionally, copyright owners sold their copyrighted material in exchange for money. The lack of money changing hands in open source licensing should not be presumed to mean that there is no economic consideration, however. There are substantial benefits, including economic benefits, to the creation and distribution of copyrighted works under public licenses that range far beyond traditional license royalties. For example, program creators may generate market share for their programs by providing certain components free of charge. Similarly, a programmer or company may increase its national or international reputation by incubating open source projects. Improvement to a product can come rapidly and free of charge from an expert not even known to the copyright holder.

Importantly, a nonexclusive license that is supported by consideration will also be deemed irrevocable, rather than revocable at will. Assuming that the Jacobsen case is followed by courts in other jurisdictions, which seems likely, open-source licenses should generally be treated as irrevocable by the licensor.

Irrevocable does not, however, imply that the license will be available to everyone in the world, forever. An open-source license is not a license between the licensor and the world at large, it is a license between the licensor and any party that takes and uses the software according to the conditions imposed in the license. A licensor may stop offering the software under license at any time. In this case, the license would be irrevocable as between the licensor and any licensee who has taken a license before the licensor stops offering it. As to a party who wanted to use the software after that date, there would be no license to take in the first instance. Thus Satoshi Nakamoto technically could withdraw his license from circulation at any time, or begin charging a royalty for any future use of his code.

Again, cessation of licensing by the licensor does not constitute a revocation of the licenses previously granted. Thus an open-source licensee can continue to act pursuant to the terms of the license (possibly in perpetuity, but see below for some potential caveats). Presumably, this includes the right to grant sublicenses, if that right has been granted in the original license, such as is the case with the MIT License. However, this sublicensing issue appears to have been little discussed in case law or in academia. In the case of the MIT License in particular, the fact that the license expressly states that Nakamoto grants a license to anyone “obtaining a copy of this software and associated documentation files” might be deemed as further indication that sublicensees should be permitted to continue using the code.

Assuming a licensor with an irrevocable license can continue to grant sublicenses, as a practical matter any cessation of licensing activity by the original licensor would likely have little effect on further development of software deriving from the original code, given the multiple sources of the code from licensed sources.

In other words, putting aside the technical niceties above, once open-source code is released into the wild under an MIT License, the world generally treats it as public domain.

Flies in the Ointment

Thus, it appears that the Bitcoin world is safe from the spectre of a revenge-seeking “Satoshi Nakamoto” seeking to thrust a dagger into the heart of the entire Bitcoin ecosystem. But, are there are any arguments that might prove troubling? A few.

Contract law in some states, including California and Illinois, holds that a license with an unspecified duration is terminable at will. Other states pursue a more flexible approach, treating a license with no specified term as terminable after a “reasonable” period of time, in light of the contract language and the context of the parties’ agreement. Could this provide a licensor grounds for terminating prior licenses, either at a time of the licensor’s choosing, or after some “reasonable” passage of time?

First, it is important to note that many open-source licenses state that the license is “perpetual”. Courts will likely honor this type of statement as providing the necessary specificity. None other than our good friend Judge Leonard Hand said this about “perpetual” contracts, back in 1925:

[T]he original contract. . . . was in terms unlimited in time, and the plaintiff apparently reasons that the defendant is bound forever to pay one-half of the expenses of maintenance. This seems to us untenable. Had the parties expressed the intention to make a promise for perpetual maintenance, we should, of course, have nothing to say; their words would be conclusive. But they did not, and, as no time is expressly fixed, we must look to the circumstances to learn what they meant.

Town of Readsboro v. Hoosac Tunnel & WR Co., 6 F. 2d 733 (2nd Cir. 1925).

The MIT License, notably, does not state that it is “perpetual”. Arguably, this provides a sliver of a possibility that a court might deem it terminable at will, or terminable after a reasonable period of time. One suspects, though, that the language of the MIT License — with its reference to anyone “obtaining” the code and granting the license “without restriction” and “without limitation” — might be deemed to imply a license in perpetuity, as would the open-source community perspective/position that such licenses cannot be revoked.

And even if some argument for revocation might be made, it seems likely that if a significant ecosystem of open-source development as evolved from the original code, a court would deem the licensor estopped from attempting to stop that evolution by means of an injunction.

There is a final limitation that only a copyright lawyer could love. Under Section 203 of the Copyright Act, every author has a right to terminate an exclusive or nonexclusive license 35 years after the license has been given. So, in 2044, theoretically “Satoshi Nakomoto” (or Wright or Dorian Nakamoto or Ross William Ulbricht or whomever) or his heirs will have the right to terminate all open-source licenses ever granted. To the extent there is any protectable Bitcoin core code embedded in software still extant in 2044, which is highly unlikely given the rapid evolution of open-source software, Nakamoto could then finally, theoretically bring a suit for copyright infringement.

Assuming he’s truly been identified by then.

Perhaps the most important take-away from this thought experiment is not the question of what happens when someone like Nakamoto attempts to revoke an open-source license, given that the courts will likely reject such efforts. What this exercise highlights is that it is important for downstream developers to understand the provenance of the code that they are modifying, especially if they are attempting to claim any proprietary rights in the resulting code. What hidden risks exist? Has all of the code being used been provided under an open-source license? Did the party purporting to license his or her code have the necessary authority from all those who assisted in creating the code? If these types of infirmities exist, the validity of your license may be at risk.

If you’ve made it all the way to the end of this, many thanks. Also, a caveat: Some parts of my analysis were new to me, so if you see anything I’ve gotten wrong, raise your hand!