TL;DR
- The codebase of the Tezos blockchain evolves with the incorporation of amendments that successfully run through its on-chain governance mechanism.
- As Tezos is licensed under the permissive MIT Open Source License this poses the risk of license violation since the code of injected amendment proposals may contain software pieces that are not allowed to be used and redistributed in permissively licensed software.
- Liability questions remain unresolved.
- We propose the mandatory use of a DCO and an SPDX file that are checked upon submittance.
The Tezos blockchain has the ability to evolve with technological developments through an on-chain governance mechanism : Amendment proposals can be brought forward by injecting the source code that would implement the amendment (and registering a content hash of that code).
If the proposal successfully runs through the whole amendment process (Proposal Period, Exploration Vote Period, Testing Period and Promotion Vote Period), the proposed amendment gets activated and becomes part of the software constituting Tezos .
This is a true asset as it makes Tezos future proof and fosters the spirit of a truly decentralized open source community ! However, there is a risk of this asset to become a liability that beats Tezos at its own game (maliciously or unintentionally):
Tezos is licensed with the MIT Open Source License a so-called permissive open source license. As depicted in Figure 1, permissively licensed software can be reused in any other software, regardless of that software’s license type. This is where the license type earns its name: it permits any other software to use it freely.
However, the name permissive can be a bit misleading when considering what kind of software dependencies are allowed to be used in permissively licensed software: in this respect, permissively licensed software is rather restrictive (which is not the permissive license’s “fault” but rather that of the restrictions on reuse imposed by other types of licenses).
Figure 1: Classification of open and closed source software licenses and their respective forward and backward compatibilities with other license types. Source: https://softdev4research.github.io/4OSS-lesson/03-use-license/index.html
Now a modern piece of software is increasingly complex and builds upon existing and well-tested libraries as much as possible. In general, this is a good thing: reuse eliminates waste and is thus more efficient and software that has been excessively tested and used in other contexts is less likely to contain bugs or behave in an unintended way .
But there’s a catch: if software dependencies are used whose licenses are not compatible with the software using them (whether that happened intentionally or unintentionally), a lawsuit might entail.
In the case of Tezos – assuming the current codebase is “clean” in terms of license violations – the danger of “bad egg software dependencies” (i.e. dependencies that are not allowed under the MIT license) entering the codebase stems from the “uncontrolled” development and injection of amendment proposals as illustrated by Figure 2.
Figure 2: How “bad egg software dependencies” could enter the Tezos codebase.
As Tezos is a decentralized network , there is no one governing body or legal entity that is liable for the code, but we imagine that plaintiffs and courts would find something to assert their rights/let justice rule.
We are no lawyers (or legal experts in any matter), so for the lawyers out there – who would be endangered by a license violation? :
- We believe it is indisputable that the legal or natural person who developed the amendment’s code would be susceptible to a lawsuit!?
- Could the bakers operating the network and adopting the new codebase with activation of the amendment be seen as some kind of “client” to the developer , i.e. in some way liable for using and/or redistributing the third-party code?
- It does neither own the network nor the codebase and is not a central governing body, but could the Tezos Foundation be a “handy” candidate to target liability at and would there be any legal basis for that?
- Does using the Tezos blockchain and thus its codebase, i.e. interacting with it in any way (e.g. as a third-party application via API), constitute a license violation that opens the third-party up for a lawsuit? Does is make a difference if the third-party knew about the license violations at the time of use?
Regardless of the answers to these questions, we think the Tezos community should do everything in their power to prevent license violations in the first place . Of course, that starts with the careful and responsible use of software dependencies by any development team. However, all humans make errors and just appealing to development teams won’t prevent possible malicious actors from intentionally hiding a “bad egg” in an otherwise sound amendment proposal that stands a real chance of getting promoted.
A second measure that would mitigate the risk but not solve the problem altogether, is for the community to increase awareness for the topic in general and consciously incorporate checking of license issues in their activities when evaluating the published source code of an amendment proposal.
Maybe blockchain-based license management could be an option for the future. But for now, we believe the combination of two measures could provide an acceptable protection from license violations and entailing legal uncertainties:
-
Demanding that any proposal contains a Developer Certificate of Origin (DCO) as depicted in Figure 3 and denying the acceptance of any proposal lacking a DCO.
-
Using a “classical” software tool to check included dependencies prior to even accepting a proposal to the Proposal Period may be a technologically safe solution. This may require demanding the inclusion of a Software Package Data Exchange (SPDX) file in any proposal and denying the acceptance of proposals lacking such a file.
Figure 3: Example of a Developer Certificate of Origin. Source: https://elinux.org/Developer_Certificate_Of_Origin
These measures and among them especially the second one, would in turn limit developers’ possibilities, but we think it’s a reasonable proposal and to the best of our knowledge already considered a “best practice” – what’s your take on the subject? Especially lawyers: How do you evaluate SPDX as an option? …and the community at large: How could these measures efficiently be integrated into the existing process?
This work has been published by the work order of BMW AG and been contributed to the open source ecosystem through the ASC(S e.V. ENVITED Working Group with the goal of enabling virtually enhanced homologation processes.
