4 ms·

I'm going to go out on a limb here. While I'm definitely not on Oracle's side for this case, I'm not so sure I agree with the statement that declaring code is n

I'm going to go out on a limb here. While I'm definitely not on Oracle's side for this case, I'm not so sure I agree with the statement that declaring code is not code in general. To me, that's akin to the NSA collecting phone call metadata and then claiming that it's not really a problem because they don't actually have the contents. Except, as we know, with sufficient metadata, you don't even need contents to figure out what's going on. The same goes with APIs. With sufficiently comprehensive APIs or sufficiently advanced programming language facilities, which are becoming more and more commonplace (more sophisticated static type checking, macros, and template metaprogramming), more and more information becomes encoded in the declarations, to the point where you really can't claim that the declaration isn't something you should be able to copyright. With the Java API under consideration I agree that the APIs probably shouldn't fall under copyright, but I'm not sure I agree with this precedent being set here more generally.

deleted 10y ago
[deleted]
dpark 10y ago
>more and more information becomes encoded in the declarations I don't see how this is true at all. We've moved continually toward higher-level APIs. There's a lot more "magic" in String.split than strtok. If your API is so specific that the implementation is entirely implied by the declaration, then all that means is that the implementation itself is trivial, in which case I don't think your API implementation should copyrightable either.
- cmdkeen 10y ago
  But it isn't a single function definition it is the whole API. Deciding that you want to pitch your API at a specific level of abstraction and ensuring that level is consistently maintained across a whole language is hard work. The recent criticisms of ASP.Net Core's API changes or PHP's "interesting" APIs over the years surely demonstrate that writing language APIs is hard.
  - dpark 10y ago
    Sure. Coming up with a good recipe is also hard, but recipes are not copyrightable. Difficult does not always imply copyrightable.
gilgoomesh 10y ago
The NSA are collecting private metadata, that's the problem there. The Java APIs are public information (everyone who creates Java programs needs a copy of them and needs to know what they do).
- wfunction 10y ago
  This had nothing to do with privacy... I think you missed the point of the analogy?
deleted 10y ago
[deleted]
TimMeade 10y ago
I would disagree on that declaring code is not code. If I declare my api uses a GET to /user/:id to get a user, does that interfere with someones copyright that has an api that uses a GET to /user/:id to get a user (everyone I think)? This is just a declaration. The actual code is buried in the methods and means that actually GET the user. This is not quite what is going on with this trial, but it's a very simplistic version. If we can't use the same declared API end points, then it will be much worse than patent trolls. Tim
Jtsummers 10y ago
Depending on perspective (and perhaps language), I've come across the analogy comparing this to having a book with the same (mostly generic) table of contents. Though a ToC can be copyrighted. Imagine the situation of a physics text where there may be only a handful of reasonable ways to break down the information and order it. Would it be reasonable to sue someone for having the same ordering (deliberately in this case), but with the content rewritten from scratch (ideal since Google does have those 9 offending lines).

deleted 10y ago

[deleted]

dpark 10y ago

>more and more information becomes encoded in the declarations I don't see how this is true at all. We've moved continually toward higher-level APIs. There's a lot more "magic" in String.split than strtok. If your API is so specific that the implementation is entirely implied by the declaration, then all that means is that the implementation itself is trivial, in which case I don't think your API implementation should copyrightable either.

cmdkeen 10y ago
But it isn't a single function definition it is the whole API. Deciding that you want to pitch your API at a specific level of abstraction and ensuring that level is consistently maintained across a whole language is hard work. The recent criticisms of ASP.Net Core's API changes or PHP's "interesting" APIs over the years surely demonstrate that writing language APIs is hard.
- dpark 10y ago
  Sure. Coming up with a good recipe is also hard, but recipes are not copyrightable. Difficult does not always imply copyrightable.

gilgoomesh 10y ago

The NSA are collecting private metadata, that's the problem there. The Java APIs are public information (everyone who creates Java programs needs a copy of them and needs to know what they do).

wfunction 10y ago
This had nothing to do with privacy... I think you missed the point of the analogy?

deleted 10y ago

[deleted]

TimMeade 10y ago

I would disagree on that declaring code is not code. If I declare my api uses a GET to /user/:id to get a user, does that interfere with someones copyright that has an api that uses a GET to /user/:id to get a user (everyone I think)? This is just a declaration. The actual code is buried in the methods and means that actually GET the user. This is not quite what is going on with this trial, but it's a very simplistic version. If we can't use the same declared API end points, then it will be much worse than patent trolls. Tim

Jtsummers 10y ago

Depending on perspective (and perhaps language), I've come across the analogy comparing this to having a book with the same (mostly generic) table of contents. Though a ToC can be copyrighted. Imagine the situation of a physics text where there may be only a handful of reasonable ways to break down the information and order it. Would it be reasonable to sue someone for having the same ordering (deliberately in this case), but with the content rewritten from scratch (ideal since Google does have those 9 offending lines).