← Process Mechanics

The Cryptographic Autonomy License

By VanL Tags: Open Source, Patents, Copyright

I want to introduce the Cryptographic Autonomy License. (PDF Link) (NB: The CAL is currently at version 1.0-Beta. As the CAL is still open for revision, this link will be periodically updated to reflect the current "canonical" version of the license.) The Cryptographic Autonomy License, or CAL, is a new strong "network" copyleft license especially appropriate for distributed systems. The CAL has not yet been certified as open source. It will be submitted to the Open Source Initiative for approval after the conclusion of the public comment period.

Warning: This post is long and assumes a high level of familiarity with the intricacies around open source law. If that doesn't sound exciting, this may not be the post for you. ☺

Why a new license?

I have become increasingly interested in reciprocal licenses. I'm not the only one. There have efforts to create new strong copyleft licenses, such as the Parity Public License and the Server Side Public License. Nevertheless, none of these new proposed licenses has as yet been accepted as open source by the open source initiative.

Clearly there is a desire for stronger reciprocal licenses. And while I personally tend to use more permissive licenses, copyleft has a place in helping preserve software freedom, which I consider important.

Thus I was excited when Holo contacted me and described their need for a strong network copyleft license for Holochain, and engaged me to work with them drafting it.

Key Principles

When considering the structure of what eventually became the CAL, there were a couple of key principles we used when drafting.[1]

  1. The CAL must comply with the Open Source Definition—including in spirit.

The Open Source Definition (OSD) is valuable from both a legal and community-building perspective. Legally, OSD-compliant licenses have clear boundaries that encourage understanding between licensors and licensees.

But open source licenses are even more important as community-building tools. As I have written before:

Open source licenses are always about communities. You pick a community by picking a license. The license isn't just a legal document—it ends up being part of a social compact between participants in the community.

This community aspect is the most important aspect of the CAL. The CAL is agnostic as to particular business models. It meets Holo's needs, but it is not specific to Holo. It has no special rules for original contributors. It can be used for inbound == outbound licensing. It may not be for everyone, but it is fair.

  1. The CAL should be primarily structured as a license.

As much as possible, the effects of the license are expressed in terms of either a grant of permissions or a applicable-to-all-parties condition on the grants.

Not every part of the license can be structured this way. But anything not structured as a grant or a condition should be able to be struck from the license by a court without affecting enforceability.

Further, grants and conditions can be automatically applied. There is no need for offer and acceptance. Just in case, however, the CAL also has language expressing the terms as a unilateral offer with acceptance by action. But that is a hopefully-redundant measure.[2]

  1. The CAL should make use of all available reserved rights.

Most open source licenses primarily focus on the reserved rights under copyright. The CAL also addresses the reserved rights under patent law.[3]

This is because copyright rights automatically vest in newly-written software. But software can also be patentable. The OSD also implicates patent rights. But even licenses that include a patent grant do not generally condition making, using, and selling the work on granting the same permissions to others. The CAL does.

It is true that provisions that rely on patent-exclusive rights require that the licensor register for and be granted a patent in order to be enforce those provisions. However, this requirement is not substantially different from enforcement under copyright law. The Supreme Court recently decided in Fourth Estate Public Benefit Corp. v. Wall-Street.com LLC[4] that registration is required before an enforcer can sue for copyright infringement as well. Just like a patent application, an application for copyright registration undergoes an examination process to determine if the work is eligible for protection. A registration certificate issues if the work meets the requirements. Thus, both copyright and patent law require registration and examination before enforcement.

Even in a situation in which a licensor does not have a patent, it is ordinary practice to restrict software functionality on the basis of copyright rights. The functional and expressive aspects of software are so interrelated that copying expression is very hard to avoid using the "patent" verbs (e.g., make, use, sell, and offer to sell) when exercising rights under copyright. Thus, the use of patent verbs makes the application and of the license consistent regardless of whether the licensor has a patent.

Second, even when considering just copyright, most open source licenses don't address the full spectrum of reserved rights. In particular, the copyright grants authors the exclusive rights to publicly perform and display works. "Public performance" has not been well-defined with regard to software, but it is a recognized right under copyright that appears to apply. The CAL provides a definition of public performance for software and uses it to trigger copyleft provisions.

Breaking Down the CAL

The CAL is designed to be read from top to bottom, but it includes a number of interrelated concepts that appear in many sections. Defined terms are Capitalized. Even though the Definitions are near the bottom (in Section 6), the terms were chosen so that they would read intelligibly in context. In the description below, regular links in each paragraph are to sections in this document; italicized links with arrows (⭷) are to the associated part of the CAL. Reading from the top down:

