[License-review] For Approval: The Cryptographic Autonomy License
VanL
van.lindberg at gmail.com
Tue May 14 01:39:22 UTC 2019
Hi Larry,
Thank you for the correction.
On Mon, May 13, 2019, 7:13 PM Lawrence Rosen <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 “perform <https://www.law.cornell.edu/uscode/text/17/101>” a work
> means to recite, render, play, dance, or act it, either directly or by
> means of any device <https://www.law.cornell.edu/uscode/text/17/101>or
> process <https://www.law.cornell.edu/uscode/text/17/101> 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/f3eaba68/attachment.html>
More information about the License-review
mailing list