4 ms·

The aspect of this case that I don't understand is why, even if APIs are copyrightable, why Google would need a special license for the Android. If Java is ava

The aspect of this case that I don't understand is why, even if APIs are copyrightable, why Google would need a special license for the Android. If Java is available under the GPL, and Android is a derivative work but is also licensed under the GPL, then where's the problem? Conversely, by Oracle's logic, any application that uses the Java API would be a derivative work (the method signatures are perfect copies), and thus the app would need to be either GPL itself or pay for a commercial license for Java. This, too, seems incompatible with existing practice (e.g., Apache's Java applications are licensed under its own open-source license which is more permissive and thus can't be a derivative work under the GPL. What am I missing here?

theandrewbailey 7y ago
IANAL, but this is how I understand it: The GPL only means that you can read, run, change, and distribute code. It does not affect copyright. The individuals/companies working on a GPL program still retain their copyright for each bit of code contributed (authored). Because of that, copying code into a completely different program without consent of each author can be problematic. In addition, only the authors can sue to enforce the license. This is why the FSF requires contributors to assign copyright to the FSF: https://www.gnu.org/licenses/why-assign.en.html https://www.gnu.org/licenses/why-assign.en.html
- barkingcat 7y ago
  This doesn't apply because the implementation that Google used wasn't GPLed at all.
- icebraining 7y ago
  The GPL lets you copy code into a completely different program, it's just that you still have to follow the license and comply with all its requirements.
comex 7y ago
For your first point, Google was trying to avoid the GPL (for whatever reason), but since the lawsuit they’ve switched from Apache Harmony to OpenJDK in order to take advantage of it: https://arstechnica.com/tech-policy/2016/01/android-n-switches-to-openjdk-google-tells-oracle-it-is-protected-by-the-gpl/ https://arstechnica.com/tech-policy/2016/01/android-n-switch... For your second point, using an API is different from consuming it; among other things, you don’t generally copy and paste the full method declarations into your own code.
- monocasa 7y ago
  OpenJDK wasn't out yet, so they weren't avoiding the GPL, they were avoiding the proprietary license that the Sun JRE was distributed with at that time.
barkingcat 7y ago
Because Google didn't use Java as distributed by Oracle/Sun or the Java with the GPL license. (in the timeline of the dispute) Google used an Apache licensed re-implementation called Harmony, which was GPL incompatible to begin with. (The project was created specifically to not be GPL licensed, to AVOID the GPL as well as to negate any GPL protections)
geofft 7y ago
Wikipedia says: "At this point in time, the OpenJDK implementation offered by Sun was not as mature or complete as the Java Standard Edition. Instead of licensing Java, Google chose to develop a cleanroom version of the Java Standard Edition libraries, developing the libraries from a completely fresh start without any access to Sun's code." OpenJDK was released in 2007. Android was founded in 2003 and acquired by Google in 2005. It's entirely possible that if the schedules had been shifted a few years, Android would have gone with OpenJDK. Note that OpenJDK is available under the GPL with the "classpath exception," allowing you to link non-GPL software against it (sorta like the LGPL). Android avoids the GPL in userspace, to the extent of writing their own libc (apparently glibc being under LGPL was not enough).
- liara_k 7y ago
  Ah, THAT makes sense. Not having their own system licensed under the GPL would explain why licensing of OpenJDK doesn't make the question irrelevant, and the timeline explains why they didn't just use OpenJDK directly. Thanks! Also, OpenJDK is now 12 years old... It seems like forever, and it's kind of weird that events that old are still relevant to live legal disputes, but... I guess that's the speed of software vs. the speed of the U.S. legal system... ;)
