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

[Bruce Perens]

On Thu, Aug 22, 2019 at 1:50 PM Lukas Atkinson <opensource at lukasatkinson.de>
wrote:

> On Thu, 22 Aug 2019 at 22:14, Bruce Perens via License-review <
> license-review at lists.opensource.org> wrote:
>
>> Importantly, the CAL does not encumber the data.
>>
>
This is a semantic argument about the meaning of legal terms. It doesn't
"encumber" the data, but it asserts a requirement for specific action
regarding the data upon the licensee with as large and odious an effect as
something called "encumberance" might have.


> It does not require any license for the data. It does not restrict how
>> data may be processed. It merely compels a software operator to perform
>> certain actions regarding the data, and only if they are able to do so.
>>
>
It doesn't say "only if you are able to do so". It says "to the extent that
such User Data is available to You for use in conjunction with the Work."
It can very easily be the fact that the data is available for you to use in
conjunction with the work, but not for you to extract from the program
without soliciting the work of a more technically-skilled person.

I agree that the CAL restricts use in a very small way, but think that this
> restriction is appropriate, similar to how requiring source disclosure is
> considered appropriate in copyleft licenses.
>

OK, so a restriction of use is OK if it achieves a *similar *purpose to
requirements that you distribute source code, even though it's data, not
source code. So, what happens when the next license comes along, and
requires that you distribute your *own private *data to the software
author, with appropriate rights? How is that fundamentally different from
the requirement here? We then get to stating a whole rule-set for data
freedom that maintains your privacy too, which isn't currently in the OSD
and doesn't belong there.


> SaaS as a field does not require user data to be locked up.
>

I reject the proposition that #6 protects *classes *of endeavor and does
not at the same time protect any of the million implementation details of
that endeavor. I could then come out with an anti-vegetable-oil license
that requires the use of lard, and that would, under your analysis, protect
the field of endeavor of baking. A field of endeavor is the whole of the
large set of decisions that make it up, not some Platonic Ideal version of
the same endeavor.

As the end user's freedom so crucially depends on access to their data, I
> think that on balance, a software operator's freedom must take the backseat
> here.
>

Actually, OSI hasn't gotten into the business of protecting one party at
the other's expense except in the case of anything so fundamental as
responsibility to distribute source code. This shows the problem OSI would
be entering here - the need to weigh each party's rights and decide *which
is more worthy than the other. *Certainly not everyone agrees that the user
is more worthy than the business. This is a sort of micromanaging social
engineering that we have wisely stayed away from.

An end user is free to run the software for themselves or their affiliates
> without restriction
>

That's actually not a factual statement. There is a restriction in legal
terms, backed by the potential of prosecution for copyright infringement.


> , and will certainly not have to consult a lawyer for that. You are
> painting an overly dramatic picture here.
>

What happens when someone asks for their data? Whether or not to give it,
and how to give it without violating anyone else's privacy, are not trivial
decisions.


> In general, I also find the CAL to be more comprehensible for lay persons
> than e.g. the GPLv3.
>

I don't actually. But this is irrelevant, because the naive user does not
have to read the GPL. It doesn't place any restrictions upon them.

If compliance doesn't matter for some people, and isn't a noticeable burden
> for the rest, and increases software freedom, is that provision really so
> objectionable?
>

We must keep in our minds that Open Source involves lots of licenses, not
just the one under consideration. The aggregate of license obligations can
become intolerable for practical use while a single license might be
tolerable for some arbitrarily selected person.

At the risk of being criticized for the slippery-slope fallacy, where do
you stop? How do we define what is not so much trouble, and who do we
define that for, and what about everyone else?

    Thanks

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