“The Ethereum Foundation’s mission is to promote and support research, development and education to bring decentralized protocols and tools to the world that empower developers to produce next generation decentralized applications (dapps), and together build a more globally accessible, more free and more trustworthy Internet.”
From https://ethereum.org/foundation
TL;DR – What are you proposing?
I am proposing to the contributors that the C++ Ethereum client runtime (cpp-ethereum) be re-licensed from the copyleft GPLv3 license to the more permissive Apache 2.0 license, to enable Ethereum software to be used as broadly as possible (a long-standing plan). This proposal only addresses the C++ client runtime and does not include Solidity or Mix (the C++ tools).
There is another blog post detailing the likely operational steps in that process. This document seeks to explain why I am making that proposal.
What is Ethereum?
When we think about Ethereum, we usually think about public chain, and more specifically we think about the public chain (the “mainnet”). That is quite natural within the frame of reference of Ethereum purely as a cryptocurrency, but it is a limited view of the possibilities which this new decentralized computing platform offers.
Ethereum is much more than “a better cryptocurrency”. Ether is the fuel for the engine, but it is the Ethereum engine itself which opens up these new possibilities. The fuel is just a means to an end.
We have the opportunity to build a set of technologies in the next few years which could have similar societal impacts as the Internet, the World Wide Web and open source languages, relational databases, etc. We are building a decentralized computing platform which every individual on Earth should benefit from.
These technologies need to reach into every nook and cranny of our computing fabric: big and small, public and private, independent and corporate; smartwatches to mainframes.
This is a large and ambitious undertaking that is addictive and all-consuming for many of us. Diversity of viewpoints, a broad spectrum of use-cases to mature the base technology, and an open and inclusive attitude and environment of collaboration will help us achieve our shared goals.
Why do private and consortium chains matter?
“It is important to note that while the original Ethereum blockchain is a public blockchain, the Ethereum state transition rules (i.e. the part of the protocol that deals with processing transactions, executing contract code, etc.) can be separated from the Ethereum public blockchain consensus algorithm (i.e. proof of work), and it is entirely possible to create private (run by one node controlled by one company) or consortium (run by a pre- specified set of nodes) blockchains that run the Ethereum code.”
“Ethereum technology itself is thus arguably agnostic between whether it’s applied in a public, consortium or private model, and it is our goal to maximally aim for interoperability between various instantiations of Ethereum – i.e. one should be able to take contracts and applications that are written for public chain Ethereum and port them to private chain Ethereum and vice versa.”
Vitalik Buterin, Ethereum Platform Review paper
Many individuals and companies, large and small, see that opportunity the Ethereum platform has to offer, and are equally supportive of and inspired by the technical vision, even if their business goals vary dramatically. Public chains and private or consortium chains will likely end up having a lot more in common than meets the eye.
We have a working example of a permissioned Ethereum chain in the form of HydraChain, which was demonstrated at Ethereum DEVCON1 last November (2015):
Consortium chains can provide certain benefits beyond the general purpose public chain because they are special-purpose, such as:
- They can choose to have 1 second block-times.
- They might not need to do any node-discovery because the nodes are fixed.
- They can have incredible throughput (e.g. JP Morgan’s Juno boasts 2,000 txns/sec).
- They can modify consensus rules for performance (i.e. using PBFT).
- They can be a testbed for experimentation and innovation, because there will often be much smaller groups of stakeholders.
The interest in Ethereum can be seen in the ever-growing volume of news stories about blockchain and decentralized ledger technologies in general, but in particular, the interest in the Ethereum platform emanating from major technology companies has escalated rapidly and noticeably since the last Ethereum developer conference, DEVCON1, which was held in London in November 2015.
The Ethereum platform is unique in the crypto space in that a significant number of large publicly owned corporations are either already using it, have experimented with it, or are exploring how it may be used in or integrated with their current systems.
The author believes providing a permissive licensing will facilitate moving towards the dream of mass adoption of the Ethereum platform.
Some articles from Vitalik Buterin on private and consortium blockchains:
- On Public and Private Blockchains (August 2015)
- Vitalik Buterin on Misconceptions in the Private vs Public Blockchain Debate
- Ethereum Platform Review: Opportunities and Challenges for Private and Consortium Blockchains
Why permissive licensing over copyleft?
Software licensing is obviously somewhat of a religious matter, but there are practical reasons to favor permissive licenses for low-level components like Ethereum.
Beyond incompatibility between the GPL and corporate business models there are practical ways in which the GPL reduces Ethereum’s reach. The author was witness to these restrictions in his “past life” as a video games developer.
Worst of all are the games consoles. Code for PlayStation and XBOX usually has to be closed-source, because developers must sign NDAs (non-disclosure agreements) to be allowed access to the SDKs and they cannot redistribute those SDKs or any information about the platform APIs. That is commonly interpreted to include any code using those APIs. Some embedded platforms are similarly locked down.
While we could argue until the cows come home about the ethics of even using such systems, they are a reality, and making Ethereum available on them has value.
The Apple stores – App Store for iOS and Mac Store for macOS – are incompatible with the GPL, and the same is likely true of the Windows Store. The Terms of Service are applying additional constraints which are incompatible with the GPL.
The only “workaround” which I have seen for this incompatibility is for there to be a single copyright owner for the software, such that they can dual license it as GPL and commercial, and for the commercial version of the software to be used in the App Store. That is the approach which Mono used for nearly a decade, which means that developers wanting to use C# on iOS had to pay for a commercial license for Mono for all that time.
Open Whisper Systems recently added an exception to the GPLv3 license for their libsignal-protocol-c library, which permits people to incorporate that library into applications distributed through the App Store under Mozilla Public License 2.0, providing that the licensees are otherwise in compliance with the GPL. That exception looks similar to dual-licensing, but seemingly only applies for iOS.
That dual GPL/commercial licensing approach is a sensible approach for open-source friendly companies to take, which balances their desire to make the code available for public good while also generating revenue to keep them alive from those end-users who want or need to use the code in a context which is not GPL-compatible.
Dual licensing is the approach which Mono took, which Qt have recently switched to and which Ethcore are following with Parity. That dual licensing approach doesn’t work well for a Foundation, though, which is explicitly non-profit.
The choice of GPL for a Foundation just reduces the contexts in which the code can be used, because offering a commercial license is not really possible. Commercial licensing would be incompatible with the non-profit mission of the Ethereum Foundation.
More importantly, though, the Foundation does not own the code to be able to offer the code under a commercial license, because the Foundation has intentionally not required copyright assignment from the contributors.
What licenses does the Ethereum Foundation use?
At the moment we have a bit of a mixed bag. This proposal is only considering the C++ codebase, but it might make sense to look at licensing for the codebases as a whole.
- go-ethereum – GPLv3 and LGPLv3
- cpp-ethereum – GPLv3
- pyethereum/pyethapp – MIT
- ethereumjs-lib – MPL 2.0 and MIT
- remix – MIT
- web3.js – LGPLv3
Why Apache 2.0?
There are numerous permissive software licenses which are OSI approved, with a much shorter list of popular ones (really boiling down to MIT, BSD and Apache). Why are we favoring Apache 2.0 for the C++ codebase, where we had previously favored MIT?
See License compatibility from Wikipedia.
It essentially boils down to compatibility with GPLv3 in combination with protection from future software patent claims, which is obviously hugely important to Ethereum.
Apache 2.0 is the Free Software Foundation’s own recommendation for permissive licences for that very reason:
–
“This is a free software license, compatible with version 3 of the GNU GPL.”
“Please note that this license is not compatible with GPL version 2, because it has some requirements that are not in that GPL version. These include certain patent termination and indemnification provisions. The patent termination provision is a good thing, which is why we recommend the Apache 2.0 license for substantial programs over other lax permissive licenses.”
Various Licenses and Comments about them, Free Software Foundation
–
About the Ethereum C++ client
The Ethereum C++ project has spent the last few months rebooting under the leadership of Christian Reitwießner, who is probably best known as the lead developer on Solidity, but also leads work on Mix, Remix and on the C++ client.
A number of the original C++ development team departed last year, with Christian, Yann Levreau, Liana Husikyan and Dimitry Khoklov staying on. Bob Summerwill and Greg Colvin were added to the team in February, and Paweł Bylica rejoined the Foundation in March.
Christian has blogged about our progress in February, May and July.
We are on the verge of finally decoupling Solidity, (Re)Mix and Eth, so that we have three entirely independent projects – one runtime, two tooling.
That architectural decoupling is a dual-edged sword, because that tight coupling did a lot to keep the eth client alive. We needed Solidity and Mix, so development on eth had to continue too. All of the projects were interrelated.
Following this refactoring, it is getting much harder to justify any significant level of spending from the Foundation for ongoing eth development. We already have geth. Parity is becoming more popular. There are 8 clients in total. In the early days, having the Foundation funding multiple clients was crucial for maturing the protocol. With 4 clients developed outside of the Foundation, it is harder to argue for this spending anymore.
So what unique value does a C++ client bring to the table to justify ongoing spending, whether from the Foundation or from other community actors?
The author’s own interest in the C++ client was on the basis of resource-constrained devices and portability, potential for the best raw performance, and a possibility that such a profile might also be a good fit for data centers. Those are interesting stories, but not entirely compelling. Parity has a very similar “profile”.
With this huge growth in interest in Ethereum for private and consortium chain scenarios though, we have a fantastic new potential “niche” for the C++ client, which is Enterprise applications.
That wouldn’t mean that the C++ client wouldn’t support public chain scenarios. It would mean that we put an additional focus on modularity in the C++ client, so that it can start to span all of these categories in a way which has not been a primary focus to this point. And it would mean that additional resources could come to bear on this work, outside of purely being funded by the Ethereum Foundation.
Why is the Ethereum C++ client a good fit for Enterprise?
Development efforts within large enterprises usually quite conservative in their development language choices. They need systems to run for many years, and favor long-term-service platforms and well known and mature development tools. That often ends up meaning Java or C++ on Linux.
Newer languages like Go and Rust are less appealing in many corporate environments, because their developers have little to no experience with those languages, where they have Java and C++ experience to spare.
In addition, the C++ codebase benefited from a fairly significant refactoring last year which started to decouple the consensus mechanism. This was prototyped as a Proof of Authority (POA) alternative to Proof of Work (POW) in the (now retired) Fluidity client.
There has been huge interest in Ethereum integration within the Hyperledger consortium following Vitalik’s presentation to their Technical Steering Committee in April 2016. Hyperledger is a project under the Linux Foundation bringing together many member companies collaborating to build common blockchain and ledger solutions.
Outside of Hyperledger there are other companies who have already made their technology decision and chosen Ethereum as their base technology. Rubix by Deloitte, for example, have been building on the C++ codebase for several months and there are a number of other companies also favoring the C++ codebase.
With permissive licensing, work in any of these “C++ buckets” could proceed in parallel with existing Ethereum Foundation-centered work. We can collaborate where we have commonality and diverge where we need to.
Permissive licensing enables permissionless innovation.
Corporations don’t love you or hate you
Technology companies are now the largest corporations in the world by market cap.
Apple, Alphabet/Google, Microsoft and Amazon are literally #1, #2, #3 and #4 for the first quarter of 2016. Ahead of oil companies. Ahead of banks. Ahead of every other industry.
Most software developers are working for large corporations. Those corporations need tools to build their businesses. Open source tools resourced by large corporations are now the norm. There is a world of difference between the current day and the hostile landscape which Richard Stallman was facing in the mid-80s.
- Apple are obviously a money-making machine, but they also finance LLVM/Clang.
- Google do not have your best interests at heart, but that doesn’t mean that Go is evil.
- Facebook, mixed in with their people farming, have brought us React.
- Microsoft are night-and-day different from the Ballmer horror days.
Conclusion
Corporations will build blockchain technology irrespective of what we do. It is already happening.
Just as both Intranets and the Internet have a role to play, so do public and private/consortium chains. Maximalist thinking is not particularly helpful here.
The real world never works in black-and-white, and demonizing people with similar but not identical goals is self-defeating.
The author would rather have those corporations building Ethereum-based blockchain technology than have them building something completely incompatible purely because of the barrier of copyleft licensing which we have long planned to remove anyway.
Having these corporations within a shared “big tent” rather than in rival camps gives us maximal synergy, and taps the vast resources of those corporations to contribute to our goals, rather than letting them build rival ecosystems with zero synergy.
Proceed with caution, but please let’s proceed!
Appendix A – History of cpp-ethereum licensing
- Issue #3 – License (January 2014)
- Vitalik changed it to MIT License (January 2014)
- Gav reverted it to GPL (August 2014)
- “License is and always has been GPL – Gav” (October 2014)
- Issue #575 – Split projects, re-licence libraries as more permissive (December 2014)
- Pull #1392 – Suggestion for contributor license (March 2015)
- Pull #2789 – Wording for MIT license and external contributors (August 2015)
- Issue #530 – Get to clarity on licensing and copyright (May 2016)
Appendix B – A selection of Enterprise blockchain articles and events
- March 2015
- April 2015
- July 2015
- August 2015
- September 2015
- October 2015
- December 2015
- January 2016
- February 2016
- March 2016
- 40 Banks Trial Commercial Paper Trading in Latest R3 Blockchain Test
- JPMorgan Unveils ‘Juno’ Project at Hyperledger Blockchain Meeting
- Meet the Technical Minds Behind the Hyperledger Blockchain Project
- Hyperledger On Verge of Merging Blockchain IBM, Digital Asset Code
- Microsoft Adds Ethereum to Windows Platform For Over 3 Million Developers
- April 2016
- R3 Blockchain Consortium Partners With Microsoft
- Introducing R3 Corda: A Distributed Ledger Designed for Financial Services (Richard Gendal Brown)
- Intel Unveils ‘Sawtooth Lake’ Proposal at Hyperledger Meeting
- Intel Conducting Experiments to Massively Scale Blockchain
- Vitalik Buterin Pitches Hyperledger Project on Ethereum Integration
- May 2016
- June 2016
- July 2016
Bob's Blog 
Thank you for this Bob. Strongly agree with the re-license to Apache.
Thank you! It certainly makes sense to me, and has been the long-term plan.
Hopefully it won’t be too long and painful a process. I’m already a couple of months into the work 🙂
Great article. Thanks for (re)posting it on the Reddit!
Thanks, Eric. Glad you enjoyed it!
NIce, the more I discover Ethereans the more I see the interests of everyone are alike. We share the permaculture one!
🙂