What is the “Work”?

Watching the debate over the SSPL heightened my concern regarding the interaction of copyleft-style requirements as they relate to OSD element 9, that the "License Must Not Restrict Other Software." I am also sensitized to the possibility of misuse-based defenses.[5] Misuse defenses and OSD 9 compliance issues share a common theme: using one work to control the licensing of another.

One way to address these concerns is by focusing on IP permissions and conditions as discussed above. The conditions in the CAL only discuss the "Work" itself, and the exercise of exclusive rights relative to the Work. Obeying this rule sidesteps the misuse and OSD-related concerns.

So what is the "Work"? Somewhat circularly, the CAL defines the Work ⭷ as anything a licensor may use IP rights to protect. That ties the license to the full scope of copyright and patent law. It also helpfully excludes the "restrict[ion of] other software" as required by OSD 9. Thus the CAL protects the Work as fully as possible under IP law, but no further. The CAL also includes an interpretive clause (CAL § 7.1.2 ⭷)) making that clear.

This definition of the "Work" has a number of nuances. It is strictly more expansive than the normal copyright-based definition of works, because it also includes patentable functionality. Technically, the functional elements of software are not (or should not be) subject to copyright protection. They are just "along for the ride," so to speak. But the CAL's definition of the Work extends to all protectable elements of the work, including those that may be protectable solely under patent (or database) protection laws. In fact, this definition results in "maximal copyleft" as described by McCoy Smith in his CopyleftConf 2019 presentation: If some aspect of the work can be subject to the CAL, then it is.

A second implication is that the Work includes APIs and interfaces. This is for two reasons. First, there are many patents that directly reference or claim APIs. More controversially, the core issue in Oracle v. Google is the protection of the Java APIs through copyright. Regardless of a person's policy preferences, APIs are logically covered under patent law, copyright law, or both. Thus the API is part of the Work, so conditions on the use or reimplementation of the API are consistent with only applying the CAL to the Work itself.

Copyleft and the Public Performance of Software

A unique element in the CAL (and in software licensing generally) is the use of the reserved rights of "public performance" and "public display" as licensing hooks. This is the core of the "network" aspect of the CAL, so it requires further explanation.

First, the statutory authority for using public performance and public display comes from 17 U.S.C. § 106:

Subject to sections 107 through 122, the owner of copyright under this title has the exclusive rights to do and to authorize any of the following:

    1. to reproduce the copyrighted work in copies or phonorecords;

    2. to prepare derivative works based upon the copyrighted work;

    3. to distribute copies or phonorecords of the copyrighted work to the public by sale or other transfer of ownership, or by rental, lease, or lending;

    4. in the case of literary, musical, dramatic, and choreographic works, pantomimes, and motion pictures and other audiovisual works, to perform the copyrighted work publicly;

    5. in the case of literary, musical, dramatic, and choreographic works, pantomimes, and pictorial, graphic, or sculptural works, including the individual images of a motion picture or other audiovisual work, to display the copyrighted work publicly; and

    6. in the case of sound recordings, to perform the copyrighted work publicly by means of a digital audio transmission.*

(Bold emphasis added.) Software is defined as a literary work, so the rights apply as by statute. But what exactly is "public performance"? It is not distribution or reproduction, because it doesn't result in a new fixation of the work. Instead, it is the making of a work perceptible by the public that results in public display or performance. As per 17 U.S.C. § 101:

To perform or display a work “publicly” means—

[. . .]

(2) to transmit or otherwise communicate a performance or display of the work to a place specified by clause (1) or to the public, by means of any device or process, whether the members of the public capable of receiving the performance or display receive it in the same place or in separate places and at the same time or at different times.

As the World Wide Web was just taking off, President Clinton convened a group to discuss issues related to the United States' "National Information Infrastructure."[6] One of the topics discussed was the application of network technologies to intellectual property, including the public performance right. As Bruce Lehman wrote in the intellectual property task force report:

A distinction must be made between transmissions of copies of works and transmissions of performances or displays of works. When a copy of a work is transmitted over wires, fiber optics, satellite signals or other modes in digital form so that it may be captured in a user’s computer without the capability of simultaneous “rendering” or “showing,” it has rather clearly not been performed. Thus, for example, a file comprising the digitized version of a motion picture might be transferred from a copyright owner to an end user via the Internet without the public performance right being implicated. When, however, the motion picture is “rendered”—by showing its images in sequence—so that users with the requisite hardware and software might watch it with or without copying the performance, then, under the current law, a “performance” has occurred.[7]

