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

Tue Dec 10 17:22:33 UTC 2019

For those who haven't read the hundreds of emails on  this topic over the
past year, I just want to briefly summarize my own thoughts on the issue
Nigel is bringing up.In an earlier iteration of the CAL I did raise this
same issue with Van.

By comparison, the AGPL goes to great lengths to define the requirement to
distribute source in a way that if you run unmodified AGPL software - even
as a service - you are automatically compliant. This is a valuable
tradition in many FOSS licenses - in particular the copyleft ones. However,
in the case of the AGPL this approach does also lead to some IMO
unfortunate effects. Essentially the AGPL assumes that there's some kind of
(classic) user interface where the users can interact with the UI to find a
link to download source code. It's not clear how one should use AGPL for
software that doesn't have a user interface (in the obvious sense). It is a
bit unclear what happens if AGPL software is run behind a proxy: is the
user still interacting with it? And in a microservice architecture it is
not clear that AGPL could be effective for anything else than the UI
components, since the users do not interact with the backend components
directly. (In particular, the components that would store user data!) All
of these issues are consequences from the approach in AGPL arising from the
principle that running the unmodified software is automatically compliant.

So when discussing this topic earlier this year, I came to the conclusion
that the current wording in the CAL is the better approach. (At least
better for CAL, I don't want to say I dislike the AGPL either, just that it
has its own limitations.) I wouldn't want the CAL to move in a direction
where it prescribes the existence of some particular UI, API or other
technology. (In fact, in the extreme THAT would be against OSD # 10!)

And, like Van just pointed out, running CAL software for yourself - whether
unmodified or modified - you will automatically be in compliance. It is
only if you undertake the activity of offering the software as a service to
other users, who can input data into your system, that you become liable to
fulfill these obligations. This does not seem unreasonable to me at all.

Also, it seems likely that a lot of CAL licensed software will include the
feature to easily download a copy of your user data, even if the license
doesn't require it.

henrik

On Tue, Dec 10, 2019 at 4:42 PM Nigel T <nigel.2048 at gmail.com> wrote:

> 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
>>
> _______________________________________________
> License-review mailing list
> License-review at lists.opensource.org
>
> http://lists.opensource.org/mailman/listinfo/license-review_lists.opensource.org
>

-- 
henrik.ingo at avoinelama.fi
+358-40-5697354        skype: henrik.ingo            irc: hingo
www.openlife.cc

My LinkedIn profile: http://fi.linkedin.com/pub/henrik-ingo/3/232/8a7
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensource.org/pipermail/license-review_lists.opensource.org/attachments/20191210/ef4989da/attachment-0001.html>