[License-review] For Approval: The Cryptographic Autonomy License

Mon May 13 21:40:07 UTC 2019

I thought this was resolved as being simply an interpretive aid... but if
this ends up being the remaining issue, I will jettison 7.1.1.

Thanks,
Van

On Mon, May 13, 2019 at 4:30 PM Pamela Chestek <pamela at chesteklegal.com>
wrote:

> I would add that the special provision for GDPR in Section 7.1.1 is
> facially non-compliant with OSD 5/6 because it singles out one class of
> licensees, those who have to comply with a specific privacy law, the GDPR,
> and gives them different treatment than those who have to comply with other
> privacy laws.
>
> Pam
>
> Pamela S. Chestek
> Chestek Legal
> PO Box 2492
> Raleigh, NC 27602
> 919-800-8033
> pamela at chesteklegal.com
> www.chesteklegal.com
>
> On 5/13/2019 5:02 PM, VanL wrote:
>
> Hello all,
>
> I wanted to stop for a minute and provide a checkpoint: a good faith
> summary of what I see as the arguments and counterarguments about the CAL.
> Please correct me if I am misrepresenting anyone's arguments.
>
> As far as I see it, there are two substantive debates occurring over the
> CAL:
>     1) Can data portability can be guaranteed as part of software
> freedom/under the OSD?
>     2) Is the legal mechanism of using "public performance" effective,
> compliant with the OSD, and good policy?
>
> These issues are fundamental. Regardless of how well (or how poorly) the
> CAL is drafted, these cannot be resolved through more precise wording or
> better examples. Other issues of wording, or clarifications about the role
> of patent rights have been raised, but those seem to have been resolved
> through explanation or changes to the wording. There is also a third line
> of argument that the CAL is too complicated, and that complexity *per se*
> should be disqualifying. With regard to this third argument regarding
> complexity, it seems subordinate to the substantive debates above. (For an
> example, see Perens, ; also in rebuttal, Villa,
> http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-May/004143.html
> )
>
> The substantive arguments above generally only apply to the "operator" use
> case, where the software is being run by a first user (the "operator") to
> provide services to one or more second users (the "end users"). Note that
> the linked messages below are *representative*, not comprehensive.
>
> *1. Arguments about data portability:* The CAL conditions the exercise of
> copyright and patent permissions on providing data portability for end
> users of the software in the operator context. This is for "User Data" as
> defined in the CAL, which is scoped to data that is input to or output from
> the software in which a user as a preexisting interest.
>
> - Argument: The data portability provisions violate freedom zero. (Perens,
> http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-May/004121.html
> )
> - Response: Data portability is in line with traditional notions of
> software freedom (Lindberg,
> http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-May/004123.html),
> see also "CAL is a net positive contribution to software freedom" (Ingo,
> http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-May/004148.html)
>
>
> - Argument: It is a use restriction (prohibited under OSD 6) to deny
> operators the ability to withhold user data from end users because it
> applies more particularly in the operator case. (Perens,
> http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-May/004081.html,
>
> http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-April/004036.html
> )
> - Response: Operators are free to use the software in any way they see fit
> - there is nothing in the CAL that denies them the ability to use the
> software in any particular way. They just have to take the additional
> action of providing data portability along with source.
>
> - Argument: This encumbers data that is outside the scope of the license.
> (Perens,
> http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-April/004032.html
> )
> - Response: The CAL does not create any rights that did not previously
> exist. It does not change the license for any work or data. (Lindberg,
> http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-April/004033.html
> )
>
> - Argument: Data is not copyrightable, so not reachable by the license.
> (Rosen,
> http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-May/004137.html
> )
> - Response: The copyrightability or not of data is not relevant to the
> license; the CAL does not create new ownership interests or licensing
> rights. (
> http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-May/004139.html
> )
>
> - Argument (Ingo vs Ingo!): CAL may fail OSD #6, in similar fashion to
> license zero... "I also agree with Bruce that this whole topic is a can of
> worms"
> - Response: Having "Freedom to run the program for any purpose" includes
> both operator and end user as people "running" the program - this is the
> idea behind all network copyleft.... CAL is scoped "in a way that is quite
> defensible"
> (Both are Ingo, same message:
> http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-May/004148.html
> )
>
> - Argument: Data portability is an ethical restriction which doesn't
> belong in a license. (Cowan,
> http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-May/004140.html
> )
> - Response: The CAL limits itself to permissions for the work and does not
> invoke ethical duties (
> http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-May/004108.html
> )
>
> *2. Arguments about the legal mechanism:* Open source software licenses
> rely on intellectual property law to enforce their rules concerning the
> licensing of derived works. Most existing FOSS licenses have used the
> ability to distribute the work and to create derivative works (both under
> copyright) as the traditional "hook" for enforcement. Some alternatives do
> exist: the third party beneficiary language in NASA 1.3, and the "network
> interaction" with a modified work in AGPL.The CAL also uses distribution
> and the ability to create derivative works as hooks for copyleft
> enforcement. The CAL also uses "public performance" (either as included in
> the copyright statute or as defined in the included definition), as well as
> patent rights (specifically "use", "sale," and "offer for sale").
>
> Most of the arguments have to do with the use of public performance:
> - Argument: This is legally untested and not necessary (e.g. Ingo,
> http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-April/004046.html
> )
> - Response: The only other license applicable in an operator context is
> the AGPL, which uses legally novel terms, is gameable relative to
> enforcement, and ambiguous in a corporate context (Lindberg,
> http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-April/004047.html,
> see also Fleming,
> http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-April/004049.html
> )
>
> - Argument: Public performance is US-centric and may not be applicable in
> the international context. (Chestek,
> http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-April/004054.html
> )
> - Response: WIPO "Communication to the public" appears analogous
> (Atkinson,
> http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-April/004055.html,
> see also Ingo,
> http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-April/004060.html),
> and "Public performance is also a defined term" (Lindberg,
> http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-May/004108.html
> )
>
> - Argument: Public performance extends copyright ("is copyright
> maximalist") and so should be rejected as a matter of policy. (example:
> Henrik Ingo,
> http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-April/004059.html,
> see also Peterson,
> http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-May/004092.html).
>
> - Response: "Public performance is recognized under copyright" and it is
> better to use existing legal terms (Lindberg,
> http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-May/004095.html,
> see also Rosen,
> http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-May/004137.html,
> but Rosen mentions that it may be limited in application)
>
> - Argument: The CAL uses Oracle v. Google-based logic regarding API
> reimplementation, this is premature (Fontana,
> http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-April/004062.html)
>
> - Response: These rights already exist, this is not an extension
> (Lindberg,
> http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-May/004108.html,
>
> http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-May/004089.html).
> Also, the structure of the CAL does not make it dependent upon a particular
> outcome in OvG (Chestek,
> http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-April/004067.html
> )
>
>
>
>
> _______________________________________________
> License-review mailing listLicense-review at lists.opensource.orghttp://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/20190513/2004d4b2/attachment-0001.html>