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

Tue May 14 03:19:12 UTC 2019

Van, now I am doubly confused. You assert that by "perform" you really meant "display." But "display" is a separate explicit verb in 17 USC 106, and according to 17 USC 101 it means:

To “ <https://www.law.cornell.edu/uscode/text/17/101> display” a work means to show a copy of it, either directly or by means of a film, slide, television image, or any other  <https://www.law.cornell.edu/uscode/text/17/101> device or  <https://www.law.cornell.edu/uscode/text/17/101> process or, in the case of a motion picture or other audiovisual work, to show individual images nonsequentially.

My immediate quarrel is not with what you mean to say with your license, only with your choice of copyright terms-of-art that mean something very different.

It appears that you intend to focus on the "render[ing]" and "display" of the work over a network. In computer science, that is referred to as "executing" the work on the network. Thus, in your situation, you probably mean "executing" the API. 

Yes, software is classified as a literary work for purposes of copyright law. But nowadays, the musical or image components of a software work (see, e.g., Pandora and YouTube) can also be performed or displayed. That doesn't change their own copyright character, nor does it suggest that the performance or display is of the literary components of that work. The "literary" software is executed so that those musical or image components can be performed or displayed. 

I challenge you to do a "dramatic reading, line by line, of the source code to an audience." This reminds me of several of the night-time comics who ask professional actors to read Trump's remarks dramatically to the audience. That is not software, although every component is executed by camera, network, and television software to bring it to me. The performance or display by Trump or the performer are not themselves software.

Yes, it is also true, as you say, that when you "make [your] API available," you may incidentally "make portions of [your] source code available." But the essential and important aspects of that availability is the execution of the API, not anything to do with its source code per se. The "network action of a software program" is its execution on a computer somewhere on the network, not the music or images or even the source code.

My concern is your choice of terminology. While the Supreme Court has not yet told us that an API cannot be copyrighted nor licensed, I personally prefer that we not confuse them with inappropriate terms-of-art so that they don't understand that the execution of the API is what must – for the sake of free software – remain free and unconstrained. For these reasons, I personally support almost all of Google's amici briefs in that litigation.

My objections have nothing to do with patent law. The word "use" is frequently misconstrued in open source licenses to imply a patent license. Perhaps, or perhaps not? A patented API is a different beast from one where only copyright is claimed.

You said: "We regularly observe situations where people 'send' data to an operator, and then want it back, and the operator refuses." True, but so what? Why force them to return data that the sender already has? And why omit the important reference to "personal information" that the receiver ought not to share with anyone even if the sender wants it back? For that reason, telecommunications networks should not share location data without express permission.

What you wish to do with CAL can perhaps be done better with correct words. I apologize for calling your response a "casual dismissal." Neither is my objection casual.

Best, /Larry

From: VanL <van.lindberg at gmail.com> 
Sent: Monday, May 13, 2019 6:39 PM
To: Lawrence Rosen <lrosen at rosenlaw.com>; License submissions for OSI review <license-review at lists.opensource.org>
Subject: Re: [License-review] For Approval: The Cryptographic Autonomy License

Hi Larry,

Thank you for the correction.

On Mon, May 13, 2019, 7:13 PM Lawrence Rosen <lrosen at rosenlaw.com <mailto:lrosen at rosenlaw.com> > wrote:

Van, your response to my earlier comments about CAL did not capture my objections correctly.

1. "Performance" is a very misleading word for you to use. First, it is meant by you in an entirely different way than the explicit copyright term-of-art in 17 USC 101:

To “ <https://www.law.cornell.edu/uscode/text/17/101> perform” a work means to recite, render, play, dance, or act it, either directly or by means of any <https://www.law.cornell.edu/uscode/text/17/101>  device or  <https://www.law.cornell.edu/uscode/text/17/101> process or, in the case of a motion picture or other audiovisual work, to show its images in any sequence or to make the sounds accompanying it audible.

You risk misleading licensors and licensees about the meaning of that word.

Here we disagree. You are focusing too literally on selected parts of the statute - many parts of which do not apply.

But you did not quote all of 17 U.S.C. § 101:

    To perform or display a work “publicly” means—

    [. . .]

    (2) to transmit or otherwise communicate a performance or display of the work to a place specified by clause (1) or to the public, by means of any device or process, whether the members of the public capable of receiving the performance or display receive it in the same place or in separate places and at the same time or at different times.

In particular, I am focusing on the "render[ing]" and "display" of the work over the network as being the performance.

As I have noted previously, software is classified as a literary work for purposes of copyright law, so that is where I go to for examples.

Let's say, for example, that I did a dramatic reading, line by line, of the source code to an audience. Public performance of the code as a literary work? Yes - clearly in line with established cases.

What about a dramatic display of my code, sending selected lines out to an audience? Yes, and again in line with established cases.

When I make my API available, in almost all cases I will incidentally make portions of my source code available as part of the response. This is indistinguishable from the dramatic display, and consistent with the full text of the statute.

Also, per OvG, even the minimal creativity involved, plus the creative organization of how to send responses is enough to maintain copyright - and public performance - in the network action of a software program.

Please let me know where you disagree with this analysis. 

Many of us believe that an API should not be subject to copyright or licensing restrictions at all.

Again, I generally agree, but that is not where we are. 

Aside from copyright, however, the CAL also hooks into the patent rights to use, sell, and offer to sell. Even if I am wrong on my public performance analysis, making the API available over the network is clearly included in at least one of use, sell, or offer to sell. This provides a secondary, independent chain of reasoning to support the concept.

Again, please let me know where you see this failing legally.

2. When a person sends data to a program, no license should require that the receiving program be prepared to send it back. Data is and should remain free. The sender alreadyd knows (or should know) what data she sent to the receiver. There is no need to impose any return burden on the receiver of that data.

I understand this point. It is a normative point, not a legal one: it "should" not be necessary.

In an ideal world, that is true. I don't think your representation accords with reality, though. We regularly observe situations where people "send" data to an operator, and then want it back, and the operator refuses.

More important, my reference in my email to GDPR meant only that the receiver should have a responsibility not to disclose anyone's personal data to any third party. When my phone sends my name and URL and location as data to a receiving program, that automatically (by statute!) should be confidential information. The sender could have copied the data before it was sent, and the receiver should have a confidentiality obligation about that data that forbids her from disclosing it to anyone without my express permission. This has no relationship to "ownership interests or licensing rights." For example, my "location" is not owned; it is merely personal information that I want kept from third parties.

I agree that there should be a general obligation to keep personal information confidential - and under certain statutes, an operator has a requirement to do so. 

The CAL does not address the confidentiality of personal information vis-a-vis third parties at all. In fact, there is specific language limiting the data portability provisions to data that a person has a preexisting right to possess.

I hope you won't dismiss my concerns about CAL casually.

No casual dismissal intended. You felt that my summary was deficient and provided additional information. Now that you explained more, I have tried to respond more fully.

Thanks,

Van

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensource.org/pipermail/license-review_lists.opensource.org/attachments/20190513/8b7032c7/attachment-0001.html>