[License-review] For approval: The Cryptographic Autonomy License (Beta 4)
nigel.2048 at gmail.com
Thu Dec 12 17:17:24 UTC 2019
Continuing to characterize these users as "clueless" shows a deep contempt
for the less technical portion of the OSS community. I'm not inclined to
be the word police but I believe that this is inappropriate for this list
and makes it unnecessarily toxic.
I think even non-native English speakers can understand that the phrase
"clueless" is intentionally derogatory.
On Thu, Dec 12, 2019 at 3:18 AM Henrik Ingo <henrik.ingo at avoinelama.fi>
> 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>
>>> 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
>>> 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
> License-review mailing list
> License-review at lists.opensource.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the License-review