[License-review] For approval: The Cryptographic Autonomy License (Beta 4)

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>
wrote:

> Bruce
>
> 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
> that.
>
> henrik
>
> 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:
>>
>>> Josh,
>>>
>>> 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.
>>>
>>> henrik
>>>
>>>
>>>
>>>> --
>>>> Josh Berkus
>>>>
>>>> _______________________________________________
>>>> License-review mailing list
>>>> License-review at lists.opensource.org
>>>>
>>>> http://lists.opensource.org/mailman/listinfo/license-review_lists.opensource.org
>>>>
>>>
>>>
>>> --
>>> henrik.ingo at avoinelama.fi
>>> +358-40-5697354        skype: henrik.ingo            irc: hingo
>>> www.openlife.cc
>>>
>>> My LinkedIn profile: http://fi.linkedin.com/pub/henrik-ingo/3/232/8a7
>>> _______________________________________________
>>> License-review mailing list
>>> License-review at lists.opensource.org
>>>
>>> http://lists.opensource.org/mailman/listinfo/license-review_lists.opensource.org
>>>
>>
>
> --
> henrik.ingo at avoinelama.fi
> +358-40-5697354        skype: henrik.ingo            irc: hingo
> www.openlife.cc
>
> My LinkedIn profile: http://fi.linkedin.com/pub/henrik-ingo/3/232/8a7
> _______________________________________________
> License-review mailing list
> License-review at lists.opensource.org
>
> http://lists.opensource.org/mailman/listinfo/license-review_lists.opensource.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensource.org/pipermail/license-review_lists.opensource.org/attachments/20191212/ba91c015/attachment.html>