A controversial new open source license designed for use with decentralized applications was recently approved by the Open Source Initiative (OSI). The Cryptographic Autonomy License (CAL) claims to be the first open source license specifically designed to protect end users’ rights and ownership of data and control of their cryptographic keys.

The use of open source software (OSS) for blockchain applications is common, and we addressed some of the associated legal issues in our white paper “10 Things to Know About The Intersection of Blockchain Technology, Open Source Software, and Patents.” The CAL includes many provisions that are commonly found in other open source licenses (e.g., it requires making the source code available for any modifications to the underlying work). However, it also includes a number of unique provisions and many subtle nuances to more common provisions.

We strongly encourage anyone, who wants to use software covered by the CAL, to obtain legal counsel to fully understand the ramifications of this license!

The OSI, which approves licenses that meet its definition of “open source,” struggled with this license during the contentious approval process. Some of the controversy is captured here. After much debate and the resignation of OSI co-founder Bruce Perens, the OSI ultimately approved Holochain’s request for approval of CAL.

The following are some of the more unique aspects of CAL; however, this list is not exhaustive.

License Grant – It is common to grant OSS users a broad license under the Licensor’s intellectual property. However, the CAL grants world-wide, royalty-free, non-exclusive permission to:

a) Take any action with the Work that would infringe the non-patent intellectual property laws of any jurisdiction to which You are subject; and

b) Take any action with the Work that would infringe any patent claims that Licensor can license or becomes able to license, to the extent that those claims are embodied in the Work as distributed by Licensor.

The scope of this grant is curious in that part a) is not limited to granting a license to infringe the non-patent IP of the Licensor – rather, it purports to grant a license to infringe anyone’s IP, anywhere in the world! In contrast, part b) is specifically limited to a license to infringe the Licensor’s patents.

Limitations on the License Grant - The following limitations apply to the license grant:

a) Licensor does not grant any patent license for claims that are only infringed due to modification of the Work as provided by Licensor, or the combination of the Work as provided by Licensor, directly or indirectly, with any other component, including other software or hardware.

Literally construed, does this mean a patent that claims a “processor” programmed with software would not be covered by this license, because it is infringed by a combination of the OSS software with a processor?

Recipients – Many OSS licenses impose conditions on users that are triggered when they distribute the OSS and some have triggers when users make OSS available via a network (e.g., via a SaaS deployment). The CAL defines the term “Recipients” and many conditions are triggered based on this definition. The CAL defines “Recipients” as:

Any non-Affiliate third party to whom you cause the Work, or any portion to be distributed, communicated, made available, or made perceptible (via physical delivery or network connection).

This definition goes well beyond the typical “distribution” or “network access” triggers found in many other OSS licenses. As detailed below, the license also purports to expressly make Recipients third-party beneficiaries and grants them the right to enforce breaches.

Source Code Availability – Some notable aspects of the requirement to make source code available under the CAL are as follows:

• The “Source Code” of the Work means “the form of the Work preferred for making modifications, including any comments, configuration information, documentation, help materials, installation instructions, cryptographic seeds or keys, and any information reasonably necessary for the Recipient to independently compile and use the Source Code and to have full access to the functionality contained in the Work.”

• The CAL requires that you must continue to provide access to the license notices and source code for at least one year after you stop using the software or exercising any permissions granted under the CAL.

Ramifications of Non-Compliance – Lawsuits involving breach of OSS licenses often involve a legal dispute over whether the breach constitutes a copyright infringement or a breach of contract, which may impact the remedies available to the plaintiff. This determination is based on several factors that are evaluated by the Court. According to the CAL:

Any failure to act according to the terms and conditions of this License places Your use of the Work outside the scope of the License and infringes the intellectual property rights of the Licensor.

This provision purports to contractually determine the issue that is within the province of the Court – stating that a breach of any provision in the license constitutes an IP infringement. Whether this is enforceable will be up to a court to decide, but it will likely be challenged.

Enforcement by Recipients – Typically, OSS license breaches are enforced by the Licensor, which is the entity that has granted the license and owns the underlying IP. According to the CAL:

