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

[Henrik Ingo]

I already reviewed this when you presented the license for discussion
in March: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2019-March/020310.html

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.
2. From a policy point of view, it is not in OSI interest to expand
the use of copyright legislation to restrict 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.

I should emphasize that I think this license would be a net new
addition to the scope of copyleft licensing options, both in terms of
how to address "network copyleft", and the anti-tivoization aspect of
User Data. As such it would be great if a revised, less hazardous
version of this license can eventually be approved by the OSI.


As a brief comment on the angle Bruce is focusing on, it is a valuable
tradition that a goal for open source licenses is to grant rights to
users and at the same time also protect users from unnecessary legal
risk or burden. In this case Bruce's dilemma seems to arise from using
CAL for p2p software, where all participants are both users and
"vendors/providers". While this is a valid area of concern, it also
seems like a relatively narrow problem. 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.

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.

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?

henrik

On Mon, Apr 22, 2019 at 9:44 PM VanL <van.lindberg at gmail.com> wrote:
>
> I'd like to thank everyone who provided feedback on earlier drafts of the Cryptographic Autonomy License (CAL). Since we presented the draft license in February, we have received hundreds of comments and suggestions, all of which have helped us fine-tune the license.
>
> We now present the CAL 1.0-Beta for approval at the next board meeting:
>   Google Docs link: https://docs.google.com/document/d/1sWUREQN02YJ-q91gXOCflRB57Q1YcU1G7UMS_a8WOTI/edit#
>   PDF Link: https://www.processmechanics.com/static/CAL-1.0-Beta.pdf
>
> The CAL is still open for revision until it is approved by the Board, and the links above will be updated as appropriate.
>
> I also refer everyone here again to the blog post describing the legal foundations of the license (https://www.processmechanics.com/2019/03/15/the-cryptographic-autonomy-license/) as well as the discussion on license-discuss, summarized by Lukas Atkinson here: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2019-April/020394.html
>
> Thanks,
> Van
>
> _______________________________________________
> 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