4 ms·

> Google didn't copy any of Oracle/Sun's Java source code base into Android Java. Oracle lawyers acknowledge this. You're saying the textual contents of the in

> Google didn't copy any of Oracle/Sun's Java source code base into Android Java. Oracle lawyers acknowledge this. You're saying the textual contents of the interfaces that define the APIs are not part of the source code base? Of course Google copied them, or a nearly identical paraphrase of them. I'm not quite sure what Google's legal theory is. Listening to the oral arguments this morning certainly didn't make that more clear to me. But I don't think it includes redefining what we mean by copying text. And interfaces, in common parlance, are certainly lines of code. Nor do I think Oracle's argument is that no one else can define interfaces that use the same words as in the Java standard library interfaces. read, write, get, put, etc. did not become Oracle's property by virtue of them being used as method names. I have a bit of trouble with the concept "the threshhold of too much", too, as it applies to this case. Google copied or paraphrased essentially _all_ of the text of interfaces they used from Java libraries.

AnimalMuppet 6y ago
> You're saying the textual contents of the interfaces that define the APIs are not part of the source code base? Of course Google copied them, or a nearly identical paraphrase of them. Well, they aren't part of the implementation, since they just describe the interface. Google's theory is that interfaces, being needed for interoperability, are not protected by copyright. Google's alternate theory is that, even if they are protected by copyright, using them is fair use.
salawat 6y ago
>I have a bit of trouble with the concept "the threshhold of too much", too, as it applies to this case. Google copied or paraphrased essentially _all_ of the text of interfaces they used from Java libraries Oracle is trying to argue that just because you intentionally left a bunch of implementation detail out because it isn't relevant toward transforming something like the Java API's to a new context, it should still count as copyright infringement because they Still yoinked everything they did take... Which seems circular to me. Google's point is "no shit, Sherlock, it wouldn't be Java otherwise." Oracle is couching this issue from the perspective that Google should have invented a completely New language and runtime, absorbing the same costs of them doing so. Google argues, on the other hand, that what they made, in order to confer to the syntactic structure of the programming language known as Java, dictates the duplication of the organization of the fundamental functions, packages, and namespaces, and that furthermore, Oracle has no standing to call them on it, because those APIs are a necessary prerequite to drive the operation of the JVM, and are by definition the only way to do it, so that API constitutes a method of operation.
- thu2111 6y ago
  Oracle's argument isn't legally circular or anything like that. It's actually very strong, which is why it's problematic: the industry status-quo consensus that you can't copyright APIs has no obvious basis in copyright law beyond the notion that you can't copyright "facts". Is an API a collection of facts? I would hate to be a lawyer tasked with arguing this one in front of the Supremes. Programmers sweat bullets over API design, an API is very obviously not a mere collection of facts, it's a creative work. Copyright law protects creative works. Hence, Google's problem. An API is not a mere collection of names either. The Java API is defined by the specification, which is contained in the JavaDocs. Thread safety rules, when callbacks are invoked, what sub-types can be passed into a parameter, all these are a part of the API as well. Strip out the source code of the methods but leave the types, prototypes and JavaDocs and you have the Java API - it's been done and the result is still huge. Google's point is essentially one of convenience; the industry has never recognised APIs as copyrightable before and shouldn't now. This is not a legal argument at all so I am mostly expecting Oracle to give them a solid thrashing, because the SC is meant to interpret existing law, not simply agree to whatever one of the parties thinks the law should be. And other than declaring API reimplementation to be fair use, there's no obvious legal escape route to make APIs non-protected. It's thus interesting to consider what happens if or when Oracle win. In the short run a lot of disruption, especially to projects like Wine and maybe WSL. In the long run it's harder to say. Something unprotectable would have become protectable. We might see, for example, the birth of companies that specialise in nothing except API design. Today such a company would be unviable because there'd be no way to protect or own the results. You can imagine that this would occur in the same way that specialised agencies do graphics design, translation, logo design, API implementations, etc. This might lead to higher quality APIs across the industry: a difficult to anticipate side effect of expanding IP protection. It would also presumably reduce competition as it became even harder to compete with lockin via reimplementation of APIs. However, doing that is relatively rare today. I can't say for sure that the (small) loss of plug-compatible competing implementations of products would be worse than a hypothetical increase in API quality from allowing specialisation in it.
  - curt15 6y ago
    >In the long run it's harder to say. The easiest solution if the software industry wants to preserve the status quo is to just lobby Congress to amend the laws to explicitly distinguish interfaces from implementations.

