In April 2016, Vitalik Buterin gave a presentation to Hyperledger’s technical steering committee on how Ethereum could be integrated into the project, going so far as to suggest that Ethereum’s protocol could become the backbone to support Hyperledger. This excited enough of the Hyperledger team to foster active communication with the Ethereum community.
To clarify: Hyperledger never wanted to acquire Ethereum but were looking to collaborate. They considered hosting projects that would be designed to connect to the ETH chain as a client or be built on top of the Ethereum platform. They attempted to solidify this collaboration by incorporating Ethereum C++ (cpp-ethereum) into Hyperledger but to do so, the C++ iteration would first have to be relicensed before being absorbed. That’s where the potential collaboration stalled and began to fall apart.
To make use of the C++ codebase within Hyperledger, every developer who worked on the code would need to sign off on relicensing their contribution to the project. The relicensing effort was allegedly blocked at the last minute by former Ethereum Foundation member and current Ethcore founder, Gavin Wood, who had written most of the core code of cpp-ethereum. ETHNews reached out to Gavin Wood for comment but has not heard back as of this publication.
ETHNews also contacted Bob Summerwill, a former Ethereum core developer who worked on the cpp-ethereum client and now works on ConsenSys’ Enterprise Ethereum project. Summerwill had been leading the charge that tried to relicense the C++ client before it was effectively stopped, and was kind enough to answer our questions:
ETHNews: Is there any way to move forward without cpp-ethereum relicensing, or is this integration dead in the water?
Bob Summerwill: I am afraid that we missed a great and unique opportunity for the two communities to collaborate. I have the utmost respect for Brian Behlendorf, Chris Ferris, and the rest of the Hyperledger crew, and I think that we all could have benefited immensely from working together. I think that a C++ Ethereum client within Hyperledger would have been a great development place for Enterprises to get involved with Ethereum, and especially for building and testing consortium chain features.
What will Hyperledger do regarding Ethereum moving forward? Will you look for a different way to integrate Ethereum into the Hyperledger Project?
I'm not sure. There were discussions about Nethereum and Web3j making sense within Hyperledger. That might still make sense, but in the absence of an Ethereum client codebase, that is of much less value than it could have been.
Do you see this as a major blow to the widespread adoption of Ethereum?
I think it was a real missed opportunity, for sure, but by no means a body blow.
Will Hyperledger be looking at working with other blockchain networks instead?
Hyperledger already hosts multiple blockchain technologies - Fabric, Sawtooth Lake, Iroha, and R3 have also open-sourced Corda. It would have been lovely to have an Ethereum client as part of that list, because it would have made Ethereum an easy choice for the many Enterprises who are already engaged with the Linux Foundation, using Linux, OpenStack, node.js, etc.
Summerwill and Hyperledger saw real potential in cpp-ethereum due to the popularity of C++ as a programming language. Much fewer programmers are trained in newer languages like Go, in which the Geth Ethereum client was written. That familiarity is what makes C++ ideal for enterprise needs and is part of why Hyperledger attempted to help the community reach consensus regarding relicensing the cpp-ethereum client, which is currently under a GPL-3 license.
What’s so important about changing a software license? It all comes down to the differences between two types of open source software licenses: GPL-3 and Apache-2.0. The Hyperledger Project and its many components are all united under an Apache license. They prefer to use only one license because working out the legality of certain business moves can become overly complicated, due to differences in language and permissions of the licenses. Apache is appealing to businesses and large corporate entities because it’s more permissive. While both licenses allow commercial use, GPL expressly forbids sublicensing and Apache allows it.
Apache does this through the Grant of Patent License section of its text. The actual language within Apache regarding patent licenses reads, in part:
“Subject to the terms and conditions of this License, each Contributor hereby grants to You a perpetual, worldwide, non-exclusive, no-charge, royalty-free, irrevocable (except as stated in this section) patent license to make, have made, use, offer to sell, sell, import, and otherwise transfer the Work, where such license applies only to those patent claims licensable by such Contributor that are necessarily infringed by their Contribution(s) alone or by combination of their Contribution(s) with the Work to which such Contribution(s) was submitted.”
Mainly, an Apache license gives a corporate entity the ability to sell their software, while keeping certain parts of it confidential. With a GPL-3 license, you can still sell your code, but you can’t prevent another party from later giving away it away for free. Also, within GPL-3, a corporation’s secret proprietary code would have to be relicensed as GPL-3, meaning their secrets could no longer be confidential. In the preamble of the GNU General Public License Version 3, it states:
“When we speak of free software, we are referring to freedom, not price. Our General Public Licenses are designed to make sure that you have the freedom to distribute copies of free software (and charge for them if you wish), that you receive source code or can get it if you want it, that you can change the software or use pieces of it in new free programs, and that you know you can do these things.”
This type of license is great for bootstrapping a good concept when you have very little funds to hire developers. When the code is able to be worked on by an entire community of free-software-loving developers, the quality of that code increases. The GPL-3 ensures that any code released under that license will remain under it.
If the code is licensed under GPL-3, that license is required to follow the code and all of its derivations, which is part of the problem. The GPL can effectively creep into any code you pair it with – meaning if any GPL code is used as even a small part of a project, that entire project is now subject to the terms of the GPL. Due to how copyright law works with the GPL-3, any formerly proprietary code becomes a derivate work and is then subject to the terms of the GPL. That means a company wouldn’t be able to keep their exclusive source code private.
A GPL is a “copyleft” (inverted copyright) type of license because it carries a share-alike clause. It follows the code no matter what portion is used or what changes occur, using the rules of the copyright system to protect free software from that very system. Technically, anyone could slap their name on a public domain product and resell it as their own. While they could also run into “moral rights” issues depending on their jurisdiction, the GPL-3 would not allow something like that to happen.
Regarding “free” software, Richard Stallman, American software freedom activist and programmer, famously said, “Think free as in free speech, not free beer.” This is all about the distinction between freeware and free software. The former being gratis, or free of charge, while the latter is Libre, meaning unrestricted. According to the Apache Software Foundation (ASF):
“The Free Software Foundation considers the Apache License, Version 2.0 to be a free software license, compatible with version 3 of the GPL. Apache 2 software can, therefore, be included in GPLv3 projects because the GPLv3 license accepts our software into GPLv3 works. However, GPLv3 software cannot be included in Apache projects. The licenses are incompatible in one direction only, and it is a result of ASF's licensing philosophy and the GPLv3 authors' interpretation of copyright law.
This licensing incompatibility applies only when some Apache project software becomes a derivative work of some GPLv3 software because then the Apache software would have to be distributed under GPLv3. This would be incompatible with ASF's requirement that all Apache software must be distributed under the Apache License 2.0.”
This shows how something as simple as the specific language in two similar, but different, types of free software licenses can greatly affect what is able to be done with that software. If cpp-ethereum were licensed under Apache all along, there would never have been an issue, and Hyperledger could have simply taken and integrated the C++ client. But, due to friction between the different licenses, and the developers who chose those licenses, a potential collaboration has fallen by the wayside. However, there are still other ways for Hyperledger to integrate Ethereum in the future, so there’s still the potential for collaboration. This is just an example of the growing pains Ethereum will experience as it continues to develop into the world computer it aims to be.