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

[Bruce Perens]

On Thu, Aug 22, 2019 at 3:12 PM Josh Berkus <josh at berkus.org> wrote:

> they want to take their data


Which they provided.


> But, the Vendor has encrypted the User's data, and encased it in legal
> protections, in such a way that the User cannot take their data and leave.
>
> As I understand it, the CAL argues that the OSM should have the right to
> release its software under a license that says that Vendor isn't allowed
> to do that.

If they want to use the OSM's bits, the data has the same
> distribution requirements as the source code.
>

This is a contractually-required performance requirement which attempts to
synthesize a data right which does not actually exist in the local
jurisdiction. And thus it is the same as every approach to OSI with a
license that attempts to enforce something that might properly be a law,
but isn't, so we'll try to make it a license term instead. These have often
been moral things like "no use for war" or "no use by the Police of South
Africa".

You are attempting to make an argument that data rights are so important
that Open Source includes them by implication, when in fact for most of the
existence of Open Source they weren't that much of a consideration. It
doesn't work that way. The rules don't automatically expand to include the
issue of the day, they are consciously changed to explicitly include them
if necessary. I am reminded of that argument of how important badgeware
was, and how irrelevant OSI would be if they rejected it, which someone
apparently bought.

>
> You seem to be arguing that, in this story, the freedom of Vendor is
> paramount, and the freedoms of OSM and User are insignificant.  Why
> would the rights of the intermediate Vendor trump everyone else?
>

Actually, I am declining to say that one party is more important than the
other. I can't see that I have much of a right to say one law-abiding
person is more important than another.

All of this is also leaving aside the other form of data -- things like
> configurations and similar that are required for the software to even
> run, which I believe that the CAL is also designed to protect.


So, my specific configuration is something I now have to disclose too? It's
not a derivative work, and it's not the user's.

    Thanks

    Bruce
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensource.org/pipermail/license-review_lists.opensource.org/attachments/20190822/9030208b/attachment-0001.html>