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

[VanL]

Hi Bruce,

On Wed, May 8, 2019, 9:28 PM Bruce Perens via License-review <
license-review at lists.opensource.org> wrote:

Van,

Let's please get more specific regarding blockchain, since that is the
target of the customer.

Anna puts data in a blockchain, and her digital signature. She holds some
right to this data.
Betty then processes the blockchain, adding data and her own digital
signature. Because it's a blockchain, Betty's added data is necessarily
derivative of Anna's.

Anna asks Betty for her data. What does Betty have to provide?

1. Only the data that Anna fed into the system.
2. The data that Anna fed into the system, and Betty's data which is
derivative.
3. #2, plus the secret key that Betty used to manipulate Anna's data.



Short answer: Possibly nothing. If anything, then only (1).

Longer answer: In order for Betty to have a duty vis a vis Anna, Anna needs
to be a Recipient of the Work from Betty. Just putting your data out into
the wild does not create duties downstream for anyone who happens to get
the data. The duty is personal to each Recipient. See CAL 2.3(b).

Let's assume for the sake of the hypo that Betty is providing services to
Anna that make Anna a Recipient of the Work from Betty. In which case,
Betty will need to make available to Anna the User Data provided by Anna -
your #1.

The CAL does not contain a concept of "Derived Data," so I am somewhat
unsure how to respond to your #2. Regardless, Anna does not have a Lawful
Interest in Betty's derivative data, so the CAL does not create any duty.

Given that there is no duty to provide the "derivative" data of #2, any
keys used to manipulate the data are also irrelevant (your #3).

Anticipating possible questions:

Q: What if Anna's data is encrypted by Betty while in Betty's possession?
Does Betty need to give up her key then?

A: No. If the encryption is reversible, then Betty must decrypt Anna's data
in order to provide it to her unencrypted, but the encryption key used by
Betty can stay secret.

If the encryption is irreversible, then the information is likely "not
available" to Betty, so the duty doesn't apply. If the application does
process Anna's User Data somehow while it is in the encrypted state, then
the encrypted User Data must be made available to Anna so that she can
process that data in the setting of her choice.



Note your definition of "Source Code":

o) “Source Code” means the form of the work preferred for making
modifications, including any comments, design documentation, help
materials, installation instructions, *cryptographic keys*, and any
information reasonably necessary to compile the Source Code into Object
Code *or Process User Data* using generated Object Code.

Emphasis mine. Perhaps modulated by a comma, the definition of source code
seems to include cryptographic keys used to process user data.


This is mixing two different concepts.  The above concerns User Data, this
concerns source code. 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. This is exactly the
same as the requirement to provide keys under the GPLv3's complete
corresponding source.

Thanks,
Van
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensource.org/pipermail/license-review_lists.opensource.org/attachments/20190508/445fa6ed/attachment.html>