- stefan_ 7y ago
  When Android was started, no embedded system of any kind used glibc. It's now 2019 and still none do. It's not GPL avoidance, it's just glibc being (a) huge (pain) for all the wrong reasons.
  - andrekandre 7y ago
    what parts of glibc make it trouble for embedded systems? is it the way it uses memory? or just “too large”?
    - kllrnohj 7y ago
      glibc has a reputation for being bloated. Here's a post from 2002 of Linus complaining about it, for example: http://ecos.sourceware.org/ml/libc-alpha/2002-01/msg00079.html http://ecos.sourceware.org/ml/libc-alpha/2002-01/msg00079.ht... Independently of that glibc also has organizational issues. You see this in some major projects flipping back and forth on it, like Debian switching to EGLIBC in 2009 and then back to glibc in 2015. You continue to see this with the very slow (or outright rejection) adoption of new syscalls: https://lwn.net/Articles/655028/ https://lwn.net/Articles/655028/ It's important to remember glibc is not libc for Linux, and distinctly does not behave as such. If your platform is unapologetically Linux to the core, wouldn't you want something else that tracks the kernel API better? And it's not like Android was unique in not using glibc, either. The *BSD's don't, either.
CodeArtisan 7y ago
IIRC, Google copy/pasted code from Apache Harmony which wasn't legal itself. edit: http://www.groklaw.net/pdf3/OraGoogle-959.pdf http://www.groklaw.net/pdf3/OraGoogle-959.pdf "Two of the three questions from the jurors have focused on Apache, but the issue is actually very simple: Apache never obtained any license from Sun permitting its use of the Java specifications for Harmony. As made clear by Apache itself, Apache never had a license from Sun or Oracle for Harmony. Apache had no rights to Java technology that it could give to Google. This not even a case in which there is a “cloud over Apache,” to use the Court’s phrase (4/20/2012 Trial Tr. 1114:16-20). Apache simply had no title at all, and has publicly conceded as much: When Apache resigned from the JCP in protest based on its inability to obtain a license, it stated in its resignation that the “Java specifications are proprietary technology that must be licensed directly from the spec lead under whatever terms the spec lead chooses.” (TX 1045 at p. 2.) Thus, Google’s use of Apache Harmony provides no defense for Google. Oracle seeks an instruction to the jury that will prevent confusion and clarify that Google’s use of Harmony provides no defense to Oracle’s copyright infringement claims."
- curt15 7y ago
  >"When Apache resigned from the JCP in protest based on its inability to obtain a license..." Wasn't Apache seeking a license for a collection of tests, not the right to implement the API itself? And what, under Oracle's argument, would be the legal status of GNU GCJ/Classpath?
  - monocasa 7y ago
    Apache was seeking the ability to access the tests, as passing those tests were the requirement to call it Java. Sun was using trademark (not copyright over API sequence structure and organization) to enforce this, sort of how Firefox does. I'd imagine that Oracle sees GCJ/classpath as infringing, but there's not enough money in enforcing that to be worth it. That's all gut feeling though, and I don't know of any information that'd let us confirm one way or another.

theandrewbailey 7y ago

IANAL, but this is how I understand it: The GPL only means that you can read, run, change, and distribute code. It does not affect copyright. The individuals/companies working on a GPL program still retain their copyright for each bit of code contributed (authored). Because of that, copying code into a completely different program without consent of each author can be problematic. In addition, only the authors can sue to enforce the license. This is why the FSF requires contributors to assign copyright to the FSF: https://www.gnu.org/licenses/why-assign.en.html https://www.gnu.org/licenses/why-assign.en.html

barkingcat 7y ago
This doesn't apply because the implementation that Google used wasn't GPLed at all.
icebraining 7y ago
The GPL lets you copy code into a completely different program, it's just that you still have to follow the license and comply with all its requirements.

comex 7y ago

For your first point, Google was trying to avoid the GPL (for whatever reason), but since the lawsuit they’ve switched from Apache Harmony to OpenJDK in order to take advantage of it: https://arstechnica.com/tech-policy/2016/01/android-n-switches-to-openjdk-google-tells-oracle-it-is-protected-by-the-gpl/ https://arstechnica.com/tech-policy/2016/01/android-n-switch... For your second point, using an API is different from consuming it; among other things, you don’t generally copy and paste the full method declarations into your own code.

monocasa 7y ago
OpenJDK wasn't out yet, so they weren't avoiding the GPL, they were avoiding the proprietary license that the Sun JRE was distributed with at that time.

barkingcat 7y ago

Because Google didn't use Java as distributed by Oracle/Sun or the Java with the GPL license. (in the timeline of the dispute) Google used an Apache licensed re-implementation called Harmony, which was GPL incompatible to begin with. (The project was created specifically to not be GPL licensed, to AVOID the GPL as well as to negate any GPL protections)