You also agree that either the Licensor or a Recipient (as an intended third-party beneficiary) may enforce the terms and conditions of this License against You via specific performance.

This provision purports to permit entities other than the Licensor (i.e., any other Recipient) to sue licensees to enforce the terms and conditions of the CAL. But whether a third party (not the licensor or licensee) has standing to sue for breach of contract is a legal issue that is determined by the Court. Second, this provision purports to allow for specific performance as a remedy for a breach of the license, but whether this remedy is available is also an issue that is decided by a Court. This provision is also perplexing, given the previous provision that purports to convert a breach of contract into an IP infringement. If interpreted literally, this combination of provisions purports to give the third-party Recipients the right to enforce IP claims for IP that they do not own. Regardless of what is written in the CAL, a party typically cannot enforce IP rights unless it has standing to do so.

Jurisdiction – The CAL includes a number of jurisdictional clauses, including:

• A Licensor may require that any action or suit by a Licensee relating to a Work provided by Licensor under this License may be brought only in the courts of a particular jurisdiction and under the laws of a particular jurisdiction (excluding its conflict-of-law provisions), if Licensor provides conspicuous notice of the particular jurisdiction to all Licensees.

• In the event of infringement, the terms and conditions of this License may be enforced by Licensor under the intellectual property laws of any jurisdiction to which You are subject.

Again, the question of jurisdiction (whether a particular Court has authority to decide a particular case), and which laws will apply in that case, are legal questions for the Court to decide based on multiple factors.

User Data – Some of the more controversial provisions of the CAL relate to user data. The CAL specifies:

• For so long as you use the Software, You must also provide to any Recipient to whom you provide services via the Work, a no-charge copy, provided in a commonly used electronic form, of the Recipient’s User Data in your possession, to the extent that such User Data is available to You for use in conjunction with the Work.

• “User Data” means any data that is an input to or an output from the Work, where the presence of the data is necessary for substantially identical use of the Work in an equivalent context chosen by the Recipient, and where the Recipient has an existing ownership interest, an existing right to possess, or where the data has been generated by, for, or has been assigned to the Recipient.

• You may not, by the use of cryptographic methods applied to anything provided to the Recipient, by possession or control of cryptographic keys, seeds, or hashes, by other technological protection measures, or by any other method, limit a Recipient’s ability to access any functionality present in the Recipient’s independent copy of the Work, or deny a Recipient full control of the Recipient’s User Data.

The CAL purports to require compliance with the right of access to personal information that is mandated by privacy laws such as the General Data Protection Regulation (“GDPR”) and the California Consumer Protection Act (“CCPA”). However, several issues arise from the literal terms. Consider the following:

• The obligation to provide the data is not triggered by a user’s request. The CAL mandates: “You must also provide to any Recipient to whom you provide services via the Work, a no-charge copy, provided in a commonly used electronic form, of the Recipient’s User Data in your possession.” Does this mean if you do not automatically provide the data you are in breach?

• How frequently must the data be provided? The CAL is silent on this.

• Given the definition of “User Data” includes many qualifiers, including some based on ownership and legal rights relating to the data, how does a licensee make these determinations?

Attorneys’ Fees – The CAL includes an attorneys’ fees provision to a “prevailing party” in the event of the need for an enforcement action. According to CAL, the “prevailing party” “is the party that achieves, or avoids, compliance with this License, including through settlement.”

• The CAL purports to award fees to the party who prevails even by way of settlement. Will this be a disincentive for settlement?

• Might we see a cottage industry of Recipients’ attorneys enforcing minor compliance transgressions and seeking attorneys’ fees for doing so?

Conclusion

Many OSS licenses have potentially adverse legal ramifications for users and, unfortunately, include ambiguities and poorly drafted terms. The CAL is no exception. With the growing and ubiquitous use of OSS, and the increasing number of enforcements, it is critical to understand the legal ramifications of using any OSS components. If you are using OSS, it is absolutely a best practice to adopt and implement a comprehensive written OSS policy.