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

Henrik Ingo henrik.ingo at avoinelama.fi
Mon Dec 9 18:33:27 UTC 2019


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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensource.org/pipermail/license-review_lists.opensource.org/attachments/20191209/34b5dc11/attachment.html>


More information about the License-review mailing list