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

[Nigel T]

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