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

[Henrik Ingo]

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