[License-review] For approval: The Cryptographic Autonomy License (Beta 4)
henrik.ingo at avoinelama.fi
Thu Dec 12 08:17:34 UTC 2019
As you point out, most operators - however clueless they may be - already
must carry the burden of handling users' data carefully. In the EU - and
this includes sites outside the EU that serve the EU market - they already
have the burden to return to users a data set mandated by the GDPR, which
is even broader than the data set defined by CAL. So the net additional
burden imposed by CAL is actually zero.
Just to give another example of the kinds of things a clueless operator
must legally understand to handle correctly: Should the operator ever
transfer copies of user data from the EU to the US - such as over MySQL
replication - then at minimum they need to apply encryption at rest on the
other end, and possibly more, like minimize or anonymize the personally
identifiable data. If the operator doesn't know what encryption at rest
means, then yes, they will spend €€€€€€€ to have someone else implement
On Thu, Dec 12, 2019 at 1:23 AM Bruce Perens <bruce at perens.com> wrote:
> Henrik, I think your example misses the point. Most operators, of course,
> have more than one customer, and in returning data to one customer, must be
> very careful to segregate it from anyone else's data. The penalties in
> Europe for failing to do that are potentially very significant, and we can
> expect them to get that way everywhere.
> So they either are compelled to write an export facility, or do some sort
> of ad hoc export. But they must be very careful about what data is
> released, and due diligence probably requires that they inspect the
> outgoing data manually.
> On Wed, Dec 11, 2019, 13:12 Henrik Ingo <henrik.ingo at avoinelama.fi> wrote:
>> I agree that this is an interesting question to discuss, and raised it
>> myself some months ago. But...
>> On Wed, Dec 11, 2019 at 10:09 PM Josh Berkus <josh at berkus.org> wrote:
>>> 3) I am now compelled, under the terms of the license, to *write* a user
>>> data export feature that didn't exist in the software that I copied from
>>> you under the CAL.
>> Sorry but this is not true. The whole point of Van's position is that the
>> CAL doesn't compel you to write or create any particular technical solution.
>> As a trivial counter example: Assume that you use the CAL licensed
>> software to provide services to a single user other than yourself. You can
>> now fulfill your obligations easily by just creating a zip file of your
>> data directory.
>> Of course, if you expect lots of users and therefore maybe lots of
>> requests for user data, you probably should write an easy export feature
>> since that is the most practical solution to you. But the CAL doesn't
>> compel you to do that. Quite the contrary, it allows you to choose whatever
>> method is preferable for you.
>>> 4) As a corollary, this means that if I am not a programmer (and don't
>>> have $$$$), I cannot use the software you created in (1).
>>> While the above may be OK with you, it would be an unprecedented step in
>>> the history of OSS licenses, and as such is likely to create significant
>>> barriers to approval.
>> Note that this same criticism can be pointed toward the GPL itself too -
>> for source code.
>> Assume I give to you 1 CD with a binary executable, and another CD with
>> the corresponding source. I have not published the source code online, you
>> are the only recipient of it.
>> You now want to distribute the unmodified binary to 2 other recipients.
>> How will you comply with the GPL requirement to distribute source? You
>> either have to burn 2 new CDs with the source, or upload the source to an
>> online location. If you don't know how to do that, you must spend $$$$ to
>> get it done.
>> The fact that this is not a common problem with the GPL, suggests that
>> the analogous problem might not be common for CAL either. Even if the
>> hypothetical scenario is definitely worth discussing.
>>> Nigel is suggesting language to make the data export requirement
>>> symmetrical; that is, that downstream users are required to preserve or
>>> expand any data export features present in the software they copied.
>> Note that such a requirement may itself not be OSD compliant. At least
>> care would have to be taken to draft the language more precisely than what
>> you did above, so that it doesn't create the situation where some code or
>> feature can never be removed from the software.
>>> Josh Berkus
>>> License-review mailing list
>>> License-review at lists.opensource.org
>> henrik.ingo at avoinelama.fi
>> +358-40-5697354 skype: henrik.ingo irc: hingo
>> My LinkedIn profile: http://fi.linkedin.com/pub/henrik-ingo/3/232/8a7
>> License-review mailing list
>> License-review at lists.opensource.org
henrik.ingo at avoinelama.fi
+358-40-5697354 skype: henrik.ingo irc: hingo
My LinkedIn profile: http://fi.linkedin.com/pub/henrik-ingo/3/232/8a7
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the License-review