Road to Success

Before looking closer at Ethereum, here is a summary of OSS considerations:

• OSS is software licensed with:
  • its source code included; and
  • the right to modify and distribute the software.
• Software developers typically have two key concerns regarding using OSS:
• its level of security (given that OSS source code is widely available); and
• whether it is restrictive, copyleft or “viral” OSS.
• Whether OSS is permissive or restrictive depends on its terms:
  • Permissive OSS licences permit a licensee to freely change OSS code and combine OSS code with other software code (a “derivative software”) without placing restrictions (or any significant restrictions) on the derivative software and how it may be subsequently licensed.
  • Restrictive, or copyleft, OSS licences impose licensing restrictions to both using the original OSS code and any derivative software. Developers of derivative software subject to restrictive or copyleft OSS provisions must allow anyone to view and use the source code of derivative software under the licensing terms governing the OSS used to create the derivative software. Copyleft licences are therefore sometimes called “viral OSS” because they have the potential to infect any new code developed, which could restrict the basis on which the new code can be distributed. For this reason, developers and tech companies may prefer avoiding restrictive OSS and therefore having to expose any part of its source code and risk any competitive or proprietary edge.
  • “Weak copyleft” OSS licences permit, to varying degrees, use in derivative software without triggering copyleft obligations. It may, however, be difficult to definitively say whether derivative software will avoid triggering copyleft obligations, particularly if the relevant OSS licence terms leave matters open to interpretation.

Ultimately, developers must understand the type of OSS code they are working with, and carefully review the relevant OSS terms on a case-by-case basis. This becomes particularly critical if the value of derivative software depends on the proprietary nature of the code.

Why would blockchain software developers want to use OSS code? As is the case with any software development (not just for blockchain software), some of the advantages include:

• the lower development costs of using already available and accepted building blocks, which frees up valuable development resources for proprietary developments;
• improved competition, as competitors are likely to also be using the same OSS code; and
• reduced logistical and marketing costs, as OSS is often more reliable from being subjected to constant technical peer review by many developers, including in the case of Ethereum.

The risks of using OSS must also be considered alongside any advantages:

• viral OSS risks, as described above – namely, having to expose proprietary and confidentially developed software due to copyleft obligations;
• OSS risks are commonly flagged during transaction due diligence, potentially raising obstacles or delay with seeking investment or satisfying warranties. Investors may insist on not using any OSS. It can be difficult to assuage concerns even over weak copyleft or permissive OSS due to often broadly drafted licence terms; and
• in commercial arrangements, software vendors may be asked to warrant that their solution involves no restrictive OSS. Customers may not want the legal risk of failing to adhere to OSS licence obligations affecting distribution, which could lead to the licensor bringing a copyright infringement claim and seeking remedial action including monetary damages and injunctions, as well as being forced to expose derivative software source code.

Blockchain technologies are incredibly valuable and have the potential to support ground-breaking use cases. Developers and customers alike must equally be aware of the risks and obligations that may come with utilising blockchain offerings coded using OSS and the licence terms that govern them.