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

Tue Apr 30 23:46:28 UTC 2019

Assume that there is a right of public performance in an API.[^1] What
section of the OSD, or well-settled rationale for not approving a
license, does this particular provision of the CAL fail?[^2] It
exercises no rights outside of copyright law. It serves to make more
software available under open source licenses. Why is this not
considered "open source"?

My point here is the understandable complaint that the OSI
decisionmaking process can be unpredictable. I'm seeing statements that
this provision is unusual, or new, or beyond what the FSF was trying to
accomplish, but not a reason why it therefore fails the definition.

Pam

[^1]: There is an escape hatch in the definition. It says "'Public
Performance; (or 'Publicly Performing') means any action that implicates
the rights of public performance or public display of a work under
copyright law." I can argue, or perhaps it can be clarified, that the
definition says if there isn't such a thing under copyright law, then
this provision isn't operational. However, I don't believe that /Google
v. Oracle/ will have the result of closing the door on the right of
public performance for APIs, since /Google v. Oracle /is about the right
of reproduction, not the right of public performance. Personally I
believe it is a non-frivolous theory.

[^2]: I personally question the data possession provisions, but I'm
putting that aside for now.

Pamela S. Chestek
Chestek Legal
PO Box 2492
Raleigh, NC 27602
+1 919-800-8033
pamela at chesteklegal.com
www.chesteklegal.com

On 4/30/19 6:00 PM, Bruce Perens via License-review wrote:
> Interesting opinion by Lothar Determann:
>
>     Under § 106(4), the copyright owner has the exclusive right to,
>     “in the case of literary, musical, dramatic, and choreographic
>     works, pantomimes, and motion pictures and other audiovisual
>     works, perform the copyrighted work publicly.” Software source and
>     object code typically qualifies as a literary work because it
>     consists of numbers and letters. When executed, it causes
>     computers to display user-generated output—which the software
>     copyright owner does not own—and a GUI—which the software
>     copyright owner typically does own. GUIs contain words, numbers,
>     and graphics and qualify as literary, pictorial, or graphic works
>     under § 102(a). GUIs do not “consist of a series of related images
>     which are intrinsically intended to be shown”; thus, they do not
>     qualify as audio-visual works.57 Section 106(4) does not cover
>     pictorial and graphic works in its enumeration of protected
>     works.58 Thus, the right to public performance under § 106(4)
>     cannot apply to Scenarios 1 through 5 or 7, unless the literary
>     works elements of the underlying code or GUI are “performed.”
>
>     “To ‘perform’ a work means to recite, render, play, dance, or act
>     it, either directly or by means of any device or 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.”59 The enumerated activities (recite, render, play,
>     dance, act) all require as a common feature that the work be
>     presented to a human audience in a manner that the work can be
>     perceived visually or audibly.60 The execution of code internally
>     within a computer does not cause or allow perception by a human
>     audience and thus does not constitute performance.61 The text
>     elements of a GUI are displayed statically for viewing and
>     interacting with the program, but usually not shown in a sequence
>     or made audible. Therefore, software as such is not susceptible to
>     public performance under § 106(4).
>
>
> There's more in the article.
>
> So, we have some interesting questions. Van might wish to try to rebut
> Lothar's opinion. Is it in OSI's interest to approve licenses which
> assert the public performance right for purposes /other/ than
> requiring publication of the source code? I note that although FSF
> disapproves of the assertion of a public performance right in software
> (or any more rights whatsoever), they did try to make use of something
> similar in AGPL, and OSI approved the license after some argument.
>
>     Thanks
>
>     Bruce
>
> On Tue, Apr 30, 2019 at 2:49 PM Smith, McCoy <mccoy.smith at intel.com
> <mailto:mccoy.smith at intel.com>> wrote:
>
>     FWIW, there is a discussion of this question in the following
>     article: 
>     https://scholarship.law.berkeley.edu/cgi/viewcontent.cgi?referer=&httpsredir=1&article=2046&context=btlj,
>     specifically in Sections III.C.6 & III.C.7.
>
>      
>
>     *From:*License-review
>     [mailto:license-review-bounces at lists.opensource.org
>     <mailto:license-review-bounces at lists.opensource.org>] *On Behalf
>     Of *Bruce Perens via License-review
>     *Sent:* Tuesday, April 30, 2019 2:44 PM
>     *To:* License submissions for OSI review
>     <license-review at lists.opensource.org
>     <mailto:license-review at lists.opensource.org>>
>     *Cc:* Bruce Perens <bruce at perens.com <mailto:bruce at perens.com>>
>     *Subject:* Re: [License-review] For Approval: The Cryptographic
>     Autonomy License
>
>      
>
>     Let's try that again.
>
>      
>
>     Van's response was a reply to this question: 
>
>     >/First, would you please discuss whether there is a sufficient public/
>
>     >/performance right for software defined in 17 USC 106 (4), (5) and
>     (6)? I/
>
>     >/read your discussion of Public Performance and was not enlightened.*/
>
>      
>
>     Upon re-reading, it appears that Van read my question as asking
>     whether software was copyrightable at all, and did not really
>     answer the question about the public performance right. This is
>     either misunderstanding, or squirrely lawyer stuff :-)
>
>
> _______________________________________________
> 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/20190430/c9ed92d3/attachment-0001.html>