Matt Savare and John Wintermute work at Lowenstein Sandler LLP, where they practice intellectual property, digital advertising, technology, blockchain and privacy law. Shailley Singh is the senior director for product and R&D at IAB Tech Lab.
Despite the incredible amount of attention blockchain technology has garnered in the last year, very little has been reported on the open-source licensing issues and related risks developers face when using ethereum as a foundation for their own applications.
Many developers may not understand (or willfully ignore) the unique risks when utilizing open-source software. (These risks are not present in bitcoin, because the bitcoin blockchain, unlike the ethereum blockchain, is not a platform upon which developers can easily create decentralized applications using open-source code.)
The Ethereum Foundation currently utilizes a variety of open-source licenses for ethereum’s different components. To make matters more complicated, the body has indicated that it has not yet selected a final open-source license on which the core of ethereum will be made available in the future.
For this reason, developers of ethereum-based applications should identify, understand and address these risks and limitations.
Utilization of ethereum involves a number of business and legal issues, but perhaps none are more pressing for an ethereum-based app developer than what is usually a straightforward question: what are my rights to use ethereum?
The answer, it turns out, is not so simple.
When ‘free’ isn’t free
The Ethereum Foundation promises that ethereum “is both open-source software and Free software after the definition of the Free Software Foundation (so-called FLOSS).” In other words, licensees will generally receive broad rights to run, copy, distribute and improve the software.
Beyond this basic premise, however, things get uncertain.
As any seasoned open-source software developer knows, “free” software does not mean “free of restriction,” neither does it necessarily mean “free of cost,” though it often is. Those restrictions, which can disrupt the core of a downstream developer’s business model, are particularly complicated when it comes to ethereum.
Open-source software, which is premised upon the notion that every software licensee should receive a program’s source code and the ability to modify the software for its own purposes, generally falls into one of two broad categories: “permissive” and “restrictive.”
Permissive-type licenses, which include MIT, BSD and Apache, contain minimal restrictions and grant broad rights to licensees to use and modify the covered software and to re-distribute the modifications on the licensee’s own preferred terms.
For commercial developers, permissive licenses are generally considered safer than restrictive licenses, because they do not run the risk of “tainting” any developments or modifications with the open-source terms of the in-licensed software.
The MIT License, for instance, requires only a copyright notice, a disclaimer, and that the disclaimer and notice be passed along to any downstream licensees. A developer is free to take software that is licensed pursuant to the MIT License and to re-license any modifications or derivative works as part of a standard commercial offering.
Infectious licenses
Restrictive-type licenses, or “copyleft” licenses, include the Mozilla Public License, General Public License (GPL), Lesser GPL and Affero GPL.
In contrast to permissive licenses, these licenses restrict a licensee’s ability to distribute modifications and derivative works under commercial or non-open-source terms.
Copyleft licenses are also called “viral licenses,” because they may potentially “infect” a software product with the open-source terms of the underlying copyleft program, leaving a licensee unable to distribute a modified or derivative version for a fee or in non-source form.
Depending on the copyleft license, there may be ways to utilize the open-source software in a way that does not infect the overall product, and the manner of use that will trigger the terms of the viral license is often a complicated and fact-specific question.
Thus, the use of open-source software, while tremendously valuable, carries levels of risk that must be parsed before in-licensing any open-source product.
At the highest level of risk, a developer may jeopardize the entire proprietary value of a project.
Conflicting views
For developers seeking to understand the implications of licensing ethereum for use in their businesses, the Ethereum Foundation complicates this already sensitive issue in two ways: first, by leveraging a variety of open-source licenses for ethereum’s various components; and second, by remaining indecisive as to the future licensing scheme of ethereum, particularly the ethereum core.
According to the licensing section of ethereum’s GitHub page, applications will be distributed under GPL, and the middleware will be made available under a version of the Affero GPL. Both licenses are restrictive in nature, and therefore limit a licensee’s ability to re-license modifications or developments on commercial terms.
They differ, however, in the definition of “distribution” that triggers the viral restrictions in each license. Affero’s wrinkle is that remote interaction via the web is sufficient to trigger a requirement that an Affero licensee make generally available the source code of its own developments and modifications.
In other words, a licensee of an Affero-covered software product might wish to make modifications or improvements to the underlying software and to make that improved product available as software-as-a-service, but in that case, the source code of the entire derivative work must be made available to users interacting with it. Obviously, this requirement is often prohibitive for a developer wishing to retain the product’s proprietary value.
The Ethereum Foundation explains that ethereum “is distributed under several licenses” in part “to reflect the different thinking of the minds behind different pieces of software.”
These conflicting views are also apparent in that the Ethereum Foundation indicates that it has not selected a final license for the core of ethereum, which includes the consensus engine, the networking code and supporting libraries.
Unresolved questions
Although the Ethereum Foundation states that the “core of ethereum will be released under the most liberal of licenses,” it cites the MIT License, Mozilla Public License and LGPL as the three leading candidates – the latter two of which are actually copyleft in nature (albeit generally considered to be “weak copyleft” licenses).
The goal, according to the foundation, is to make the core “available for use in any commercial environment, closed or open source.”
To make matters more complicated, cpp-ethereum, which contains all of ethereum’s core libraries, appears to be currently licensed under the GPL.
Not only does this conflict with the foundation’s indication that the final core licenses are undetermined, but it is not even among the options listed by the foundation for consideration. The GPL is neither a permissive license nor a “weak copyleft” one. Rather, it contains significant restrictions on downstream modification and redistribution.
The current utilization of a strong copyleft license and the apparent uncertainty as to the final licensing scheme pose potentially material risks for developers.
Until the final license is determined, developers of ethereum-based applications are subject to any shifts or divisions in the philosophy behind the licensing of ethereum – a philosophy the Ethereum Foundation freely admits already contains rifts among the various stakeholders.
Tread carefully
None of this is to say that developers should not utilize ethereum or that the Ethereum Foundation is doing anything wrong in its approach.
Rather, commercial developers need to understand the complications of open-source licensing and the unique wrinkles in the context of ethereum.
The downside of underestimating or misjudging the risks is far too great.
Coder’s monument image via Shutterstock