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 of Product and Research and Development at IAB Tech Lab.
Despite the incredible amount of attention that blockchain technology has generated last year, very little has been reported about open-source licensing issues and the associated risks to which developers are confronted when they use ethereum as the base applications.
Many developers may not understand (or deliberately ignore) unique risks when using free software. (These risks are not present in bitcoin, because the bitcoin block chain, unlike the ethereum blockchain, is not a platform on which developers can easily build decentralized applications using open-source code .)
The Ethereum Foundation currently uses a variety of open-source licenses for the various components of the ethereum. To complicate matters, the agency said that it had not yet chosen a final open-source license on which the ethereum core would be available in the future.
For this reason, ethereum-based application developers should identify, understand and address these risks and limitations.
The use of ethereum involves a number of commercial and legal issues, but none is more urgent for an etheric based developer than what is usually a simple question: what are my rights to use ethereum?
The answer, it turns out, is not so simple.
When & # 39; free & # 39; is not free
The Ethereum Foundation promises that ethereum "is both open-source software and free software after the definition of the Free Software Foundation (FLOSS)". In other words, licensees will generally receive broad rights to run, copy, distribute, and improve the software.
Beyond this basic premise, however, things become uncertain.
As any experienced open source software developer knows, "free" software does not mean "unrestricted" or necessarily "free", although it often is. These restrictions, which can disrupt the core business model of a downstream developer, are particularly complicated when it comes to ethereum.
Free software, based on the idea that every software licensee should receive the source code of a program and be able to modify the software for its own purposes, generally fall within the scope of the software. 39, one of two broad categories: "and" restrictive. "
Permissive licenses, which include MIT, BSD, and Apache, contain minimum restrictions and give licensees extensive rights to use and modify the covered software and redistribute the changes on their own. conditions.
For commercial developers, permissive licenses are generally considered safer than restrictive licenses, as they will not alter developments or modifications with the open-source terms of the licensed software .
The MIT license, for example, requires only a copyright notice, a disclaimer, and that the disclaimer and notification be forwarded to any downstream licensee. A developer is free to take software that is licensed under the MIT license and to reclassify any modification or derivative work as part of a standard commercial offer.
Infectious permit
Restrictive type licenses, or "copyleft" licenses, include the Mozilla Public License, the General Public License (GPL), the Minor GPL and the Affero GPL.
Unlike permissive licenses, these licenses limit the ability of a licensee to distribute modifications and derivative works on commercial or non-commercial terms.
Copyleft licenses are also known as "viral licenses" because they can potentially "infect" software with the open-source terms of the underlying copyleft program, leaving a licensee unable to distribute a modified or derived version for a fee or in a form other than the source.
Depending on the copyleft license, there may be ways to use the open-source software in a way that does not infect the overall product, and the mode of the copyleft. Use that triggers the terms of the viral license is often a complicated, fact-specific question.
Thus, the use of open source software, although of great value, involves risk levels that must be analyzed before licensing a product to open source code.
At the highest level of risk, a developer can jeopardize the entire property value of a project.
Conflicting Views
For developers seeking to understand the implications of using ethereum in their businesses, the Ethereum Foundation complicates this already sensitive problem in two ways: first, by leveraging various open-source licenses for different ethereum components; and secondly, remaining undecided about the future system of etheric authorization, especially the heart of the eteum.
According to the Licensing section of page GitHub of the Ethereum the applications will be distributed under GPL, and the middleware will be available as a version of the Affero GPL. Both licenses are restrictive and thus limit the ability of a licensee to renew a license for changes or developments on commercial terms.
However, they differ in the definition of "distribution" that triggers the viral restrictions in each license. The difficulty of Affero is that remote interaction via the web is sufficient to trigger the obligation for an Affero dealer to generally make available the source code of his own developments and modifications.
In other words, a licensee of a software product covered by Affero may wish to make changes or improvements to the underlying software and make this enhanced product available as software- service, but in this case, the source code of the entire derived work must be made available to users who interact with it. Obviously, this requirement is often prohibitive for a developer wishing to retain the proprietary value of the product.
The Ethereum Foundation explains that ethereum "is distributed under several licenses" in part "to reflect the different thinking of the minds behind different software."
These conflicting views are also apparent in that the Ethereum Foundation states that it did not select a final license for the ethereum core, which includes the consensus engine, the networking code and support libraries.
Unresolved Questions
Although the Ethereum Foundation states that "the nucleus of the ethereum will be released under the most liberal license", it cites the MIT license, Mozilla Public License and LGPL as the top three candidates – the last two being in copyleft reality in nature (although generally considered "low copyleft" licenses).
The goal, according to the foundation, is to make the core "available for use in any commercial, closed or open environment."
To complicate matters, cpp-ethereum, which contains all the basic ethereum libraries, currently appears to be under GPL license.
Not only is this inconsistent with the foundation's indication that definitive basic licenses are undetermined, but it's not even among the options listed by the foundation for review. The GPL is neither a permissive license nor a "weak copyleft" license. On the contrary, it contains important restrictions on downstream modification and redistribution.
The current use of a strong copyleft license and the apparent uncertainty as to the final licensing regime pose potentially significant risks to developers.
Until the final license is determined, ethereum-based application developers are subject to changes or divisions in the ethereum licensing philosophy – a philosophy that the Foundation Ethereum admits freely already contains cleavages between different stakeholders.
Walking carefully
None of this means that developers should not use ethereum or that the Ethereum Foundation is doing something wrong with its approach.
On the contrary, commercial developers must understand the complications of open-source licensing and unique wrinkles in the context of the ethereum.
The disadvantage of underestimating or misjudging the risks is far too great.
Image of the Coder monument via Shutterstock
Leader in blockchain news, CoinDesk strives to provide an open platform for dialogue and discussion on all blockchain topics by encouraging contributing articles. As such, the opinions expressed in this article are those of the author and do not necessarily reflect the opinion of CoinDesk
For further details on how to submit a Article of opinion or analysis, consult our Editorial Guide or email news@coindesk.com.