The Legal Principles of the Cryptographic Autonomy License (CAL)
As we wrote last week, we have been working hard on Holochain, as well as a new license that we are calling the “Cryptographic Autonomy License” (or “CAL”). As we have been developing the CAL, we have been thinking about the principles we want to uphold as well as some possible hypothetical situations that help us identify exactly how the license should work. We will talk about these circumstances relative to Holochain and hApps, but we are designing the CAL to apply more broadly than to just our community.
This blog post is going to go into more of the legal details that distinguish the CAL from other open source licenses. We will explain why some of these details are important, and then talk about a few of the legal structures we’re using to maximize user autonomy.
Both End Users and App Creators Need Autonomy
Both Open Source and Free Software licenses include provisions to make sure that recipients of software are granted permissions to use, modify, distribute and redistribute software — the “four freedoms” identified by the Free Software Foundation in the link above. However, history has shown that there are difficult decisions to be made in identifying whose freedoms must be maintained — freedom for immediate downstream developers or the freedoms of end users of the resulting products or services.
Giving access to the source code is really not enough when larger works can be created or when the recipients of the license aren’t developers and their interest in the work is in the use of the application, not the distribution or modification.
The CAL addresses this issue by explicitly dealing with development rights and user rights. Unlike other Open Source Licenses, the CAL makes the use and distribution of the software conditional on providing access to the source code and providing users access to their data and control over the keys that manage that data.
Similarities to the GDPR
You might have heard of the “General Data Protection Regulation” or GDPR. The GDPR is a regulation that applies to all businesses interacting with EU citizens anywhere in the world. It is designed to ensure that users have control over their own privacy — in our language, to increase their autonomy.
One aspect of the GDPR requires companies to provide users with copies of their data. We believe that legal protections of data are simply not enough.
With Holochain we have made user autonomy a central element of the architecture so that applications built on the framework can put the real control of identity and data in the hands of the end user. However, it is still possible for apps to be architected that remove this autonomy.
This is why it is important that the CAL goes beyond GDPR and requires that end users not only have access but also are independently in control of their own identity and data.
In Holochain, this means they have all the necessary tools, including cryptographic keys and seeds, thus ensuring that the creator of the application cannot revoke their access or control their identity.
“Performing” and “Using” the Software
Most Open Source Licenses place conditions on the distribution of the software, either alone or as part of a derived work. When someone runs a distributed application, however, they don’t “distribute” the software, leading to what has been called the “SaaS loophole.” Because the CAL deals with networked applications, we want to make sure that the software source code stays open and available even when it is used to provide a service over the network.
Another license, the Affero Genero Public License (AGPL 3.0), tries to deal with the SaaS loophole by requiring people who offer a “modified version” of AGPL-licensed software to users over a network to also provide access to source code. The AGPL uses a new concept of “network interaction” to condition these rights, however, which doesn’t currently have a basis in intellectual property law.
In contrast, the CAL places conditions on the “use” of the software (under patent law) and the “public performance” of software interfaces (under copyright law). In concrete terms, this has much the same effect as the “network interaction” clause of the AGPL, but ties the conditions included in the CAL to the exact permissions granted under intellectual property law, rather than on a network “interaction” that can be more difficult to classify.
The idea of “publicly performing” the software interface also helps address whether a compatible reimplementation is covered or not. Under the CAL, a compatible reimplementation is still “performing” the same interface, and, as such the creators of that reimplemented work would need to make their source code available under an open source license.
Thus, the CAL works by ensuring that the Holochain framework itself stays open source by using a strong network copyleft license. Unlike the AGPL, however, the license also provides a built-in mechanism for authors to allow elements of the work to be bundled into applications that are licensed commercially. Conceptually, this exception is similar to how the “GPL plus classpath exception” is used for Java, and how the Mozilla Public License v.2 allows for the creation of “Larger Works.”
Enhanced License Compatibility
Another feature of the CAL is that it takes a permissive-as-possible approach to license compatibility. Like other reciprocal licenses, the CAL requires that users have access to the source code, including the source code to derivative works. However, unlike other licenses, the source code to any modifications may be under any open source license that allows programs to be built using code under two different licenses. That means that even though the CAL requires compatible implementations of the API — “public performances” as described above — to be open source, other teams can implement those compatible implementations under different open source licenses.
Enforcing the License
Because the CAL is designed to ensure user autonomy, we want to make sure that users also have the opportunity to enforce the license.
Most open source licenses have the concept that the copyright owner is the only person who can enforce the license.
The CAL allows the copyright owner to enforce the license, but — like the NASA Open Source Agreement — other people who are “intended third party beneficiaries” also have some rights.
In contract law, a “third party beneficiary” is a person who hasn’t signed an agreement, but benefits when other people do things that they said they would do in a contract.
In the CAL, some of those “intended third party beneficiaries” are those who receive copies of the software or use the software to process or store user data via a “public performance” of the software interface over the network. Under the CAL, third party beneficiaries don’t have all the rights that copyright holders do; they can, however, use the courts to make sure that they get their user data as well as the software necessary to control their own identity and interact with their own data.
Looking Ahead to Distributed Applications — and Cryptographic Autonomy
The CAL doesn’t deal with every situation. We can’t force people to provide storage, processing power, or other resources. For example, if someone has a business built on a Holochain application, and they go bankrupt, we can’t force them to stay in business and to keep providing services. But we can make sure that as long as people are participating in Holochain, they won’t be able to hold a user’s data hostage or keep it out of their control.
As we know, the law does not necessarily keep up with the needs of people and the potentials of technology innovations. This is a challenge when creating new licenses that work to maintain a true open use capacity, and where protections are oriented to the end users more than the developer or business community.
One area of concern for us is the use and misuse of cryptographic keys.
It is a tricky problem, and one that we think is essential to how applications will work in the future.
Next Steps and Closing Remarks:
We invite you to review and comment on our draft of the Cryptographic Autonomy License. It will be in an open comment period in GitHub for 30-days, and we look forward to your feedback. We also invite discussion on our Mattermost or Telegram channels.
In the next few weeks we will be exploring how Holo and Holochain are distinct, and we will dive into how Holochain security, works, and how we are implementing that security within Holo. We will continue to provide updates that are geared towards all of our stakeholders. These updates will showcase our business intents, technology, and commitment to communities of developers and change makers. We hope you are enjoying the exploration and journey as well, and we welcome your input and feedback.
Please join us next week in the live streamed Ask Me Anything (AMA) on February 7th at 6pm GMT (1pm EST).
As a reminder, the milestones and releases that will be coming out are:
Promised in February
- Holo Closed Alpha Testnet (not public, only Indiegogo Alpha/Beta backers)
Dates To Be Announced
- HoloPorts Shipped (Indiegogo in 1st batch, HoloPort store in 2nd batch)
- Holo Open Alpha Testnet
- Holo Full Feature Testnet
- Holo Beta Mainnet
Thanks to Arthur Brock & Eric Harris-Braun for laying the groundwork, inspiration and vision, and to Van Lindberg for formulating the legal foundations. Some Rights Reserved.
— Holo Executive Director, Mary Camacho
P.S. You may have noticed that since last week’s post we have changed the name of the license. This was done as we iterated through the contract language and determined that the fundamental distinction between this license and others is the cryptographic control.
