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

Thu Dec 5 16:12:54 UTC 2019

Van,

Why would a clean-room procedure be necessary? It's Open Source software,
and everyone has the right to read it.

Let's make sure I have this straight. You can't write other Open Source
software that is compatible with Holochain, under any license but the CAL,
because only software under the CAL license has a license to the patents?

    Thanks

    Bruce

On Thu, Dec 5, 2019 at 6:07 AM VanL <van.lindberg at gmail.com> wrote:

> Hello Bruce,
>
> You seem to be outlining a classic clean-room reverse engineering
> procedure and asking if it is possible for someone to use such a procedure.
>
> - In the case of Holochain itself, certain necessary aspects are patent
> pending. The CAL itself is the mechanism by which the patent is licensed to
> users and contributors. Someone who attempted to subvert the user
> protections would thus be exposing themselves to an infringement lawsuit,
> as they would have bypassed the method by which they could receive a
> license. Thus patent law, like copyright, is harnessed to protect the
> software commons.
>
> - In the general case, I don't dispute that there could be a hypothetical
> clean room procedure that would allow legal reverse engineering. In
> practice, I believe the law is muddled and the steps needed to create and
> execute such a clean room procedure are unclear. Maybe Google v. Oracle
> will give us more clarity.
>
> Thanks,
> Van
>
> On Thu, Dec 5, 2019 at 12:23 AM Bruce Perens via License-review <
> license-review at lists.opensource.org> wrote:
>
>> Hi Van,
>>
>> I hope you've been well.
>>
>> The purpose of the CAL is to protect the Holochain (
>> https://holochain.org/) from bad actors who would sequester user data. I
>> am exploring whether it could possibly be effective at that, which of
>> course has some implication on its usefulness.
>>
>> Is there anything in the terms that would prevent a developer from
>> reading the entire code base, and developing a detailed understanding of
>> how it works?
>>
>> Would anything in the terms prevent a developer from documenting how
>> Holochain (or any other licensed code) works, and publicly distributing
>> that document under a different license from the original code? Assume that
>> the document only renders descriptions of the functionality necessary for
>> interoperability.
>>
>> Would anything in the terms prevent any developer from taking that
>> document, and implementing an interoperable program under any license, or
>> no license?
>>
>> Would the CAL terms prevent such an interoperable program from operating
>> as a Holonet node?
>>
>> Does Holonet have any other legal means of preventing such an
>> interoperable program from operating as a Holonet node?
>>
>> Can the CAL data terms, and the overall intent to keep user data
>> available to the user on Holonet, thus be circumvented by anyone who takes
>> the trouble to develop an interoperable program?
>>
>> And if the answer is no, even if the program is under an OSI-approved
>> license?
>>
>>     Thanks
>>
>>     Bruce
>>
>> On Wed, Dec 4, 2019 at 12:31 PM VanL <van.lindberg at gmail.com> wrote:
>>
>>> Based upon ongoing discussions with the license review committee, I am
>>> withdrawing Beta 3 and substituting Beta 4 (here attached).
>>>
>>> The primary change between Beta 3 and Beta 4 is the definition of "User
>>> Data."
>>>
>>> My understanding of OSI's position is that data requirements, such as
>>> are addressed by the CAL, are within scope of what an open source license
>>> can reasonably address. However, there was a request by the committee to
>>> more tightly define the definition of "User Data" so that it was more
>>> closely tied to function and experience of using the software by a user who
>>> chooses to self-host.
>>>
>>> In consultation with my client, we have proposed and received positive
>>> feedback on the following modified definition of User Data (most
>>> significant change bolded):
>>>
>>> “User Data” means any data that is an input to or an output from the
>>> Work, *where the presence of the data is necessary for substantially
>>> identical use of the Work in an equivalent context chosen by the Recipient*,
>>> and where the Recipient has an existing ownership interest, an existing
>>> right to possess, or where the data has been generated by, for, or has been
>>> assigned to the Recipient.
>>>
>>> There are also a few cleanups and the following minor but substantive
>>> changes:
>>> - Section 7.4, There is a definition of "prevailing party" for attorney
>>> fee awards (" A “prevailing party” is the party that achieves, or avoids,
>>> compliance with this License, including through settlement.")
>>> - Section 5.3, Enforcing against a terminated licensee does not cause
>>> termination for the license-enforcing party  ("Administrative review
>>> procedures, declaratory judgment actions, counterclaims in response to
>>> patent litigation, and enforcement actions against former Licensees
>>> terminated under this section do not cause termination due to litigation.")
>>>
>>> All other discussion regarding CAL Betas 2 and 3 should apply.
>>>
>>> From the original submission:
>>>
>>> *Rationale:* The CAL is a new network copyleft license especially
>>> applicable for distributed systems. It is designed to be as protective as
>>> possible of downstream recipients of the software, providing them all that
>>> they need to create and use an independent copy of a licensed work without
>>> losing functionality or data.
>>>
>>> *Distinguish:* The CAL is most similar to the AGPL, and will have a
>>> similar scope of action in most cases. However, the CAL has provisions that
>>> require that operators provide recipients of the software with a copy of
>>> their user data, enhancing their ability to independently use the software.
>>> The CAL also allows the creation of mixed "Larger Works," provides for
>>> affiliate use, and does not specify a mechanism by which notice is given to
>>> recipients.
>>>
>>> *Legal Analysis*: The CAL was drafted by legal counsel. Previous
>>> discussions have outlined many aspects of the legal analysis.
>>>
>>> A copy the the license in Markdown format is attached. For those who
>>> would prefer it, a Google Docs version of the license is viewable here:
>>> https://docs.google.com/document/d/1-eD9EH6i3wdSXgG4XJbF-a0cSSknOERjYzlVonOwAQ0/edit?usp=sharing
>>>
>>> _______________________________________________
>>> License-review mailing list
>>> License-review at lists.opensource.org
>>>
>>> http://lists.opensource.org/mailman/listinfo/license-review_lists.opensource.org
>>>
>>
>>
>> --
>> Bruce Perens - Partner, OSS.Capital.
>> _______________________________________________
>> License-review mailing list
>> License-review at lists.opensource.org
>>
>> http://lists.opensource.org/mailman/listinfo/license-review_lists.opensource.org
>>
> _______________________________________________
> License-review mailing list
> License-review at lists.opensource.org
>
> http://lists.opensource.org/mailman/listinfo/license-review_lists.opensource.org
>

-- 
Bruce Perens - Partner, OSS.Capital.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensource.org/pipermail/license-review_lists.opensource.org/attachments/20191205/5ea60c85/attachment-0001.html>