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

Bruce Perens bruce at perens.com
Mon Dec 9 18:45:13 UTC 2019

Lawyers? You haven't even thought about juries.

I don't think this is unreasonable. As we have recently seen in cases like
Oracle v. Google, there can be really harmful decisions by juries that are
poorly informed on the topic. Lawyers and judges, no matter how
professional they are - about the law - can be out of their depth when
considering technology issues.

We should endeavor to tell them clearly and without omission what we
actually want to happen. Not wave our hands about it, calling valid
criticism unreasonable because we make invalid assumptions about the future
performance of courts and juries.

There's obviously an exception case here that needs to be handled in the
license. One-directional encryption does not provide for releasing user
data back to the user. Either the license has two prohibit it, or make an
exception for it.

On Mon, Dec 9, 2019, 10:34 AM Henrik Ingo <henrik.ingo at avoinelama.fi> wrote:

> Ok, I see your point now. While you're being unreasonable, it's a valid
> nitpick in a legal analysis to say that hashing could be a form of DRM in
> some intentionally dumb lawyer's imagination.
> henrik
> On Mon, Dec 9, 2019 at 6:27 PM Nigel T <nigel.2048 at gmail.com> wrote:
>> Where does it say that there is no obligation?
>> Show me in the license text where it implies or states that the plain
>> text password that was provided by the user to the system is not considered
>> user data?
>> That it’s not stored in plain text on the system is covered under 4.2
>> where I can’t keep data from the user via encryption.
>> Sent from my iPhone
>> On Dec 6, 2019, at 7:29 PM, Henrik Ingo <henrik.ingo at avoinelama.fi>
>> wrote:
>> Nigel,
>> Let's not get carried away here. If a plain text password isn't stored by
>> the system, then there is obviously no obligation to produce a copy. This
>> would be the case also for any other data not stored by the system.
>> Henrik
>> On Fri, 6 Dec 2019, 23:39 Nigel T, <nigel.2048 at gmail.com> wrote:
>>> Again, where in the license text does it delineate what is required to
>>> be meet 4.2?  I can return an encrypted password to the user but the plain
>>> text was provided by the user at some point.  I have either not returned
>>> all the data given to me by the user or have obfuscated it using a
>>> cryptographic means.
>>> Bob has preexisting rights to US census data records because it is
>>> public information.  Alice has spent time and money cataloging that
>>> information so it could be found in a name search.  The service provides
>>> linkage from people in his tree to the historical US census data.  What
>>> needs to be provided?
>>> Answers that states with "as a general rule" or "your example is
>>> underspecified" means Alice has to spend lots of effort to make sure that
>>> the software complies with 4.2 even if she has made zero changes to that
>>> software.
>>> In the context of your company that means any would be competitor is at
>>> a huge disadvantage in using any of your offerings because at any point it
>>> could be determined that they are in non-compliance with 4.2 and only have
>>> 60 days to fix it or cease operations.  It doesn't matter at all to you if
>>> you are compliant.  You don't need a license.
>>> On Fri, Dec 6, 2019 at 10:49 AM VanL <van.lindberg at gmail.com> wrote:
>>>> Hi Nigel,
>>>> On Fri, Dec 6, 2019 at 8:52 AM Nigel T <nigel.2048 at gmail.com> wrote:
>>>>> 3.2.a seems to imply to me that there is no patent grant when the work
>>>>> is used as part of a combination or modification.
>>>> This is known as a combination carveout. Patent claims are covered for
>>>> what is provided to you. If you modify the software in some way so that it
>>>> infringes a patent *solely because of your modification or combination*,
>>>> then your actions are not specifically licensed.
>>>> The rationale is clear: The licensor is only responsible for what they
>>>> provide to other people, not those peoples' subsequent actions. Otherwise
>>>> someone could include a single line from someone's software ("#include
>>>> <stdio.h>") and claim that all the patents owned by that person were
>>>> licensed.
>>>>> IANAL but this strikes me as a license I wouldn't touch with someone
>>>>> else's 10 foot pole.
>>>> I would imagine that the CAL would not be for everyone.
>>>>> The new version also does not appear to address the issue that if CAL
>>>>> licensed software does not meet the requirements of 4.2 then the burden of
>>>>> meeting 4.2 falls on the user even if they had made no changes to the
>>>>> software.
>>>> The CAL does not mandate a particular software architecture.
>>>> Presumably, as with any other copyleft license, anyone wanting to use
>>>> CAL-licensed software will consider whether they are willing to comply with
>>>> the terms.
>>>>> A strict reading could imply that 4.2 would require that the user of
>>>>> the software provide clients with their plain text password.  Does it?  If
>>>>> not, why not?
>>>> As a *general* rule, this is incorrect. Nothing in the CAL requires a
>>>> party to engage in poor software design so as to keep a plaintext password
>>>> available, nor does anything in the CAL require or suggest that a licensee
>>>> should decrypt the user's password. More broadly, I would hope that the
>>>> user's plain text password would not be "available to [the licensee]", but
>>>> no one can anticipate all the ways in which people will create software.
>>>>> The user of the software is the service provider and it strikes me as
>>>>> this license is a potential minefield for any user other than the original
>>>>> authors.  What does "fully use an independent copy" or "substantially
>>>>> identical use of the work" mean in the contexts of the license?
>>>> The easiest way to think about this is by analogy to the GPL3's
>>>> anti-Tivoization and "complete corresponding source" provisions, If a
>>>> particular piece of data is needed for the software to function in the same
>>>> way in a self-hosted situation, then it must be provided.
>>>> To guide your thoughts here, think about the "desert island test."
>>>> There is a desert island, with two people, Alice and Bob, and helpfully,
>>>> two identical computer systems. Alice provides your genealogical service to
>>>> Bob, her only customer, on the first computer. After a while, Bob becomes
>>>> dissatisfied, and wants to be able to run the software himself.
>>>> Alice must provide to Bob the software itself, together with anything
>>>> needed to use all the functions in the software. Alice must also provide
>>>> Bob a copy of Bob's information, so that when Bob loads the information
>>>> into his new copy of the software on his own computer, it has the
>>>> information he expects, and the functionality associated with organizing or
>>>> analyzing his information is also available.
>>>> There is one big caveat, though: Alice only needs to turn over
>>>> information that Bob has some preexisting right to. If Alice also held her
>>>> own information in the software, Alice doesn't need to turn over her own
>>>> information to Bob.
>>>>> Take this in the context of something like a genealogy service.  The
>>>>> user data includes my account information (data I provided), profile (data
>>>>> I provided), my family tree (data I provided)...
>>>> Yes, Alice would provide Bob all this information.
>>>>> ... my DNA information (data generated for me) and potential DNA
>>>>> matches (data generated for me) and links to historical data and public
>>>>> records (data generated for me).
>>>> This example is underspecified, so this part cannot be answered given
>>>> the information provided. If this information is solely based on the
>>>> processing of Bob's information, then Alice would need to provide it. If
>>>> this is based upon other information owned by Alice, then there is no
>>>> requirement to provide information owned by Alice.
>>>> Thanks,
>>>> Van
>>>> _______________________________________________
>>>> 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
>> _______________________________________________
>> License-review mailing list
>> License-review at lists.opensource.org
>> http://lists.opensource.org/mailman/listinfo/license-review_lists.opensource.org
> --
> henrik.ingo at avoinelama.fi
> +358-40-5697354        skype: henrik.ingo            irc: hingo
> www.openlife.cc
> My LinkedIn profile: http://fi.linkedin.com/pub/henrik-ingo/3/232/8a7
> _______________________________________________
> License-review mailing list
> License-review at lists.opensource.org
> http://lists.opensource.org/mailman/listinfo/license-review_lists.opensource.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensource.org/pipermail/license-review_lists.opensource.org/attachments/20191209/8e026aa0/attachment-0001.html>

More information about the License-review mailing list