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

[Bruce Perens]

On Tue, Apr 23, 2019 at 10:45 AM VanL <van.lindberg at gmail.com> wrote:

> On Mon, Apr 22, 2019 at 7:59 PM Bruce Perens via License-review <
> license-review at lists.opensource.org> wrote:
> You are correct that there is a business purpose that we believe will be
> furthered by this license. But you are fundamentally incorrect in your
> assertion: the license itself is written to be completely independent of
> the business purpose. It can be used in many different ways by many
> different users.
>

I suppose it is *possible *for different users to use it for other
purposes, and your statement would apply to any license, no matter how
contrived it is to fulfill a particular purpose. But there isn't really any
getting around the fact that this was designed for a specific purpose of
your customer.

Again this is incorrect. The license only and exclusively 1) grants
> permissions to the Work, and 2) places conditions on the use of the Work
>

No, we have terms regarding User Data, which is only related to the work in
that the work has some role in processing it - not necessarily a large or
significant role, the work nearly has to be involved in some way. A
transmission through the software which did not alter the data nor derive
information from it would be sufficient, under the terms. So, I think we
should consider User Data to be *an entirely separate piece of property
which is encumbered simply because you make use of this software.*

This *should *raise concern, since no Open Source license allowed to
date *encumbers
data which is simply processed through it,* and I would submit that a
violation of OSD #6 and #9 is inherent in such encumbrance.

“Lawful Interest” means either 1) an ownership interest or 2) a
> non-ownership property or possessory interest, including but not limited to
> lawful possession of a particular copy of a work.
>

This doesn't really tell us much at all. As far as *ownership *interests
go, we need a theory regarding ownership of data. This other than trade
secret, which would obviously not apply to the person seeking access to the
data. We might try a copyright applying to organization of data, which
doesn't seem to apply to anyone but the software author who created that
organization.

Possessory interest is also not applicable to the person *seeking* the
data, unless the license seeks to grant a *very broad *right regarding
processed data which is derived *in any way* from data for which someone
has a possessory interest. Given that a cryptographic chain is the target
here, where all data are derived from predecessor data, you might be saying
that all people have a right to all data processed with the program, and
that it is the user's obligation to make that data public.

This leaves us with GDPR, which does not actually settle the question of
data ownership, only of such things as right to access, correct, or to be
forgotten.

Thus, I don't think we can actually define for the user what the legal
interest is. There are opinions, and little case law. We have only the most
shaky idea of what our obligation is, and little protection other than
reliance on an attorney's opinion. The passive user must hire an attorney
to have a hope of actually complying with the license, and even then just
what compliance is would still be in doubt.

One wonders why you don't simply fabricate a contract applying to
participants in your market, rather than contriving to protect the market
data through the software license. The software license could obviously be
defeated through a reverse-engineering process, yielding an interoperable
software without license conditions which protected the market.

Obviously, a contract regarding the market itself would remove the need for
a new Open Source license at all. It thus seems like you aren't really
attempting to protect your customer's market, but to prevent the use of the
software to operate a similar market not owned by your customer without
placing all of the users of *that* market under potentially odious
requirements to disclose data. Thus bringing in a potential OSD#6 issue.

    Thanks

    Bruce
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensource.org/pipermail/license-review_lists.opensource.org/attachments/20190423/43f627fe/attachment.html>