In the context of network-capable software, especially distributed systems, certain elements of the interaction over a network would appear to conform with this definition. For example, a database that makes its API available over the network would apply. The software itself is part of a "performable" literary work, and the API is part of the Work. The element of the API are transmitted to various people at various times (including possibly to the "public"), but they are not used to recreate a "copy" of the work. Rather, they are used to make the work "perceptible"—usable—from a distance.

Thus, the right of public performance appears to apply to software. But because this is a novel legal theory—for software at least—I added a definition of "Public Performance" designed to capture this concept in the CAL directly. The definition is at CAL § 6(m) ⭷:

“Public Performance” (or “Publicly Performing”) means using the Software to take any action that implicates the rights of public performance or public display of a work under copyright law, specifically including making aspects of the Software, including any interfaces used for access to or manipulation of User Data, directly or indirectly available to the public.

The concept of public performance is also implicated in the definition of a "Recipient" of the work. (CAL § 6(n) ⭷) Providing the software to a Recipient requires compliance. A Recipient is defined as:

“Recipient” means any non-Affiliate third party receiving either the Software or a Public Performance of any interface thereof from You.

Maintaining User Autonomy

A second novel aspect of the CAL relates to maintaining user autonomy. At a high level, this concept is a direct descendant of the concept of user freedom from the Free Software Definition. As Richard Stallman wrote:

The freedom to run the program means the freedom for any kind of person or organization to use it on any kind of computer system, for any kind of overall job and purpose, without being required to communicate about it with the developer or any other specific entity. In this freedom, it is the user's purpose that matters, not the developer's purpose; you as a user are free to run the program for your purposes, and if you distribute it to someone else, she is then free to run it for her purposes, but you are not entitled to impose your purposes on her.[8](emphasis added)

Free software is about "user freedom," not "developer freedom." But from a practical perspective, providing users access to source code and the permission to use and modify that code is frequently not enough. Users also need access to their data. This is especially so for SaaS applications: Users may technically "own" the data provided to the SaaS provider, but it is hard to exercise their rights to that data when it is in someone else's hands. The CAL conditions use of the Work on providing access to both the source code and the user's data through the use of several interlocking definitions and clauses.

Definitions: User Data, “Processing” User Data, and Lawful Interests

The first question relates to scope. What is the "User Data"? How is the Software connected to the User Data? Those questions are answered in CAL § 6(q) ⭷ ("User Data") and CAL § 6(l) ⭷ ("Process User Data"), which read:

“User Data” means any data that is either a) an input to, or b) an output from, the Work or a Modified Work, in which a third party other than the Licensee has a Lawful Interest in the data.

“Process User Data” (or “Processing User Data”) means 1) use a system, 2) perform a method, or 3) induce any other party to use a system or perform a method, using at least in part Software provided under this License, where User Data is an input or an output to the system or method.

User Data is a deliberately broad term. It can encompass both copyrightable and non-copyrightable information, so long as it flows into or out of the licensed Software. "Processing" User Data means taking an action that would implicate patent rights in interacting with the User Data. But note the restriction: the definition of "User Data" only pertains to third party data. It excludes the Licensee's own data. The CAL does not attempt to control what a licensee does with their own data. Indeed, it could not do so and be compliant with OSD 9.

But even excluding the Licensee's own data, there is still an effect on other works—the third party User Data. How does this still comply with OSD 9?

The answer is that the CAL only specifies a negative condition: "You must refrain from using the permissions given under this License to interfere with any third party’s Lawful Interest in their own User Data" (CAL § 2.3 ⭷, emphasis added). Declining to extend granted permissions in ways that would hurt users is exactly analogous to the statement in the GPL that "To protect your rights, we need to make restrictions that forbid anyone to deny you these rights or to ask you to surrender the rights."[9] You can't use the Work to deny others their rights in their own information.

Scoping User Data: Lawful Interest

There is a second scoping issue: It does not make sense to allow any Recipient to access just any User Data. Logically, it should be limited to that User's own Data. But simply asserting "ownership" is not complete enough. For example, I may legally own a copy of a song, but I don't own the song.

Dealing with this issue is the subject of the term "Lawful Interest." Lawful Interest is defined in CAL § 6(e) ⭷, which reads:

“Lawful Interest” means either 1) an ownership interest, 2), a non-ownership property or possessory interest, including but not limited to lawful possession.

The key here is the incorporation of the concept of a "possessory interest," borrowed from (real) property law. Nolo’s Plain-English Law Dictionary defines Possessory Interest as:

In real estate, the right of a person to occupy and/or exercise control over a particular plot of land; distinguished from an ownership interest. For example, a tenant with a long term lease has a possessory interest, but not an ownership interest.[10]

