EEA Technical Working Groups Need YOU!

eea

The Enterprise Ethereum Alliance (EEA) has a number of technical working groups (WGs) already in motion:

Self-organizing working groups are intended as the primary mechanism for members to contribute to the EEA.    There were 30 member companies at launch, and it appears likely that number will grow rapidly in the coming months.   It is impractical for every company to be represented on the primary committees without those bodies becoming unwieldy and ineffective.

HOWEVER, there are numerous topics where coordination within working groups would be very beneficial, and much of this work can happen in parallel.  This breadth of effort should allow us to take advantage of the scale of talent and resourcing available across our collective membership without getting bottlenecked.

If you haven’t got involved in any of the working groups yet, the best place to start is by joining the Technical Mailing List, which is acting as the “lobby” for the working groups.

Please introduce yourself and share your interests.   Better yet, offer to create and lead new working groups where you see a need.    We don’t have heavyweight process.   The most important thing is for the conversation to get started.   There is a suggested template to help clarify scope.  There are Confluence pages for each group here.    You do not need anybody’s permission to create a new sub-group.

The intention of the EEA is not to dictate any kind of top-down structure, but for members to self-organize around their key requirements and needs, and for those groups to make concrete proposals which then filter upwards to define our standards and best practices.    With that caveat in mind, here are some possible Working Group ideas which have been raised in the past and might make sense:

  • Benchmarking
  • Testing
  • Architecture
  • Security
  • Cryptography
  • IoT
  • Best practices
  • Interoperability
  • Requirements and use-cases
  • [Bring your own suggestions]

So please do jump in and help!   Many thanks.

New Granville Island Office

image20160902_151557878.jpg

I had been working from a coffee shop every day for the best part of the year.   That was just fine in most respects, but it has meant that I never completed the setup of my hardware test farm for cpp-ethereum-cross.   It was time for me to look at rented desk space again.

I found a real beauty of a spot which was newly available on Granville Island, right by the water, in a converted houseboat, by The Profile.    I am already finding lots of common interests with my coworkers.   There is an old TV, and my Atari 2600 and Commodore 64 are definitely going to get hooked up 🙂

image20160902_094209107

image20160902_094217723

image20160830_132352456

image20160830_133435328

C++ re-licensing plan

Overview

This is a proposal to re-license the C++ implementation of the Ethereum client runtime (cpp-ethereum) from the copyleft GPLv3 license to the permissive Apache 2.0 license, to enable Ethereum to be used as broadly as possible.

NB:  If you would like to discuss this plan, please let’s all do so on cpp-ethereum Gitter channel.   Thanks!

Moving to permissive licensing has been the “plan of record” for a year or so, which we are belatedly executing on.   Gavin Wood actually started the process of relicensing to MIT last year, but it was never completed.    So we’re going through the process again now.

There is another long-form article talking about the rationale for the change and the history leading up to this proposed change of licensing, so I won’t duplicate that content here.

This post talks through the expected operational steps for making this change.   These steps aren’t entirely sequential, and we will be doing overlapping steps in parallel wherever we can, to try to get through the tedious process as quickly as we can.

Ultimately the contributors to the C++ codebase will make the decision on whether or not we relicense, and there is no intention from the Ethereum Foundation to “force” the process.

 

 

Steps to be followed

  • Creation of a Github issue to start the ball rolling                       [started May 25th]
  • Start to gather contributor details (Piratepad, then Wiki)         [completed July 7th]
  • Mention in the last few releases that we are contacting contributors  [May, June, July]
  • Ad-hoc conversations with contributors on the issue, Gitter, email   [Ongoing]
  • Talk to an IP lawyer to verify what we need to do, in rough strokes   [June 22nd]
  • Publicize “the plan” and work through any disagreements      [July 12th onwards]
  • Distribute paperwork to all contributors     [August 18th to August 24th]
  • Complete the process and change the license
  • Announce that change to the world

 

apache

What is the paperwork?

Everybody who has contributed to the code in question (see below) will be sent a letter, probably both as a PDF and physically, which essentially attests to the fact that they were the author of that code, and giving their approval for that contribution to be used under the Apache 2.0 license.

Future contributors will be required to make a similar declaration.    The one page document just ensures that there is no ambiguity for any party in the case of future disagreement or legal action.

Here is a template for the paperwork, which is legal boilerplate from the Linux Foundation adjusted to our project.

This is not final paperwork.   Discussion ongoing.

 

Content to be relicensed

