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

[Nigel T]

Van,

Given that its a SAAS style license then running the software while having*
"**any non-affiliated third party receives any part, aspect, or element of
the Work from You"* is almost the same as "running the software for its
intended use" but yes, you are correct. I should rephrase it as:

If the original software is not compliant with 4.2 then all downstream
users who lets any non-affiliated people use the software will be in
non-compliance.


In my opinion any FOSS license that allows a licensor to say that users
need to be able to do SQL queries in order to be compliant with the license
terms for software they release is a "real problem" and is a terrible
precedent for the OSI to set.

Maybe if you added a clause to 4.2 that said that the licensee doesn't have
to provide users with any user data not already being provided by the
original software except for any new data added by their modifications I
would view the license differently.

Nigel

On Tue, Dec 10, 2019 at 10:39 AM VanL <van.lindberg at gmail.com> wrote:

> Hi Nigel,
>
> The most fundamental issue you bring up is this idea that someone may run
> software and not be compliant. But it is not the running of the software
> that would create noncompliance. Just as with other open source licenses,
> it is the providing the software to other people that gives rise to the
> duty to follow the license. People don't trip and fall and find that they
> are offering a service over the Internet; they make a choice to adopt
> particular software according to a particular license, and to offer that
> software to others in a particular way.
>
> If people don't want to comply with the CAL, then I agree that they should
> not use CAL-licensed software.
>
> Turning to your more specific points, you are not alone in having written
> software here. The point that you seem to be missing is that anyone can
> look at the software as they received it, then the software as it exists
> after they add a user, and determine the difference. That is the point of
> the safe deposit box analogy.  It doesn't really matter whether the
> Recipient/user put the things in the box, or someone/something else put the
> items in the box.
>
> You also spend time worrying about mapping fields to export elements - or
> to restate more generally, insisting that there needs to be a particular
> technical implementation for data export. But software can be designed in
> different ways - some better and some worse. I am not going to say that a
> particular technically implementation is required.
>
> For example, you claim it would be a real problem that someone might need
> to use "database operations" to get data out of their system. I don't see
> that accessing a database in your control is too much a burden. In fact, I
> think in some cases that may be a good way to be compliant.
>
> 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/20191210/e2b4e0a0/attachment.html>