[License-review] For approval: The Cryptographic Autonomy License (Beta 4)
Pamela Chestek
pamela at chesteklegal.com
Tue Dec 10 19:02:29 UTC 2019
On 12/10/2019 1:04 PM, Nigel T wrote:
> Pam,
>
> It may or may not be an open source license according to the OSD but I
> will quote Van here because he said it well:
>
> /"Regardless, I don't think that the Vaccine License is an
> appropriate OSS license. My primary objection to the vaccine
> license is that it imposes conditions that are logically separate
> from and wholly unrelated to the scope of the intellectual
> property rights that are licensed."/
>
> Replace vaccinations with open data. While I support both open data
> and vaccinations, I am disinclined to mix requirements for those with
> the terms of an OSI approved software license. Open data is arguably
> more related to open source than vaccinations but I would argue they
> are still separate.
This isn't an apt comparison, the CAL is not a data license. The CAL was
amended specifically to ensure that the data requirement only goes as
far as necessary to allow operation of the software. It is therefore
tightly tied to the ability to use the software.
If I were to try to describe the difference, the Vaccine License uses
restrictions to accomplish a goal different than ensuring that the
software can be used. The CAL's restrictions are designed only to ensure
the software can be used.
> And yes, I believe there are cases where it would be very difficult to
> comply with CAL and is a significant departure from prior licenses in
> terms of obligations to the user of OSS software for both being
> compliant and determining if you are in compliance.
I appreciate the comment, which is a line of questioning I followed too
many months ago (there was this red square ....). The difficulty of
claiming "ease of compliance" as a criterion for approval is that it's
product-specific, plus the line between "ok" and "too hard" is going to
be different for every user.
>
> I also do not believe that we can rely on a more forgiving reading of
> license terms but a stricter one...part of the review process here is
> hopefully to figure out possible failure modes from both benign and
> malevolent actors.
It's a balance for sure, trying to figure out whether someone is trying
to game the system in pursuit of goals that do nothing for software
freedom or whether instead the license has a legitimate application that
advances software freedom but that may allow misuse as a side effect.
Comments are all my own and not made on behalf of OSI.
Pam
> Regards,
> Nigel
>
> On Tue, Dec 10, 2019 at 12:26 PM Pamela Chestek
> <pamela at chesteklegal.com <mailto:pamela at chesteklegal.com>> wrote:
>
> You haven't answered my last question, which is whether you
> believe this is not an open source license or simply that it a
> license that will be difficult to comply with in some use cases.
> If you believe it is not an open source license, what would be
> your explanation of the rationale for refusing it?
>
> Pam
>
> Pamela S. Chestek
> Chestek Legal
> PO Box 2492
> Raleigh, NC 27602
> 919-800-8033
> pamela at chesteklegal.com <mailto:pamela at chesteklegal.com>
> www.chesteklegal.com <http://www.chesteklegal.com>
>
> On 12/10/2019 11:48 AM, Nigel T 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 <mailto: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 <mailto:pamela at chesteklegal.com>
>> www.chesteklegal.com <http://www.chesteklegal.com>
>> _______________________________________________
>> License-review mailing list
>> License-review at lists.opensource.org
>> <mailto: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 <mailto: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
> <mailto: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/0fee0994/attachment-0001.html>
More information about the License-review
mailing list