Any Recipient's enforceable rights in their User Data are limited to getting copies of information that they have a legal right to possess.

User Autonomy: Specific Conditions

There are five separate clauses preventing particular attacks on User Autonomy, all included in CAL § 2.3) ⭷. They are:

(a) You may not, by means of cryptographic controls, technological protection measures, or any other method, limit a third party from independently Processing User Data in which they have a Lawful Interest.

This is the most general clause of the five: You can't use the work to inhibit a User's freedom to work with their own data. This is designed to be as broad as possible, and makes reference to both technical ("cryptographic controls") and legal methods ("technological protection measures" of inhibiting user freedom.

(b) During the same period in which You exercise any of the permissions granted to You under this License, You must also provide to any third party with which you have an enforceable legal agreement, a no-charge copy, provided in a commonly used electronic form, of the User Data in your possession in which that third party has a Lawful Interest.

This clause places an affirmative duty on Licensees to make a copy of a User's Data available to that User. Conveniently, anyone interacting with the Software is likely also a Recipient of the Work as defined by the CAL. Thus, this provision applies to essentially the same group that is owed a copy of the source code.

There are a couple of caveats included so as to make this commercially practicable. First, this requirement is only active while a Licensee is exercising the permissions granted. If someone stops using the Software, this requirement also stops applying. Similarly, Licensees must only provide copies of User Data to those with whom they have "an enforceable legal agreement." This is to prevent this User-Data-Download requirement from persisting into the future, even after a user has stopped using a particular SaaS offering.

(c) You may not use the Software to control any cryptographic keys, seeds, or hashes pertaining to third parties where such control would prevent the third party from independently exercising the permissions granted under this License.

The exclusion of cryptographic controls is broader than just encryption. This is one of the ways in which Holo's perspective was vital to the drafting of the CAL. Holochain-based applications use cryptographic keys as core elements protecting and representing a user's identity within the system. In Holochain, controlling someone's key means that you control their data and their identity.

This provision may not apply to everyone right now. But the founders of Holo believe that user-centric, distributed systems are the future. Those systems will necessarily use cryptographic primitives to mediate access to the system. The CAL was designed, in part, to be ready for that future.

(d) You waive any legal power to forbid circumvention of technical protection measures that include use of the Work; and
(e) You disclaim any intention to limit operation or modification of the Work as a means of enforcing the legal rights of third parties against Recipients.

These clauses are modeled after the GNU GPL version 3, section 3, and serve the same purpose.

User Autonomy and OSD 6

One possible concern with the CAL is compliance with OSD 6, "No Discrimination Against Fields of Endeavor." But compare with section 3 of the GNU GPLv3. There is no prohibition on particular business models, fields of use, or geographies. Licensees can form any sort of business that they would like with the software. They just can't lock their users in and deny them their freedom. Or as the CAL would say it, their autonomy.

Other Concepts and Provisions

Most elements of the CAL will be familiar to open source licensing practitioners, and those interested should read the entire license. Below I'll emphasize a the elements that are uncommon or new. The listing is in alphabetical order.

Applicable Jurisdiction

For some organizations, it is important that they have some control over where they can be brought into court. The CAL provides licensors the opportunity to declare an "Applicable Jurisdiction." This is done by just providing notice to licensees at the top of the file, by stating:

“The Applicable Jurisdiction for disputes arising from the licensing or use of this Work is _____.”

Application by Reference

Similar to the OSL and the UPL, the CAL allows licensing by reference. The entire text of the license does not have to be incorporated into source files. This streamlines common usage and matches what many developers do anyway. The CAL is versioned so that there is no ambiguity what terms are contemplated.

The “Combined Work Exception”

The header makes clear that one of the ways in which a licensor can apply the CAL is with reference to a "Combined Work Exception." The Combined Work Exception is a built-in optional clause that turns the CAL into a kind of Affero LGPL—reciprocally licensed, but combinable with other works into a larger program licensable as a whole under different terms. It is similar to the Classpath Exception or the LGPL, but built-in to the core license. All that needs to be done to invoke it is to label the Work appropriately.

The text of the Combined Work Exception is found in the CAL § 2.4 ⭷:

As an exception to the conditions in sections 2.2.1 and 2.2.2, any Source Code marked by the Licensor as having the “Combined Work Exception,” or any Object Code created from Source Code so marked, may be combined with other Software into a larger work, and the resulting larger work may be used, distributed, or sold under any other license, so long as You: a) comply with the notice conditions of section 2.1; b) comply with the distribution conditions of 2.2.1 and 2.2.2, relative to the Source Code provided to You; and c) comply with section 2.3.

The Combined Work Exception can either have a "file" scope, like the MPL, or a "library" scope, like the LGPL. It depends on how the Work itself is marked.

