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

[Bruce Perens]

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensource.org/pipermail/license-review_lists.opensource.org/attachments/20191211/bb9cbd3d/attachment-0001.html>