Allessandro Mazzi
Latest posts by Allessandro Mazzi (see all)
- Open-source Licensing and its Trends in Blockchain - July 4, 2018
Software development based on collaborative enhancement of source code has existed informally since the 1980s (and even before). This collaboration could easily be considered the main driver of many online products and services we use every day. Although I have a broad understanding of open-source and in specific software licensing, I am not a developer. As such, this article does not aim to explain the specifics behind the approach. Instead, I will use my legal knowledge to examine the relevant intellectual property matters – and blockchain open-source licensing in particular.
As a legal expert working mostly with Blockchain-based companies, I am repeatedly asked the same questions:
- What code is mine?
- Can I publish the software under my name?
- How can I protect my code?”
While I will not answer these questions one by one or to give a sort of one-size-fits-all solution, I will explain the principles behind free-software, or open-source licensing, and briefly analyze the licensing of popular blockchain open-source software.
What is open-source Licensing?
Open-source licenses are legally binding instruments that set the rules on how you, as a software developer or company, can use, distribute, modify, and share a publicly available piece of software.
In a licensing agreement you typically have two parties:
- Licensor: the developer/company who created the software
- Licensee: the counterparty to whom the Licensor grants the right to use, modify, distribute, sell etc. the software.
These rights come with various rules and restrictions that licensees have to respect in order to continue to enjoy using the software. These rules and restrictions can vary depending on the type of open-source license the licensor chose to protect their work.
At this stage, the words “free” and “open” and terms like “license” and “restrictions” might confuse you. That’s okay. You wouldn’t be the first to develop software based on a single idea rather than a combination of both.
First of all, you should understand that there are no pure “open” and “free” licenses available. Also, most free software licenses have some requirements that licensees should meet in order to use, copy, and modify the licensed source-code.
Open-source licenses are generally divided into two macro categories: permissive licenses and restrictive (or copyleft) licenses. Both permissive and restrictive licenses give the right to Llicensees to copy, distribute and modify the software.
Permissive licenses such as the well-known MIT license allow you to modify, merge, distribute, publish, sub-license the software and distribute it under different terms than the ones included in the original license. The only requirement under a permissive license is that you include the copyright and license notice — including the disclaimer — in all copies or on the substantial portion of the your derivative work. You are free to re-license the derivative work as long as the notices are attached to your license.
As you can see from the text of the MIT Llicense below, it basically states “Do whatever you want with my code, but no matter what, you cannot hold me liable for it”.
Like the MIT one, pure permissive licenses are short, rather straightforward, and are the closest you can get to open and free use of software, with the only requirements stated above.
With restrictive licenses, on the other hand, you will have to pay attention to strict obligations. This includes a licensees’ obligation to disclose the source code for any derivative work developed using the software. You must also keep the content of the license intact, prohibiting Licensees to enforce their own terms on derivative work.
When using or modifying even a tiny piece of the licensed software, under a restrictive license you must for instance, pay a fee for the use of the derivative work or are obligated to document every change made to the code.
Even with these more stringent requirements restrictive licenses are the most popular. There are also two types of restrictive — or copyleft — licenses:
Most developers get confused when working on restrictive licenses due to the obligation applying the original license to, potentially, all derivative work.
To understand this fully, let’s try to understand the principle behind this requirement.
When licensing through a copyleft license, the licensor makes sure that the software they spent thousands of hours to develop will be distributed under the same distribution terms of the original License. By asking licensees to “virally” attach the same distribution terms to each derivative work, the licensor has control over the way the software is distributed down the line. This ensures that additional terms will not affect the value of the original piece of work.
Copyleft licenses such as the GPL also require that the Licensee shares the source code for any derivative work, including any new code written specifically to go into the modified version. In all honesty, that’s pretty fair. After all, if I as a licensor give you the freedom to use, modify and freely access my code, why shouldn’t you do the same?
A Blockchain project, for instance, shares the enhanced source-code back to the licensor and by doing so creates great value for the original software that would be lost if further improvement of the code would be kept confidential or, worse, copyrighted.
In the weaker copyleft licenses such as the LGPL, the obligation to release the source code is waived. This means you can use and distribute the software you developed using the open source code without the need to release the source code back to the licensor.
Quick tips for dealing with licenses
While obvious, there is one piece of advice I cannot stress enough:
You must always read through each and every license and make sure you fully understand them.
If it’s a permissive license, you can do whatever you want — legally — with that software as long as a you include the copyright and permission notices in all copies.
If you stumble upon a restrictive license, make sure you follow, word-by-word, all disclosures, requirements, and restrictions included in that license. Since the documents you will come across when dealing with restrictive/copyleft licenses are long and complex legal documents, getting an advice from an IP lawyer specialized in open-source licensing might be the good investment.
If you build your software using open-source material without understanding — and subsequently breaching — the licensing terms, you will pay a lot in legal fees. Most importantly, this will make the value of the software you developed worthless.
This is just a short summary of the most used and trusted open-source licenses. Of course there are many more variants and combinations. For a comprehensive overview of the most common licenses available with related descriptions of their characteristics, check out this link.
Blockchain open-source licensing and the Ethereum dilemma
The code underpinning most cryptocurrency and open Blockchain projects is developed and distributed following open-source principles.
Blockchain giants such as Ethereum and Bitcoin have adopted (or are on the way to adopt) classic restrictive and permissive licenses (or a mix of both) for their networks’ code.
There is no real common approach towards licensing in Blockchain and I believe we will see common approaches develop in the coming years. Some projects have created already a hybrid license using the standard restrictive/copyleft licenses and adapting them to the peculiar characteristics of cryptocurrency networks. Others basically just adopted common software licenses with no modifications.
An example of the former is the Jelurida Public License (JPL) which follows the GNU GPL, but adds a 10% airdrop requirement for licensees creating a tokens using Nxt software licensed under the JPL. Any project using Nxt code for their project should follow the typical GPL common copyleft requirements. Additionally 10% of the coins created using the Nxt software should be airdropped to Nxt token holders.
This way, Nxt assures that each licensee using the Nxt code brings value back to the Nxt original contributors and Nxt network.
Bitcoin Core software (which is a product of more than 15,000 developers’ contributions) is licensed under the permissive MIT license. Other projects such as NEO and EOS seem to follow the same path of permissive licenses.
Now let’s talk about Ethereum — certainly the most popular blockchain open-source software in the blockchain space.
If you look at the Ethereum/wiki github page, you will see they have divided their software licensing strategy between the Core, the Applications and the Middleware. Every software component has its own license.
First of all, they use the future tense “will” meaning that at the moment there is not a sure answer on what kind of licenses they will actually use. I am guessing they are waiting a full switch from Proof of Work to Proof of Stake.
From a legal point of view this uncertainty raises some concerns, especially considering the number of projects using Ethereum smart contracts as the basis for their projects.
According to a company statement, they will release Core either under a MIT license, Mozilla Public License (“MPL”) or LGPL. To reiterate what we learned above, they cannot decide between releasing Core under a permissive license or a partial copyleft or a weak copy. If you understand the different characteristics of open source licenses, your first reaction may be similar to mine: Ethereum, make up your mind! As it stands, they are currently seemingly keeping every option open.
What might help interpreting their list of candidates is the further explanation and principles under which Core will be released.
They indeed state that the goal is to release Core “for use in any commercial environment, closed or open source”. This statement together with “the core of Ethereum will be released under the most liberal of licenses” leads me to predict they will release core under a MIT-looking license. But again, that’s just a guess.
For the ones who built already on Ethereum, the cpp-ethereum (which contains all core libraries) is currently released using what looks like a restrictive copyleft license.
With regards to the Ethereum Applications and Middleware, thankfully, they seem confident they will be releasing both — including the solidity compiler — under a GNU and an Affero GPL (both restrictive).
What does this mean to you?
In short, both licenses will restrict your ability to sub-license derivative work or make amendments to the commercial terms of the license.
Without going into too much detail, Affero GPL differs slightly from the pure GNU when it comes to the definition of the term “distribution” of software developed in that it has to be made available to all users.
This diversity in software licenses tells us a lot about the Ethereum licensing strategy. As they state in their github page, their strategy to release the Ethereum software under different licenses is consistent with their will to keep distinguished approaches towards different pieces of the software. Briefly, some will be released under the principle do-what-you-want while others will have to follow the viral principles of do-what-you-want-but-under-our-terms.
Takeaways
All this is not meant to scare you away from working on open-source or Blockchain projects. On the contrary, it is meant to give future open-source contributors a simple guide on understanding free software licenses.
Bear in mind that licenses are there not only to protect the licensor’s work, but to protect your derivative work, too. Understanding open-source licenses will not only prevent you from having to handle legal battles with licensors, but can also be used as a tool against infringements of the work you developed.
With freedom comes responsibility, and your responsibility when making use of an open-source code is to comprehend the rules behind each resource you use. If you are in doubt, contact an expert. It’s an investment that means the difference between a successful project and a dead one.
