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

Bruce Perens bruce at perens.com
Mon Mar 18 18:14:53 UTC 2019

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.



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>

More information about the License-discuss mailing list