[License-review] For Approval: The Cryptographic Autonomy License

VanL van.lindberg at gmail.com
Fri Apr 26 14:08:09 UTC 2019

Thank you Henrik.

On Wed, Apr 24, 2019 at 5:01 AM Henrik Ingo <henrik.ingo at avoinelama.fi>

> To summarize my concerns (that still remain):
> 1. The use of public performance in a software license is novel and
> untested. It's hard to predict it's effect, but from the definition of
> Public Performance it seems possible and even likely that both
> developers and users can get sued inadvertently.

I see this point, but disagree about the likelihood of inadvertent suit.
This is probably an irreconcilable difference, as I see the public
performance aspect as being key to the CAL.

> 2. From a policy point of view, it is not in OSI interest to expand
> the use of copyright legislation to restrict software.

I see this also. But in the context of copyright law as it is currently
written and interpreted, I don't think it is an extension to use legal
terminology and case law which already presumptively applies to software.

> 3. It is not necessary for you to use Public Performance to achieve
> your goals of the license. Both from a copyright law, and an Open
> Source Definition point of view, you can use legal methods that are
> more boring, but better tested and safer, to achieve your goals.

See above.

 In particular I wanted to
> state that obviously restrictions on DRM in general are not a
> violation of OSD. Quite the contrary, they are  a great example of
> protecting user rights against new technical means of restricting
> users.

I also agree with this point.

> Another remaining point from my previous review: CAL 2.3 c-e cover the
> use of DRM within the software licensed by CAL. It doesn't cover the
> use of DRM in the hardware or OS to restrict installation and use of
> the CAL licensed software. This seems like an unfortunate loophole
> that can be fixed by borrowing a few sentences from GPLv3.

If you take a look at the exact text, the text is very close to the GPLv3.
There was quite a bit of "borrowing" in exactly the way you suggest.

> For 2.4, I still wonder whether you are willing to consider some more
> explicit option to flag that I didn't choose to use the option. For
> example, when I apply CAL to my software, can I remove §2.4 from the
> license text?

I see this point, but I think that you are covered: 2.4 is an opt-in
provision that applies only if it is explicitly called out by the license
author. If you don't see the particular text specifically invoking it, it
does not apply.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensource.org/pipermail/license-review_lists.opensource.org/attachments/20190426/d73b4063/attachment.html>

More information about the License-review mailing list