Debating the Cryptographic Autonomy License
Van Lindberg first went to the Open Source Initiative's license-review list with the CAL in April. At that point, it ran into a number of objections and was rejected by the OSI's license review committee. The license has since been revised to address (most of) the objections that were raised; a third version with minor tweaks was posted on August 22.
At its core, the CAL is a copyleft license; distribution of derived products is only allowed if the corresponding source is made available under the same (or a compatible) license. The third version added one exception: release of source can be delayed for up to 90 days if required to comply with a security embargo. There is, however, another set of conditions that sits at the core of the CAL and are its reason for existence; they are worth quoting in full:
In addition to providing each Recipient the opportunity to have Access to the Source Code, You cannot use the permissions given under this License to interfere with a Recipient’s ability to fully use an independent copy of the Work generated from the Source Code You provide with the Recipient’s own User Data.
"User Data" means any data that is either an input to or an output from the Work, or is necessary for the functioning of the system, in which the Recipient has an existing ownership interest, an existing right to possess, or has been generated for or uniquely assigned to the Recipient.
4.2.1. No Withholding User Data
Throughout any period in which You exercise any of the permissions granted to
You under this License, 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.
4.2.2. No Technical Measures that Limit Access
You may not, by means of cryptographic controls, control of encryption keys,
seeds, hashes, or any other technological protection measures, or any other
method, limit a Recipient’s ability to access any functionality present in
Recipient's independent copy of the Work, or to deny a Recipient full control
of the Recipient’s User Data.
The license also includes a prohibition against the use of contractual measures to prevent users from exercising the rights described above. The intent of all this language is relatively straightforward: if you are a user of an application (perhaps hosted on the net somewhere), you have the right to extract your data from that application to use with your own modified version of the code. Control of data is not to be used to lock users into a de-facto proprietary system.
This language turned out to be quite controversial on the license-review list. The most vocal opponent is undoubtedly Bruce Perens, who expressed concerns about what others may try to put into future licenses based on the example of the CAL:
So, I am really most concerned with the precedent that this license would establish, which would lead to more severe terms being applied to the data processed. And thus I suggest that OSI not accept any such terms at all.
He went on to argue that the prohibition against locking up users' data should be seen as a field-of-use restriction, which would make the CAL non-compliant with section 6 of the Open Source Definition. Perens compared the CAL to the "badgeware" licenses that the OSI accepted back in 2007. The OSI took a lot of criticism for that decision; Perens suggested that the same thing could happen this time around.
Josh Berkus, instead, characterized
Perens's reasoning as "a 'slippery slope' argument
" and argued
that the CAL should be accepted:
He also rejected the field-of-use argument as being "a huge
stretch
" and concluded by saying: "While it is not the OSI's
job to challenge Amazon's business model, it is not our job to protect it
either
".
That was not the end of the discussion; indeed, it went on at such length that list moderator Simon Phipps eventually asked the participants to reduce the rate at which they were posting. Little new ground was covered in all that volume, though.
In the end, the OSI will have to decide whether mandating access to the
data managed by a given program is an appropriate feature of an open-source
license. The badgeware decision was not seen at the time (or later) as
being one of the OSI's finest moments; the decision on the CAL carries
similar risks. Badgeware licenses, though, sought to increase the rights
of copyright holders, while the CAL gives rights to software users.
Whether that difference will tip the balance in this decision remains to be
seen. The actual decision, it seems, is likely to be made at a
face-to-face meeting in mid-November.