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

Tue Dec 10 17:12:09 UTC 2019

Nigel,

Why are you presupposing that distributions you receive are noncompliant?
That seems key to your argument. It is the same as saying, "If I get some
software without complete corresponding source, and then give it to someone
else, I won't be compliant."

Van

__________________________
Van Lindberg
van.lindberg at gmail.com
m: 214.364.7985

On Tue, Dec 10, 2019, 8:49 AM Nigel T <nigel.2048 at gmail.com> wrote:

> Pam,
>
> My concern is that most software that takes in user data isn't very well
> equipped to export that user data back out.
>
> If the *code* you received from upstream (not user data) can not comply
> with the user data export requirements of 4.2...whatever those may
> be...then the downstream user of that code is automatically not in
> compliance with the license on day 1.
>
> A simple scenario is I open source a system that lets my clients make
> appointments with me, see their billing statements, communicate with me,
> etc under the CAL license.  You see this and like it because of open data
> and transparency and get a copy of my software and begin to use it for your
> own clients.  It's really easy to do as I provided you (or whomever sets up
> your web site for you) step by step instructions on how to set it up on
> your own host.
>
> No need to compile anything, just run my installer, pick a password, fill
> in some preferences, add your logo and you're ready to go.
>
> For any other open source license if you provide the source code of my
> software to your clients you are, as far as I can tell, always in
> compliance.
>
> But say I had neglected to provide a way to export some data fields that
> the client gives me when interacting with the system.  You are in breach of
> the license as is everyone else who used my open source software to serve
> their own clients.
>
> All the client user data is certainly available to you as the downstream
> provider of the software to your clients...it may just a simple SQL
> statement away or it may require a lot of code changes to make available
> but either way you DO have it.
>
> As a potential downstream user looking at my software web page, running on
> my demo site, etc, how do you know you are actually in compliance without
> more careful analysis of the system inputs and outputs?  Do you not have to
> remake this assessment every time you upgrade to my latest version?
>
> I also do not believe that we can assume that the required data is easily
> ascertainable nor do I believe that you could provide a simple criteria
> like "received in plain text" given that often the most valuable user
> inputs are the relationships between data and data groupings they create.
>
> Also the requirement to export *"**data has been generated by, for, or
> has been assigned to the Recipient"* makes the required export data not
> easily ascertainable.
>
> Regards,
>
> Nigel
>
>
> On Tue, Dec 10, 2019 at 10:12 AM Pamela Chestek <pamela at chesteklegal.com>
> wrote:
>
>>
>> On 12/10/2019 9:41 AM, Nigel T wrote:
>>
>> The *software is not a safety deposit box* because of the requirement
>> that you must also return *"**data has been generated by, for, or has
>> been assigned to the Recipient". *Safety deposit boxes don't generate
>> new content for users. Software often does.
>> Even ignoring generated data that you'd have go though each and every UI
>> screen and make sure all inputs provided by user are correctly mapped to an
>> export field...and you have to do this every time you update from upstream.
>> *If the original software cannot export all of the data required to meet
>> the requirements of 4.2 then all subsequent users of the software are in
>> breach of the license.*  *This is a point that you continue to dance
>> around. *You are handwaving significant legal and technical burden you
>> are placing on users of CAL licensed software because you want to extend
>> licensing requirements beyond open *source* into open *data *and
>> non-technical users who just use the software out of the box don't control
>> that at all. There are no exceptions for non-compliance of the original
>> code in this license so it's *a compliance nightmare** for every
>> downstream user whether they change the code or not*.
>>
>> Hi Nigel,
>>
>> Can you help me understand your point better? Section 4.2.1 says
>> "Throughout any period in which You exercise any of the permissions granted
>> to You under this License, You must also provide to any Recipient *to
>> whom you provide services via the Work*, ... the Recipient's User Data
>> in your possession, *to the extent that such User Data is available to
>> You* for use in conjunction with the Work."
>>
>> I acknowledge your dislike of the ambiguity of "to the extent that such
>> User Data is available to You," but I'd like to put that point aside. For
>> the purposes of argument let's assume that it is an easily ascertainable
>> set of data, something like "any User Data you received in plain text." The
>> scenario is that I have received data about a Recipient from upstream, and
>> now I am providing services to that same Recipient, which is the only
>> situation in which I would have to provide User Data. Is your point that
>> the program architecture may make it too difficult to extract and provide
>> the plain text that upstream provided to me? Is your argument that there is
>> something that is not open source about this arrangement, or is it that the
>> license will be used in situations for which it is poorly suited?
>>
>> Pam
>>
>> Pamela S. Chestek
>> Chestek Legal
>> PO Box 2492
>> Raleigh, NC 27602
>> 919-800-8033
>> pamela at chesteklegal.com
>> www.chesteklegal.com
>> _______________________________________________
>> 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/20191210/3e965307/attachment.html>