[License-discuss] Copyright on APIs

Henrik Ingo henrik.ingo at avoinelama.fi
Mon Jul 8 20:23:45 UTC 2019


Thanks Pam for each helpful clarification. Clearly I had lost track of all
the appeals at some point as the case is not front page stuff anymore.

About the interoperability part, I realize courts can and will set their
own thresholds here. But it's unfortunate if those stray too far from a
common sense reality held by the actual engineers. So for example in this
case I think it is definitively up for discussion to what extent an API is
copyrightable, given the existing US law. Otoh a court making a verdict
that Android and Sun Java aren't interoperable is just plain ridiculous,
since it is trivial for any engineer to see to what extent they are and
aren't the same and it is also easy to understand the value of the
interoperability that is there.

PS: Ironically, it seems the sort algorithm found in both Android's and
Sun's Java would have been a great answer to the judge's question about
code that was ported from one to the other :-D

henrik

On Mon, Jul 8, 2019 at 9:43 PM Pamela Chestek <pamela at chesteklegal.com>
wrote:

>
> On 7/8/19 4:42 AM, Henrik Ingo wrote:
>
> On Sun, Jul 7, 2019 at 5:36 PM Pamela Chestek <pamela at chesteklegal.com>
> wrote:
>
>>
>> On 7/7/2019 4:23 AM, Henrik Ingo wrote:
>>
>> While I haven't closely followed the details of Oracle vs Google, purely
>> from a layman and business standpoint it seems clear that Google did create
>> Android / Dalvik exactly to be interoperable with Java. This means one can
>> run the same Java source code on either platform and the java.* namespace
>> offers the same packages and functionality.
>>
>> I believe this is an important distinction that is often missed. No,
>> Android is not compatible with Java and was not meant to be. "As we noted
>> in the prior appeal, however, Google did not seek to foster any
>> 'inter-system consistency' between its platform and Oracle's Java platform.
>> Oracle, 750 F.3d at 1371. And Google does not rely on any interoperability
>> arguments in this appeal." *Oracle Am., Inc. v. Google LLC*, 886 F.3d
>> 1179, 1206 (Fed. Cir. 2018). If the Supreme Court doesn't go beyond its
>> remit in *Google v. Oracle*, the earlier cases holding that this type of
>> use is a fair use will still be good law.
>>
>>
> This is quoting Oracle, right?
>
> No, it was quoting the appeals court. In my world, what the court says is
> true is true, whether it's true or not. It becomes "the law of the case"
> and the parties are stuck with it. This is also from the earlier appeals
> court opinion (italics mine):
>
> Google maintains on appeal that its use of the “Java class and method
> names and declarations was ‘the only and essential means' of achieving a
> degree of interoperability with existing programs written in the [Java
> language].” Appellee Br. 49. Indeed, *given the record evidence that
> Google designed Android so that it would not be compatible with the Java
> platform, or the JVM specifically*, we find Google's interoperability
> argument confusing. While Google repeatedly cites to the district court's
> finding that Google had to copy the packages so that an app written in Java
> could run on Android, *it cites to no evidence in the record that any
> such app exists and points to no Java apps that either pre-dated or
> post-dated Android that could run on the Android platform*.15 *The
> compatibility Google sought to foster was not with Oracle's Java platform
> or with the JVM central to that platform. Instead, Google wanted to
> capitalize on the fact that software developers were already trained and
> experienced in using the Java API packages at issue**. *The district
> court agreed, finding that, as to the 37 Java API packages, “Google
> believed Java application programmers would want to find the same 37 sets
> of functionalities in the new Android system callable by the same names as
> used in Java.” Copyrightability Decision, 872 F.Supp.2d at 978. Google's
> interest was in accelerating its development process by “leverag[ing] Java
> for its existing base of developers.” J.A.2033, *1372 2092.
>
> 15 During oral argument, Google's counsel stated that “a program written
> in the Java language can run on Android if it's only using packages within
> the 37. So if I'm a developer and I have written a program, I've written it
> in Java, I can stick an Android header on it and it will run in Android
> because it is using the identical names of the classes, methods, and
> packages.” Oral Argument at 31:31. Counsel did not identify any programs
> that use only the 37 API packages at issue, however, and did not attest
> that any such program would be useful. Nor did Google cite to any record
> evidence to support this claim.
>
> *Oracle Am., Inc. v. Google Inc.*, 750 F.3d 1339
> <https://www.courtlistener.com/opinion/2673149/oracle-america-inc-v-google-inc/>,
> 1371–72 (Fed. Cir. 2014).
>
>
> I don't know why Google would not have focused on this argument in their
> appeal, however I don't see that the kind of threshold painted by Oracle is
> in any way meaningful to the real world. By the same logic one could argue
> that J2ME, J2SE and J2EE are not compatible with each other. Which is true,
> but also silly.
>
> It's a fact that I can copy some Java code to Android, and all the strings
> and integers continue to work. This is interoperability. 100%
> interoperability is very rare anyway. For example, it's unlikely that you
> could just swap one relational database for another, even if both implement
> the same SQL standard. So it would be unhelpful for a court to set the bar
> for interoperability higher than what is the norm and expectation for real
> world use cases.
>
> The legal standard is not a technical standard, it's whether the reused
> content is furthering goals that copyright law accepts as justification for
> copying. You see in the quote that the court noted the fact that there were
> no apps that ran on both platforms, so no actual interoperability. Two
> walled gardens.
>
>
>
>> But importantly, interoperability also goes the other way: Android was
>> compatible with the millions of developers familiar with Java syntax and
>> standard libraries.
>>
>> This is Google's argument why it is a fair use.
>>
>>
> Aren't these separate questions:
> 1) An API (or in any case the Java standard library API) is purely
> functional so cannot be copyrighted, vs
> 2) an API can be copyrighted but for interoperability purposes fair use
> exceptions may apply on a case by case basis. I thought the appeal is still
> about #1 and only if Oracle wins will the litigation about #2 start?
>
>
> The lower court and appeals court have decided both (1) and (2) but we
> don't know yet what the Supreme Court might agree to review. Google already
> asked the Supreme Court to review the copyrightability question once
> several years ago and the Supreme Court decided not to review it. Google
> now has sought Supreme Court review again after the fair use decision.
> Oracle is responding that copyrightability has been finally decided and the
> Supreme Court can't review it this time, just fair use. The Supreme Court
> hasn't decided yet whether it will take the case at all, and if it does,
> whether it will review only fair use or also copyrightability.
>
> Pam
>
> _______________________________________________
> License-discuss mailing list
> License-discuss at lists.opensource.org
>
> http://lists.opensource.org/mailman/listinfo/license-discuss_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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/attachments/20190708/6b156968/attachment-0001.html>


More information about the License-discuss mailing list