geofft 7y ago

Wikipedia says: "At this point in time, the OpenJDK implementation offered by Sun was not as mature or complete as the Java Standard Edition. Instead of licensing Java, Google chose to develop a cleanroom version of the Java Standard Edition libraries, developing the libraries from a completely fresh start without any access to Sun's code." OpenJDK was released in 2007. Android was founded in 2003 and acquired by Google in 2005. It's entirely possible that if the schedules had been shifted a few years, Android would have gone with OpenJDK. Note that OpenJDK is available under the GPL with the "classpath exception," allowing you to link non-GPL software against it (sorta like the LGPL). Android avoids the GPL in userspace, to the extent of writing their own libc (apparently glibc being under LGPL was not enough).

liara_k 7y ago
Ah, THAT makes sense. Not having their own system licensed under the GPL would explain why licensing of OpenJDK doesn't make the question irrelevant, and the timeline explains why they didn't just use OpenJDK directly. Thanks! Also, OpenJDK is now 12 years old... It seems like forever, and it's kind of weird that events that old are still relevant to live legal disputes, but... I guess that's the speed of software vs. the speed of the U.S. legal system... ;)
stefan_ 7y ago
When Android was started, no embedded system of any kind used glibc. It's now 2019 and still none do. It's not GPL avoidance, it's just glibc being (a) huge (pain) for all the wrong reasons.
- andrekandre 7y ago
  what parts of glibc make it trouble for embedded systems? is it the way it uses memory? or just “too large”?
  - kllrnohj 7y ago
    glibc has a reputation for being bloated. Here's a post from 2002 of Linus complaining about it, for example: http://ecos.sourceware.org/ml/libc-alpha/2002-01/msg00079.html http://ecos.sourceware.org/ml/libc-alpha/2002-01/msg00079.ht... Independently of that glibc also has organizational issues. You see this in some major projects flipping back and forth on it, like Debian switching to EGLIBC in 2009 and then back to glibc in 2015. You continue to see this with the very slow (or outright rejection) adoption of new syscalls: https://lwn.net/Articles/655028/ https://lwn.net/Articles/655028/ It's important to remember glibc is not libc for Linux, and distinctly does not behave as such. If your platform is unapologetically Linux to the core, wouldn't you want something else that tracks the kernel API better? And it's not like Android was unique in not using glibc, either. The *BSD's don't, either.

CodeArtisan 7y ago

IIRC, Google copy/pasted code from Apache Harmony which wasn't legal itself. edit: http://www.groklaw.net/pdf3/OraGoogle-959.pdf http://www.groklaw.net/pdf3/OraGoogle-959.pdf "Two of the three questions from the jurors have focused on Apache, but the issue is actually very simple: Apache never obtained any license from Sun permitting its use of the Java specifications for Harmony. As made clear by Apache itself, Apache never had a license from Sun or Oracle for Harmony. Apache had no rights to Java technology that it could give to Google. This not even a case in which there is a “cloud over Apache,” to use the Court’s phrase (4/20/2012 Trial Tr. 1114:16-20). Apache simply had no title at all, and has publicly conceded as much: When Apache resigned from the JCP in protest based on its inability to obtain a license, it stated in its resignation that the “Java specifications are proprietary technology that must be licensed directly from the spec lead under whatever terms the spec lead chooses.” (TX 1045 at p. 2.) Thus, Google’s use of Apache Harmony provides no defense for Google. Oracle seeks an instruction to the jury that will prevent confusion and clarify that Google’s use of Harmony provides no defense to Oracle’s copyright infringement claims."

curt15 7y ago
>"When Apache resigned from the JCP in protest based on its inability to obtain a license..." Wasn't Apache seeking a license for a collection of tests, not the right to implement the API itself? And what, under Oracle's argument, would be the legal status of GNU GCJ/Classpath?
- monocasa 7y ago
  Apache was seeking the ability to access the tests, as passing those tests were the requirement to call it Java. Sun was using trademark (not copyright over API sequence structure and organization) to enforce this, sort of how Firefox does. I'd imagine that Oracle sees GCJ/classpath as infringing, but there's not enough money in enforcing that to be worth it. That's all gut feeling though, and I don't know of any information that'd let us confirm one way or another.