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

[Nigel T]

Van,

Point 1:  So under 4.2 you are required to return the hashed password and
the salt (if any) in addition to any other information in the user profile
that is required to run the system.  M'kay.

Point 2:  It is not straightforward for the non-programmer to determine if
the software is compliant with 4.2 even within the context of Point 1.  The
user provided the password.  Whether a salt is used or not is an
implementation detail.  Did the export provide a salt?  Was it needed?  How
do I know without looking at the code?

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*.

This license appears to work only for the most simplest of use cases
(namely yours) and not in general and would be hugely harmful if attempted
to be used on larger, more complex data systems because many users would
invariably be in breach as most software can't actually export user data to
the required level without resorting to database tools.

And don't try to tell me folks wouldn't try to use CAL on software they
shouldn't because a big selling point for CAL is "open data". I'm all for
open data but having written software to manage large amounts of user data
and I can tell you the challenge to provide the user data required to
"fully use an independent copy of the Work" is very demanding for all but
the simplest of systems even when it's something you want to do.

At best this is a special purpose license that needs huge warnings on it as
it is written today.

Nigel

On Mon, Dec 9, 2019 at 8:03 PM VanL <van.lindberg at gmail.com> wrote:

> Nigel -
>
> I'll answer both your emails here.
>
> First, with regard to passwords: If someone doesn't store the plaintext
> password, it is not "available" to be provided. Note that the user data
> only needs to be provided if it is available to the operator for use with
> the Work. Further, using a password hash also doesn't prevent the use of
> the data in the context of the system. If a program is set up to use a
> password hash to validate someone's password, then the hashed password is
> actually what is necessary.
>
> This gets to your second point: What if some software is not "4.2
> compliant" as you put it? It is straightforward - someone can know what
> they received from the third party Recipient in order to make things work.
> Did you receive a password and username so that the person could log in?
> Then you give it back. You don't need to forensically examine the software
> in order to watch and make sure that you give back the things that the user
> gave to you.
>
> As an analogy, think about the software as a safety deposit box. You are
> the bank. When you run the software, you get an empty box.  If you choose
> to make the software available to a user, then the user can put something
> in the box. You can put something in the box for the user. When the user
> wants to leave, they get their own box and whatever was in their box.
>
> Thanks,
> Van
>
>
>
>
>
>
> 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/065d9460/attachment.html>