[License-review] For approval: The Cryptographic Autonomy License (Beta 4)
Nigel T
nigel.2048 at gmail.com
Fri Dec 6 21:38:46 UTC 2019
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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensource.org/pipermail/license-review_lists.opensource.org/attachments/20191206/0b18fcf2/attachment-0001.html>
More information about the License-review
mailing list