Compatible Open Source Licenses

Most reciprocal licenses enforce reciprocality by requiring that any derivative works be licensed under the same license that they received. Using the same license is allowed under the CAL (and must be under OSD 3). But the CAL also allows those who create Modified Works to distribute their modifications under any "Compatible Open Source License." Compatible Open Source Licenses are defined as follows:

“Compatible Open Source License” means an Open Source License that allows Object Code to be distributed that is created using both Source Code provided under this License and Source Code provided under the Open Source License.

This allows modifications to be placed under most permissive licenses and some weak reciprocal licenses. Unfortunately, the GPL and AGPL are incompatible, because the GPL family of licenses are among those that require licensing of derivative works under "this" license. I would hope that should the CAL be approved, that at least the AGPLv3 and GPLv3 might designate the CAL as compatible.

This "Compatible" provision is particularly important for reimplementation of APIs. Under the CAL, a reimplementation of an API is a derivative work. But the reimplementation can have a completely separate license, as long as it is compatible.

Recipient

The Recipient is defined as follows:

“Recipient” means any non-Affiliate third party receiving either the Software or a Public Performance of any interface thereof from You.

There are two elements of note in this definition. First, there is occasionally confusion as to whether sending to software a co-owned corporation is a distribution of the software. The CAL incorporates a common definition of "Affiliate" (CAL § 6(b) ⭷) to resolve this question (in the negative). Second, a Recipient is someone who perceives a Public Performance as described above.

Comments Welcome

The CAL has been designed as well as I know how, but that doesn't mean that there aren't areas in which it could be improved. Comments and criticisms would be gladly received. Just click the envelope above.

Acknowledgments

Finally, thanks: The CAL is an original work, but has elements inspired by the following licenses (in alphabetical order): AGPL 3.0, Apache 2.0, the GNU GPL (both v2 and v3), MPL 2.0, the NASA Open Source Agreement v1.3, OSL 3.0, the Parity Public License, and the UPL. Special thanks also go out to Kyle Mitchell, Simon Phipps and Jim Wright for valuable suggestions during drafting.

  1. While every effort was made to properly internationalize the CAL, the primary legal analysis was made relative to US law. This post also uses US law and terminology unless otherwise noted. ↩︎

  2. I tend to think that many bare licenses would likely be enforceable without contract formation. But see Mark R. Patterson, Must Licenses Be Contracts? Consent and Notice in Intellectual Property, 40 Fla. St. U. L. Rev. 105 (2012) Available at: http://ir.lawnet.fordham.edu/faculty_scholarship/593. Either way, the CAL should apply. ↩︎

  3. The CAL also includes Database Rights where applicable. Database rights are only recognized in some jurisdictions. To the extent that a jurisdiction recognizes database rights, however, they are usually granted copyright-like protection. ↩︎

  4. "[N]o civil action for infringement of the copyright in any United States work shall be instituted until . . . registration of the copyright claim has been made in accordance with this title. 586 U. S. ____ (2019) at 1." ↩︎

  5. "Use of a copyright or patent to exercise exclusive rights beyond the scope of the government grant. As stated by one court: 'Misuse of copyright applies where the copyright owner tries to extend the copyright beyond its intended reach, thereby augmenting the physical scope of copyright protection. It typically arises in situations where it is alleged that the copyright owner projected his unique rights in a work onto other, unrelated products or services.'" (Religious Tech. Ctr. v. Lerma, 1996 U.S. Dist. LEXIS 15454, 1578-1579, emphasis added.) ↩︎

  6. The Information Infrastructure Task Force (IITF) was created in 1993 by Vice-President Al Gore (through the National Economic Council and the Office of Science and Technology Policy). Its mission was to articulate and implement the Administration's vision for the National Information Infrastructure (NII). The IITF was chaired by Secretary of Commerce Ronald H. Brown and consisted of high-level representatives of the federal agencies that play a role in advancing the development and application of information technologies. ↩︎

  7. Bruce A. Lehman, Information Infrastructure Task Force, The Report of the Working Group on Intellectual Property Rights, at 71 (Sept. 1995). ↩︎

  8. Richard Stallman, What is Free Software, "The freedom to run the program as you wish," Version 1.153, https://www.gnu.org/philosophy/free-sw.en.html, 2016. ↩︎

  9. The GNU General Public License, version 2, "Preamble," available at https://opensource.org/licenses/gpl-2.0.php. ↩︎

  10. Nolo’s Plain-English Law Dictionary, "Possessory Interest," available at https://www.nolo.com/dictionary/possessory-interest-term.html ↩︎