“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
  • Former JPMorgan Exec Blythe Masters Swaps Wall Street for Bitcoin
• April 2015
  • Consensus-as-a-service: a brief report on the emergence of permissioned, distributed ledger systems (Tim Swanson)
• July 2015
  • Inside R3CEV’s Plot to Bring Distributed Ledgers to Wall Street
• August 2015
  • On Public and Private Blockchains (Vitalik Buterin)
  • ConsenSys Emerges From Stealth with New Website
• September 2015
  • Nine of world’s biggest banks join to form blockchain partnership
• October 2015
  • Microsoft Partners With ConsenSys To Use Ethereum To Provide Blockchain-As-A-Service
• December 2015
  • Linux Foundation Unites Industry Leaders to Advance Blockchain Technology
• January 2016
  • R3 Completes Blockchain Test With 11 Banks
• February 2016
  • ConsenSys Joins Linux Foundation Blockchain Initiative
    
  • IBM has just open-sourced 44,000 lines of blockchain code on GitHub
  • IBM Exec Elected Chair of Hyperledger Blockchain Committee
• 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
  • China Joins the Blockchain Race With ChinaLedger Alliance
  • Cats and dogs can be friends (Bob Summerwill)
  • Apache Foundation Founder Named Hyperledger Executive Director
• June 2016
  • Opportunities and Challenges for Private and Consortium Blockchains (Vitalik Buterin)
  • 31 Chinese Firms Form Financial Blockchain Consortium
    
• July 2016
  • Russian Finance Firms Form Blockchain Consortium

A couple of weeks back, I had the pleasure of making a number of new friends and acquaintances while I was in Austin, Texas for the OSCON 2016 Open Source Conference.

I will do another blog post about OSCON more generally, but here I focus on the open source blockchain Meetup.

NB: If anybody has further photos or notes to add, please let me know, and I will update this blog post.

Capital Factory were good enough to donate meeting space for about 30-40 attendees for the Open Source Blockchain Meetup which I organized to bring together blockchainers of all stripes, both Austin-local and out-of-towners who were at OSCON.    We also had several people who drove to Austin specifically for the event, which was very humbling.

I certainly enjoyed the evening immensely, and I hope that everybody else did too!

The idea was simply to bring together people from across all of the many open source blockchain and decentralized ledger technology projects, to get some common understanding of what we are all working on, and to make some personal connections and friendships.

I think that these technologies have the potential to have as large an impact as the Internet, or Linux, and that we will all have a lot more in the way of common goals than we will have differences.    It is a big pool and there is more than enough room for us all to swim in it 🙂

We started with Brian Deery of Factom, who talked briefly about Bitcoin, though most people present were already familiar with the granddaddy of blockchain technologies 🙂

I then gave a quick introduction to Ethereum.   Slides below.   No photo of my ugly mug available, I am afraid!

We also had Renat Khasanshyn whose company Altoros, has been doing much of the early presentation material for Hyperledger, along with building sample applications.

… and Bishop Brock, of IBM Research, who is focussed on blockchain on Mainframes.   Yes, blockchain on mainframes.   I bet they get some decent transaction throughput!   There were some other local IBM-ers too.

Brian Deery spoke again on the topic of Factom, and what they are building there.

Pete Harris, of Lighthouse Partners spoke about a new Austin Blockchain for Business Meetup which he is just starting up.    Pete is a great networker and organizer.   I look forward to seeing all of the blockchain businesses which will come out of Austin in the coming years.

And then we mingled until 9pm, when our time at Capital Factory was up, but many more of us continued to talk for a few more hours around the fine drinking establishments of Austin.

Scott Travis (below) contacted me after the Meetup and said … “That was my first meetup to attend, brought me out of my coding cave to meet some fellow Ethereum enthusiasts.”

I think there were other first-timers there too.    I think that Meetups are fantastic.   Talking to other people with similar interests is so helpful.    We’re all human, and face-to-face interactions are unbeatable.

Hector Torres was looking for collaborators for healthcare use-cases on the blockchain, and invited people to contact him at hector@ulahealth.me.

I also got to meet Niran Babalola of ConsenSys and Dustin Byington, of Satoshi Talent and SmartContract Exchange Inc, formerly at Tendermint.    And many others whose names I have sadly forgotten.   That’s what the beers after the meeting did to me 🙂

Getting out from behind our keyboards is very important, and I’m glad that I got the opportunity to meet you all down in Austin.    Best wishes!

Thanks to Paul Snow, of the Austin Bitcoin Meetup, Niran Babalolo of the Austin Ethereum Meetup, Mark Morris of the Austin Blockchain Meetup for helping to gather attendees!