[License-discuss] For Public Comment: The Cryptographic Autonomy License

[Bruce Perens]

OK. I will try to generate a two-sentence clause that preserves the
customer's specific fears in their selected wording while being broader and
not a use restriction, and submit it for your approval.

    Thanks

    Bruce

On Mon, Mar 18, 2019 at 7:15 AM VanL <van.lindberg at gmail.com> wrote:

> This is best thought of as an extended anti-Tivoization clause. It
> concerns a particular type of attack on user freedom that can arise in the
> context of distributed systems that use cryptographic primitives as
> functional and addressing elements. It is related to, but broader than, the
> concept of capabilities in software.
>
> By analogy: Tivoization uses a cryptographic primitive to deny effective
> freedom to recipients of software. They can create derivative works, but
> they are unable to meaningfully exercise that freedom because the hardware
> will not run a non-signed version.
>
> In the context of Holochain, cryptographic primitives are used for
> identity and for processing data (they are literally part of the "virtual
> machine" that runs various types of mobile code). This clause is meant to
> ensure that each Recipient has the freedom to use the software to process
> their own data and to control their own identity. Thus, a negative
> limitation, analogous to the GPLv3 restriction on Tivoization, that is only
> meant to prevent a licensee from exercising the rights in a way that
> prejudices later Recipients and practically denies them the same
> permissions received.
>
> Thanks,
> Van
>
>
> On Sun, Mar 17, 2019 at 6:35 PM Bruce Perens <bruce at perens.com> wrote:
>
>> On Sun, Mar 17, 2019 at 1:53 PM VanL <van.lindberg at gmail.com> wrote:
>>
>>> I agree with you on this one. However, the phrasing of this particular
>>> element was important to my client. I did try to make  sure that the
>>> broader language (as you suggest) was also present - see 2.3(a) and (b).
>>>
>>
>> Could you ask your client to discuss what is important here, a bit more
>> for us?
>>
>> I would like to see if cleaner wording will actually be acceptable. Right
>> now it comes across as a software use restriction, and is possibly
>> problematical within OSD #6, and I don't think there's any real intentional
>> reason for that and what the customer wants can be done without any hint of
>> trouble. Plus although you have added provisions to fill in, the sum is
>> more complicated than is really necessary.
>>
>>     Thanks
>>
>>     Bruce
>> _______________________________________________
>> License-discuss mailing list
>> License-discuss at lists.opensource.org
>>
>> http://lists.opensource.org/mailman/listinfo/license-discuss_lists.opensource.org
>>
> _______________________________________________
> License-discuss mailing list
> License-discuss at lists.opensource.org
>
> http://lists.opensource.org/mailman/listinfo/license-discuss_lists.opensource.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/attachments/20190318/6653f117/attachment.html>