5 ms·

EFF Stands With Innovative Developers in the Wake of Oracle v. Google

50 points by ScottWRobinson 11y ago

deleted 11y ago
[deleted]
rhino369 11y ago
While I'm not sure how I stand on Oracle v. Google, I don't really agree with EFF's legal analysis here. Nothing in that case suggests that using an API is infringement. It's about re-implementing an API for a different purpose. So using Twitters API is fine, but copying Twitters API for use on a Twitter clone service, not fine. I also don't think this case necessarily prevents re-using an API for interoperability. The case was about Google reimplementing Java API for use in the android davlik engine. That really isn't interoperability since Java wouldn't run on it. They just copied some java apis for the convenience of android programers. Pardon my ignorance but is that really common in the programming world? To take someones API and use it for a totally different purpose?
- abecedarius 11y ago
  That really isn't interoperability since Java wouldn't run on it. A Java package I wrote in 1996 is used in Android apps. So they had to recompile it or something, I don't know.
- fredgrott 11y ago
  using calls in an api for a different purpose is not copying by legal def of copyright law
  - rhino369 11y ago
    I didn't mean using, I meant copying the API itself to re-implement in a different piece of software.
- r0naa 11y ago
  It happens all the time, and that's a good thing. > Twitters API for use on a Twitter clone service, not fine. That's precisely what's bothering me the most. This is completely contingent on your definition of what is an API. The judgement is setting a precedent in defining an API by its routes and not by what or how it processes data. To the court, it does not matter if you are doing data intensive computations or just stripping html from a string... if the route is the same you are screwed. HTTP/1.1 GET /v1/news/latest_updates becomes intellectual property of Company Inc. Imagine the amount of patent trolling wars that are going to be waged because of that ruling, what a freaking nightmare. PS: The parent comment should not be downvoted. - I come to HN to hear people's opinions and learn from them, even if they are dissenting. It's fine to disagree, but do not silence people for thinking differently. Every constructive contribution should be part of the discussion.
  - rhino369 11y ago
    Again, pardon my ignorance, my only attempt at API use resulted in a very poorly programmed python app that was supposed to tell me which train to take . . . but isn't that just using the HTTP/1.1 GET method? Just using someone else's API with a new paramter isn't an expressive action and clearly isn't copyrightable. But the court would say the HTTP/1.1 GET [url] api is copyrighted by whoever wrote the HTTP spec. The court didn't rule than ANY api is copyrightable. Just that the specific Java ones at issue where. For example, Copyright law has what is called the "merger doctrine" which essentially says that if there is only one or maybe a few ways to implement something, then it isn't copyrightable. So while you can copyright Microsoft Excel, you probably can't copyright a simple method that adds two intergers together. There is essentially only one way to do it. The Fed Cir. in Oracle rejected that argument because there are unlimited ways to implement the Java libraries API. Why did Google even call them java.XXXXXXX.XXXX when they could have been Android.XXX.XXX, etc. There is another doctrine that states that industry convention can't be copyrighted. GET is industry convention and would never be copyrightable. But the data structure it send back may or may not be.
    - wtallis 11y ago
      > " Why did Google even call them java.XXXXXXX.XXXX when they could have been Android.XXX.XXX, etc." That wouldn't be implementing the Java APIs any more, as evidenced by the fact that no code relying on the Java APIs would be able to compile against your hypothetical Android standard library. By the Java language's own definition, changing the package and class names makes it a different API.
- guelo 11y ago
  It happens. Just off the top of my head, recently Mozilla's Servo decided to copy Chrome's embedding API CEF.
SNvD7vEJ 11y ago
So, by implementing any of the interfaces, or extending any of the classes defined in the Java SE standard lib, I would be violating Oracle's copyright on Java. ;)

deleted 11y ago

[deleted]

While I'm not sure how I stand on Oracle v. Google, I don't really agree with EFF's legal analysis here. Nothing in that case suggests that using an API is infringement. It's about re-implementing an API for a different purpose. So using Twitters API is fine, but copying Twitters API for use on a Twitter clone service, not fine. I also don't think this case necessarily prevents re-using an API for interoperability. The case was about Google reimplementing Java API for use in the android davlik engine. That really isn't interoperability since Java wouldn't run on it. They just copied some java apis for the convenience of android programers. Pardon my ignorance but is that really common in the programming world? To take someones API and use it for a totally different purpose?

abecedarius 11y ago
That really isn't interoperability since Java wouldn't run on it. A Java package I wrote in 1996 is used in Android apps. So they had to recompile it or something, I don't know.
fredgrott 11y ago
using calls in an api for a different purpose is not copying by legal def of copyright law
- rhino369 11y ago
  I didn't mean using, I meant copying the API itself to re-implement in a different piece of software.
r0naa 11y ago
It happens all the time, and that's a good thing. > Twitters API for use on a Twitter clone service, not fine. That's precisely what's bothering me the most. This is completely contingent on your definition of what is an API. The judgement is setting a precedent in defining an API by its routes and not by what or how it processes data. To the court, it does not matter if you are doing data intensive computations or just stripping html from a string... if the route is the same you are screwed. HTTP/1.1 GET /v1/news/latest_updates becomes intellectual property of Company Inc. Imagine the amount of patent trolling wars that are going to be waged because of that ruling, what a freaking nightmare. PS: The parent comment should not be downvoted. - I come to HN to hear people's opinions and learn from them, even if they are dissenting. It's fine to disagree, but do not silence people for thinking differently. Every constructive contribution should be part of the discussion.
- rhino369 11y ago
  Again, pardon my ignorance, my only attempt at API use resulted in a very poorly programmed python app that was supposed to tell me which train to take . . . but isn't that just using the HTTP/1.1 GET method? Just using someone else's API with a new paramter isn't an expressive action and clearly isn't copyrightable. But the court would say the HTTP/1.1 GET [url] api is copyrighted by whoever wrote the HTTP spec. The court didn't rule than ANY api is copyrightable. Just that the specific Java ones at issue where. For example, Copyright law has what is called the "merger doctrine" which essentially says that if there is only one or maybe a few ways to implement something, then it isn't copyrightable. So while you can copyright Microsoft Excel, you probably can't copyright a simple method that adds two intergers together. There is essentially only one way to do it. The Fed Cir. in Oracle rejected that argument because there are unlimited ways to implement the Java libraries API. Why did Google even call them java.XXXXXXX.XXXX when they could have been Android.XXX.XXX, etc. There is another doctrine that states that industry convention can't be copyrighted. GET is industry convention and would never be copyrightable. But the data structure it send back may or may not be.
  - wtallis 11y ago
    > " Why did Google even call them java.XXXXXXX.XXXX when they could have been Android.XXX.XXX, etc." That wouldn't be implementing the Java APIs any more, as evidenced by the fact that no code relying on the Java APIs would be able to compile against your hypothetical Android standard library. By the Java language's own definition, changing the package and class names makes it a different API.
guelo 11y ago
It happens. Just off the top of my head, recently Mozilla's Servo decided to copy Chrome's embedding API CEF.

SNvD7vEJ 11y ago

So, by implementing any of the interfaces, or extending any of the classes defined in the Java SE standard lib, I would be violating Oracle's copyright on Java. ;)