The following repositories are in the process of being reorganized into a restored cpp-ethereum repository, which will be relicensed as Apache 2.0:

That will include the following applications:

  • Ethereum VM:
    • eth
    • ethvm
  • Unit-testing:
    • testeth
    • testweb3
    • testweb3core
  • Support tools:
    • bench
    • ethkey
    • ethminer
    • rlp

The following standalone repositories will also be relicensed to Apache 2.0:

The following repositories, containing the Solidity compiler and the deprecated C++ GUI applications will remain under GPLv3:

The following repository, containing the new “Remix” debugging components will remain under MIT, though we might want to consider whether that should be Apache 2.0 as well?

Ethereum Everywhere

“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

Ethereum_logo_bw

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 impact as when the Internet, the World Wide Web and open source languages, databases, etc. became available.  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?

private

“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

vitalik-buterin

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:

 

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?

 

Floss-license-slide-image

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.

christian

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 FebruaryMay 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

Screen Shot 2016-06-26 at 10.51.00 PM

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!

Proceed-with-Caution-State-Farm

 

 

Appendix A – History of cpp-ethereum licensing

Appendix B – A selection of Enterprise blockchain articles and events

Cats and dogs can be friends!

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.

CapitalFactoryLogoBlack

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 🙂

image20160518_174344359

image20160518_171129327

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

I was delighted that Christopher Ferris, who is the Chair of the Hyperledger Steering Committee was able to join us to talk about “What is Hyperledger?”     That was a very last-minute.  He was in town for OSCON, but it looked like he wouldn’t be able to make the meeting, but his travel plans changed last minute, so he was able to join us.

image20160518_172203051

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

… 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.

image20160518_180950855

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.

image20160518_175942619

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.”

image20160518_170824940

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.

hector

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!

Windows 10 nuke-and-pave

So today was the day where I had enough of screwing around with trying to get Visual Studio 2015 installed on my Surface Pro 3.

I had been battling Team Explorer for Visual Studio 2015 -> Fatal Error for a week or so, like many suckers before me, and was fed up of trying hack-after-hack.

It was time to nuke-and-pave!

And I am very glad that I did.   I now have my Surface Pro 3 with the following fully-comprehensive setup for cpp-ethereum development:

  • Windows 10 Pro Insider Edition Build 14361.0 (with Bash-for-Windows)
  • Visual Studio Community 2013 Update 5
  • Visual Studio Community 2015 Update 2
  • Visual Studio Enterprise 15 Preview 2

All at the same time below!

windows10

And just for bonus points, my question of Best means for getting photos OFF Meizu MX4 Ubuntu Edition? now has a great answer.    That device (my main phone for the last few months) has a really flaky USB, which has been failing to show up on my MacBook Air OS X El Capitan almost 100% of the time.

It works a treat on Windows 10 though, I find, which means that I have no excuse for not starting to do some blog posts on OSCON, with photos.

Two great features in this latest Insider Preview too, both of which I plan to take advantage of.    So, good progress in pressing the reset button 🙂

LastPass extension for Microsoft Edge: We are excited to announce that LastPass, a popular free password management extension, is now available for download. Visit our extensions page at the Microsoft Edge Dev website to learn more and try it out for yourself! Be sure to check out the list of known issues for the LastPass extension here.

Introducing Hyper-V Container: You can now use Docker natively on Windows 10 with Hyper-V Containers, to build, ship and run containers utilizing the Windows Server 2016 Technical Preview 5  Nano Server container OS image. A new version of the Docker engine for Windows has also been made available that extends the support of containers while also improving the DockerFile syntax and getting started experience for users. For more details on how to get started with this check out the Windows container documentation or the Windows 10 Getting Started Guide.

 

Repton is alive!

I have just been followed on Twitter by Superior Interactive.   Oh my, my!

Screen Shot 2016-04-20 at 2.38.05 PM

Who are Superior Interactive?   They are the company formerly known as Superior Software, who filled my BBC Micro youth with the joy of such classics as Repton (with a level editor in later versions), Thrust, Bonecrusher and more!

Screen Shot 2016-04-20 at 2.38.14 PM

Wikipedia tells me that Superior was set up by Richard Hanson and John Dyson, who I now discover were graduates of the University of Leeds, just like me.

It is a delight to make your reacquaintance, Superior, even if, as in all likelihood, it was in a completely algorithmic and impersonal manner 🙂

And who can forget “It’s Time To Play Bonecruncher!”