3 ms·

Copying anything is “obvious” given the source material. Your arguing against all forms of copyright not just Software interfaces.

jayd16 7y ago
You can often reimplement a function body in a way that happens to be the exact way another person implimented the method. There's only so many ways to count the size of an array. That does not mean you're committing copyright infringement. Google has shown that they did not copy the bodies verbatim so its down to the API. There happens to only be a single way to write the method signatures of a compatible method.
- tsimionescu 7y ago
  > There happens to only be a single way to write the method signatures of a compatible method. That's not actually true. For example, all of the following method headers are compatible: void foo(int a) throws Exception void foo(int x) throws IOException void foo(int index) throws RuntimeException Sure, this is a technicality, but it is not completely irrelevant. However, the whole discussion is moot, because Google had no intention of being compatible with anything, as shown by the fact that there is no real-world Java program that runs as-is on Android. Also, copyright only applies to actual copies of the original work. Google could have done a clean-room redesign of the Java API starting from Java programs, they could have arrived at the same API that they have today, and could not have been successfully accused of copying.
  - jayd16 7y ago
    Many of the method parameter names are indeed changed in this situation. Changing the thrown exception is an incompatible change in Java. >However, the whole discussion is moot, because Google had no intention of being compatible with anything, as shown by the fact that there is no real-world Java program that runs as-is on Android. The vast majority of Java code runs on perfectly well in Android. APKs are packaged differently than JARs but that's a different discussion. >Also, copyright only applies to actual copies of the original work. Google could have done a clean-room redesign of the Java API starting from Java programs, they could have arrived at the same API that they have today, and could not have been successfully accused of copying. This is what they did. Oracle's argument is that a clean room implementation of the Java API is also copyright infringement.
    - tsimionescu 7y ago
      > Changing the thrown exception is an incompatible change in Java. Not if you're throwing a more specific exception. So the second and third methods are compatible with the first one, but not the other way around. > The vast majority of Java code runs on perfectly well in Android. The vast majority of Java applications use features not available on Dalvik, ever-changing though the vast majority of their code would indeed run. > This is what they did. Oracle's argument is that a clean room implementation of the Java API is also copyright infringement. They did a clean-room implementation by looking at the specification of the Java API. They did not reverse-engineer the API from working programs or from decompiled binaries, and are not claiming that they did. If they had, you would have probably seen minor differences in parameter names, thrown exceptions and a few other places.
      - jayd16 7y ago
        >Not if you're throwing a more specific exception. So the second and third methods are compatible with the first one, but not the other way around. These are public classes and third party code will have overridden the original exception and not your subtype. This would break compatibility. You cannot change the types of these signatures in either direction.

jayd16 7y ago

You can often reimplement a function body in a way that happens to be the exact way another person implimented the method. There's only so many ways to count the size of an array. That does not mean you're committing copyright infringement. Google has shown that they did not copy the bodies verbatim so its down to the API. There happens to only be a single way to write the method signatures of a compatible method.

tsimionescu 7y ago
> There happens to only be a single way to write the method signatures of a compatible method. That's not actually true. For example, all of the following method headers are compatible: void foo(int a) throws Exception void foo(int x) throws IOException void foo(int index) throws RuntimeException Sure, this is a technicality, but it is not completely irrelevant. However, the whole discussion is moot, because Google had no intention of being compatible with anything, as shown by the fact that there is no real-world Java program that runs as-is on Android. Also, copyright only applies to actual copies of the original work. Google could have done a clean-room redesign of the Java API starting from Java programs, they could have arrived at the same API that they have today, and could not have been successfully accused of copying.
- jayd16 7y ago
  Many of the method parameter names are indeed changed in this situation. Changing the thrown exception is an incompatible change in Java. >However, the whole discussion is moot, because Google had no intention of being compatible with anything, as shown by the fact that there is no real-world Java program that runs as-is on Android. The vast majority of Java code runs on perfectly well in Android. APKs are packaged differently than JARs but that's a different discussion. >Also, copyright only applies to actual copies of the original work. Google could have done a clean-room redesign of the Java API starting from Java programs, they could have arrived at the same API that they have today, and could not have been successfully accused of copying. This is what they did. Oracle's argument is that a clean room implementation of the Java API is also copyright infringement.
  - tsimionescu 7y ago
    > Changing the thrown exception is an incompatible change in Java. Not if you're throwing a more specific exception. So the second and third methods are compatible with the first one, but not the other way around. > The vast majority of Java code runs on perfectly well in Android. The vast majority of Java applications use features not available on Dalvik, ever-changing though the vast majority of their code would indeed run. > This is what they did. Oracle's argument is that a clean room implementation of the Java API is also copyright infringement. They did a clean-room implementation by looking at the specification of the Java API. They did not reverse-engineer the API from working programs or from decompiled binaries, and are not claiming that they did. If they had, you would have probably seen minor differences in parameter names, thrown exceptions and a few other places.
    - jayd16 7y ago
      >Not if you're throwing a more specific exception. So the second and third methods are compatible with the first one, but not the other way around. These are public classes and third party code will have overridden the original exception and not your subtype. This would break compatibility. You cannot change the types of these signatures in either direction.