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

[VanL]

Hi Nigel,

The core issue is that I don't think it is appropriate to dictate the
mechanism. All of your suggestions boil down to, "add the technical
requirement that the software does [X]." I think that the pressure of
compliance will make the type of ease-of-use features you are suggesting
desirable. That is enough. I don't want to mandate them.

Thanks,
Van


On Wed, Dec 11, 2019 at 12:49 PM Nigel T <nigel.2048 at gmail.com> wrote:

> Van,
>
> What issue do you have with not requiring the downstream user to provide
> any user data that the original CAL licensed software doesn't make
> available to the non-technical user?
>
> If the original software doesn't provide a user accessible export feature
> then there should be no downstream requirement for the user to provide any
> user data.  You cannot assume that the user is a developer so the assertion
> that they can just do a SQL dump or some other convoluted technical
> mechanism is an excessive burden to place on users.
>
> You can make it a requirement that any modification that adds user data
> must be accompanied by a user accessible export feature of some kind.
>
> Nigel
>
> On Wed, Dec 11, 2019 at 12:37 PM VanL <van.lindberg at gmail.com> wrote:
>
>> Hi Nigel,
>>
>> You are correct that the CAL does not mandate any particular
>> functionality or method of compliance. History has shown that mandating a
>> particular technical structure is unwise. Instead, the CAL simply describes
>> what is required and uses the standard tool of open source licensing - the
>> denial or termination of the license - to motivate compliance.
>>
>> You can argue that the CAL may be difficult to comply with in some cases,
>> or that ot would not be well-suited to some types of applications. But
>> those are not marks against the CAL. Different licenses address different
>> needs.
>>
>> Thanks,
>> Van
>>
>>
>> On Wed, Dec 11, 2019, 9:13 AM Nigel T <nigel.2048 at gmail.com> wrote:
>>
>>> The bar is being moved here.  CAL does not require that the software be
>>> able to import any data to get back to a running state...or (according to
>>> Van) even need to export any data so a SQL dump is acceptable in meeting
>>> the CAL requirement.
>>>
>>> So the user's "ability to get back to the place they were" probably
>>> requires that they re-enter the data and re-doing any associations by hand
>>> anyway. The data doesn't even have to be in any kind of layout to
>>> facilitate re-entering the data.  Here you go...a SQL dump of your data,
>>> enjoy.  I could even just create a single PNG of all the data and meet CAL
>>> requirements.
>>>
>>> If the objective really is for the user to be able to get back to where
>>> they were with a clean copy of the system then CAL should specify that CAL
>>> software should support import/export round tripping of user data.
>>>
>>> In any case, the operation of the software is not dependent on the
>>> user's customer data being present or your software is broken.
>>>
>>> I take it you do not like the suggestion that the downstream software
>>> user is under no obligation to provide any customer data that the original
>>> code did not provide as export?
>>>
>>> On Wed, Dec 11, 2019 at 12:37 AM Henrik Ingo <henrik.ingo at avoinelama.fi>
>>> wrote:
>>>
>>>>
>>>>
>>>> On Wed, 11 Dec 2019, 03:29 VanL, <van.lindberg at gmail.com> wrote:
>>>>
>>>>> The use or operation of the software is not dependent on user’s
>>>>>> customer provided data being present...
>>>>>
>>>>>
>>>>> This is not really correct, if you think about it.
>>>>>
>>>>> I don't think it is debatable to say that some (most?) software works
>>>>> differently in the presence of particular data. The subroutines the run are
>>>>> different; the displayed interface may be different; the state of the
>>>>> software is *different.* Because the accumulated state is different, the
>>>>> actual functioning of the software, as experienced by the user, is
>>>>> different.
>>>>>
>>>>> I agree that the user has the ability to get back to the place where
>>>>> they were by re-entering the data and re-doing any associations made. But
>>>>> the latent potential for the software to work the same way is not the same
>>>>> as the software actually functioning the exact same way.
>>>>>
>>>>>
>>>> Taking this argument further, the user can also rewrite all the code
>>>> from scratch, and therefore all copyleft licenses (and open source) are
>>>> unnecessary in general.
>>>>
>>>> Henrik
>>>>
>>>>>
>>>>> _______________________________________________
>>>> 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
>>
> _______________________________________________
> 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/20191211/97d384a1/attachment-0001.html>