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

[VanL]

Hi Bruce,


On Wed, May 8, 2019, 11:38 PM Bruce Perens <bruce at perens.com> wrote:

>
>
> On Wed, May 8, 2019 at 8:07 PM VanL <van.lindberg at gmail.com> wrote:
>
>> In order for Betty to have a duty vis a vis Anna, Anna needs to be a
>> Recipient of the Work from Betty.
>>
>
> What if Anna performs the work?
>

If Anna performs the work, then Anna will need to provide source code to
those who receive the work from her.

If you mean, "What if *Betty* performs the work?" then this case was
already addressed in my email above, responding to the hypo.

It seems to me that all participants in a blockchain system would have to
> perform the work to at least one other user.
>

Ok.

Since your language seems oriented toward a system with a system operator
> who potentially hoards data....
>

I am not sure where you are getting this.

- If you are getting it from the text of the license, please quote the
provision.

- If you are inferring that I _must have_ built in an exception for this
activity because you think that is my client's business model, then you are
incorrect along a number of fronts. There is no privileged "data hoarder"
in the license. Further, that is not my client's business model, and
technically, that's not how my client's technology works.

But I'll take it here as if this were a modification of the hypo.

Continuing....


....most

> users would probably be performing the software to that system operator.
> Potentially this is your customer.
>

I am not sure how to address this other than to mechanically apply the
rules in the license.

In your hypo here, all the participants in this blockchain-based app
perform the work to a central operator. Thus, the central operator is a
Recipient.

Under the CAL, a Recipient gets a copy/offer of the source code and a
copy/offer of the Recipient's own User Data.


>
>> The CAL does not contain a concept of "Derived Data," so I am somewhat
>> unsure how to respond to your #2.
>>
>
> The problem is that Anna's data exists in a modified form. It's been
> digitally signed by Betty along with data added by Betty.
>

That is irrelevant. There are no rights to "modified forms" of the data.

Is Anna's data available to Betty, and is Anna a Recipient from Betty? If
so, Anna can get a copy of her own data from Betty.


> So, Anna gets a copy of the blockchain after Betty adds her block. She now
> has a lawful interest in it, in terms of possession. But not in the key
> that Betty used to sign it?
>

Anna never has the right in this hypo to Betty's key. Betty's block is not
Anna's User Data.

More fundamentally, you seem to be constructing hypos that don't really
make sense under the CAL. I'd suggest you try drawing this out on a
whiteboard, using the rules for who gets source in the AGPL context. The
flow of duties in the CAL is roughly the same.



> It seems to me that the above is concerning both source code and user
> data. To quote again:
>
> *cryptographic keys*, and any information reasonably necessary to compile
> the Source Code into Object Code *or Process User Data* using generated
> Object Code.
>
>
> I am still reading this as "cryptographic keys necessary to process user
> data". If that is not what it says, perhaps splitting this into two
> sentences is appropriate.
>
> > If Betty has a code signing key necessary to execute the object code,
> then that code signing key must be provided so that Anna can compile and
> run the source code in other contexts.
>
> But not process user data? The text arguably says yes, you are saying no.
>

No. You are selecting elements from the sentence in such a way as to create
a new sentence. A Recipient gets everything necessary to compile the binary
and execute the resulting object code.


Thanks,
Van
__________________________
Van Lindberg
van.lindberg at gmail.com
m: 214.364.7985
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensource.org/pipermail/license-review_lists.opensource.org/attachments/20190509/a62c3f1b/attachment.html>