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

Tue May 14 14:19:38 UTC 2019

I was going to comment on this...

I at least object to both separately:

- Public Performance expands software licensing from what is current
common practice
- API copyrightability asserts that APIs are copyrightable, which is
currently undecided (in the US) and could also (negatively) influence
the outcome of the current Oracle v Google case.

There are also discussions, for both of those, whether such a legal
concept exists at all, or whether this particular license is effective
in asserting such rights. I'm obviously not competent to have such an
opinion. But I do feel the bar for OSI should be fairly low on such
question. Obviously bad, crayon licenses, should be rejected. But for
example here we can say that Oracle has already had some some success
asserting copyrights for APIs, so probably we can't dismiss such a
proposal as utterly ridiculous. So the primary opposition really is on
policy grounds, especially at this time.

I guess I did make an argument that for the public performance part
the license would have unpredictable consequences. So I also opposed
it as a "bad license" despite my lack of formal competence.

Since we're here, a clarification on my past statements: I originally
argued that asserting Public Performance rights is also unnecessary.
At the time I didn't realize CAL intends to copyright, and copyleft,
an API in itself. (My mind has blocked such an outrageous idea and
assumed that cannot possibly be what the text said!) I can see how
innovating new copyright powers could be necessary to claim rights in
an API implementation you didn't write. Still, since I oppose also
claiming API copyright, I still believe there's no need to claim
public performance rights for the remaining, more ordinary
functionality of CAL network copyleft.

henrik

On Tue, May 14, 2019 at 3:45 PM Pamela Chestek <pamela at chesteklegal.com> wrote:
>
> I would also comment that I think you have underplayed the significance of the scope of copyleft question by characterizing it as a "legal mechanism" question. You have not mentioned below that this license requires that any newly-written software that implements the same APIs must also be under and open source license. http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-April/004056.html That is a new concept; no copyleft license requirement has been applied to code written from scratch. I don't read the thread, particularly Richard and Henrik's emails, as suggesting that public performance is per se the problem, but rather the concept altogether is, no matter how it is implemented.
>
> 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 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