Skip to content →

On Blockchain Software Licenses

Blockchain software has its roots deep in the FOSS (Free and open-source software) movement (bold is mine).

There used to be a time that not releasing code under a FOSS license, like MIT or GPL, automatically disqualified a project to be seen as legitimate.

There are very good reasons for this, as the aim of blockchain software is to have free and open projects for transacting with people, which means people need to have a chance to audit the code for themselves, or at the very least have a choice in trusting a large panel of engineers to have done this for them.

Of course, this kind of license soon also became a smoke-screen. In order to be considered peer-reviewed, code actually needed to be reviewed and the findings publicised.

With the flood of projects, even at 400-600 projects in the period of 2014 to 2017 this was an impossible ask. This lead to many projects just pointing at their OS code and claiming it was peer reviewed by the merit of being Open Source.

Open Source is not enough

Free Software is rather strictly defined. Just having your code available for review does not make a project Free Software!

Making your code available for review is a means, not an end. It is a means to achieve broader goals, which are defined by the FSF (Free Software Foundation) and the OSI (Open Source Initiative).

As stated explicitly on the site of the OSI:

Open source doesn’t just mean access to the source code

The FSF is even stronger on this issue, as you can read in this article: Why Open Source misses the point of Free Software.

There has historically been a lot of overlap between Open Source and Free Software, but it is important not to confuse the two. Free Software has a different goal than just Open Source, and we need to have a clear view why Bitcoin and related softwares were always FOSS, not just OS.

Blockchain Software has value, and that’s a problem

Arguably, because tokens on blockchains represent value, the software has different characteristics that we previously have seen in other projects.

We can see this most clearly in situations where software forks.

Linux has been forked so many times the fork tree is ridiculously and comically huge:

Source: http://akachopa.blogspot.nl/2012/08/silsilah-keluarga-linux.html

Take just one fork of the above image (Debian) and lets see how many forks there are of that one:

Source: https://upload.wikimedia.org/wikipedia/commons/d/d8/Debian_family_tree_11-06.png

These timelines extend up to 2007 and 2013 respectively, so who knows how much they have grown since then.

The same has happened to the Bitcoin code, as can be seen at Map of Coins, which tracked code forks of Bitcoin.

There is an immediate problem here, though. In blockchain technology, several things are called forks, and that causes a lot of confusion and thus adds to the confusion surrounding the FOSS licenses.

This work is licensed under a Creative Commons Attribution-ShareAlike 4.0 Generic License.

Technically, the only kind of fork that is combatible with the forks FOSS deals with is the “codebase fork”. Consensus forks and stale block forks are not covered by these licenses at all.

If you want to watch more information about the different kinds of forks in blockchains, go and see my presentation on the subject:

And that’s where things get tricky. Bitcoin and other tokens have value. So if forking is always possible, that allows someone to “leech” value off the main project, or so some would argue.

It can be argued that the forks of Bitcoin that emerged last year (Bitcoin Cash, Bitcoin Gold, and all the others) now hold value that should have been in the original pre-fork project. This is a debate that is still ongoing and which I do not want to cover here, but it at least will give you an idea how controversial the forking question is: when there is money involved, people get passionate and above all protective, something FOSS explicitly is a barrier against. See “Freedom 3” in “What is free software?

The freedom to distribute copies of your modified versions to others

New licenses and the demise of FOSS in blockchain tech

It is not unsurprising that in an industry where vast amounts of money are represented by software attempts are made to halt the free distribution of the code.

One of such steps was for projects to move to more restrictive FOSS licenses. This may seem counter-intuitive, but bear with me.

The Bitcoin software is licensed under the socalled MIT license, also known as X11 license.

This license is extremely lax, also allowing people to use the code in their own proprietary programs.

Some projects, like Ethereum and Nxt, later moved to versions of the GPL license. One of the key differences in this license is that it explicitly forbids derived software to be published under anything other than a GPL license.

This turns out to act as a deterrent to projects that might want to monetise their code down the road, as they can never use their code in proprietary projects without violating the license. Case law for this is extensive, so you cannot just copy the code and get away with it anymore.

Later, Jelurida B.V., which now maintains both the Nxt and the Ardor codebase, created their own new license, called the JPL (Jelurida Public License). The JPL is a license that amongst others requires forks to provide part of the value in tokens to holders of the original fork.

nChain, a company working on the Bitcoin Cash code, apparently has also created their own license, called “nChain Open Bitcoin Cash License”. I don’t have a lot of information about this yet, but apparently it includes a restriction, quoted in a press release as

only for users to create software or applications that operate on the Bitcoin Cash (BCH) blockchain

Both of these licenses can be argued not to be in the FOSS strain anymore, as they both put limits on how the software may be shared and distributed.

On the other hand, there are also initiatives to try and block agressive moves to patent of appropriate software to one player in the market, by creating structures that explicitly protect against any software being under the sole control of one market player.

The most noticeable initiative, in the wake of the ASICBoost patent, was the Blockchain Defensive Patent License. A key provision of this license is that all signees of the license need to share all their patents with all other licensees. The license came into being in the context of mining patents, where an advantage to just one player in the field might upset the whole Bitcoin ecosystem.

My Take

As with all discussions, we are just at the start of all of this.

The fact that blockchain software usually represents substantial value and where forks will directly affect holders of tokens created by the software means we will see a lot of action in this field.

Simple human psychology leads me to believe that most early licenses will be primarily restrictive and protective and will most probably fall outside the FOSS framework. This is something we should all be watchful for, because it can have far reaching consequences. The software has been created with the explicitly stated intent to do without intermediaries. Restrictive licenses that have been worded in such a way to benefit a company or small group will do the exact opposite.

Licenses created by large groups or consortia that can be freely joined without barrier are probably the way to go, as it will most probably be necessary to protect against outside players trying to get an overly large and manipulative foothold in the market. I see this as a fruitful field to explore.

If there are any other initiatives like the ones mentioned about, I would love to hear about them. Licenses are ideology framed in law, and as such I find them very telling and interesting.

 

 

Bas Wisselink
Follow me

Bas Wisselink

Freelance trainer and speaker at Blockchain Workspace
Bas Wisselink is a freelance writer, public speaker and trainer. He is a founder of Blockchain Workspace. His expertise is in education, training and presentation skills.
Bas Wisselink
Follow me

Also published on Medium.

Published in Articles