AnimalMuppet 6y ago

> You're saying the textual contents of the interfaces that define the APIs are not part of the source code base? Of course Google copied them, or a nearly identical paraphrase of them. Well, they aren't part of the implementation, since they just describe the interface. Google's theory is that interfaces, being needed for interoperability, are not protected by copyright. Google's alternate theory is that, even if they are protected by copyright, using them is fair use.

salawat 6y ago

>I have a bit of trouble with the concept "the threshhold of too much", too, as it applies to this case. Google copied or paraphrased essentially _all_ of the text of interfaces they used from Java libraries Oracle is trying to argue that just because you intentionally left a bunch of implementation detail out because it isn't relevant toward transforming something like the Java API's to a new context, it should still count as copyright infringement because they Still yoinked everything they did take... Which seems circular to me. Google's point is "no shit, Sherlock, it wouldn't be Java otherwise." Oracle is couching this issue from the perspective that Google should have invented a completely New language and runtime, absorbing the same costs of them doing so. Google argues, on the other hand, that what they made, in order to confer to the syntactic structure of the programming language known as Java, dictates the duplication of the organization of the fundamental functions, packages, and namespaces, and that furthermore, Oracle has no standing to call them on it, because those APIs are a necessary prerequite to drive the operation of the JVM, and are by definition the only way to do it, so that API constitutes a method of operation.

thu2111 6y ago
Oracle's argument isn't legally circular or anything like that. It's actually very strong, which is why it's problematic: the industry status-quo consensus that you can't copyright APIs has no obvious basis in copyright law beyond the notion that you can't copyright "facts". Is an API a collection of facts? I would hate to be a lawyer tasked with arguing this one in front of the Supremes. Programmers sweat bullets over API design, an API is very obviously not a mere collection of facts, it's a creative work. Copyright law protects creative works. Hence, Google's problem. An API is not a mere collection of names either. The Java API is defined by the specification, which is contained in the JavaDocs. Thread safety rules, when callbacks are invoked, what sub-types can be passed into a parameter, all these are a part of the API as well. Strip out the source code of the methods but leave the types, prototypes and JavaDocs and you have the Java API - it's been done and the result is still huge. Google's point is essentially one of convenience; the industry has never recognised APIs as copyrightable before and shouldn't now. This is not a legal argument at all so I am mostly expecting Oracle to give them a solid thrashing, because the SC is meant to interpret existing law, not simply agree to whatever one of the parties thinks the law should be. And other than declaring API reimplementation to be fair use, there's no obvious legal escape route to make APIs non-protected. It's thus interesting to consider what happens if or when Oracle win. In the short run a lot of disruption, especially to projects like Wine and maybe WSL. In the long run it's harder to say. Something unprotectable would have become protectable. We might see, for example, the birth of companies that specialise in nothing except API design. Today such a company would be unviable because there'd be no way to protect or own the results. You can imagine that this would occur in the same way that specialised agencies do graphics design, translation, logo design, API implementations, etc. This might lead to higher quality APIs across the industry: a difficult to anticipate side effect of expanding IP protection. It would also presumably reduce competition as it became even harder to compete with lockin via reimplementation of APIs. However, doing that is relatively rare today. I can't say for sure that the (small) loss of plug-compatible competing implementations of products would be worse than a hypothetical increase in API quality from allowing specialisation in it.
- curt15 6y ago
  >In the long run it's harder to say. The easiest solution if the software industry wants to preserve the status quo is to just lobby Congress to amend the laws to explicitly distinguish interfaces from implementations.