Hacker News Reader

Comment by simiones | Hacker News Reader

You are misinterpreting that argument. To prove copyrightability, Oracle had to show that designing an API is a creative act and not a purely mechanical/functional one. That is the purpose of this argument: if the function would only work if named java.lang.Math.max and not work if named Math.maximum, then anyone describing the same concept would be forced to use the same name, so the name wouldn't be copyrightable. They are not stating that Google would have been in the clear if they had named it differently, they are just trying to show that Google could have named it differently without changing the meaning of the code one iota.

For example, someone writing a recipe for omelette has to say "2 eggs" simply because that's what omelette needs. You can't express it any other way, so it's not a creative act, so it can't be protected by copyright.

View on HN

Java namespaces fall into the latter category, since there is an embedded graph of symbolic coordinates. The existence of Refactoring negates that it can be seen as an accidentally creative act.

Refactoring is somewhat similar to translation, and it similarly does nothing to affect the notion of copyright. A novel is copyright-able even though it can be mechanically translated into a different language.

The fact remains that APIs are creative works. This can also be seen from discussions about APIs in the industry - everyone knows that the Unix APIs are often seen as elegant while the Windows APIs are seen as ugly. The C++ people love the design of their iterators and algorithms and data structures and believe it is superior to Haskell's equivalents.

> everyone knows that the Unix APIs are often seen as elegant while the Windows APIs are seen as ugly

I think people consider the UNIX CLIs ("do one thing and do it well") to be elegant, not UNIX APIs. UNIX APIs have quite massive (and well-known) warts in them.

Sure, there is a lot of nuance - for example, the Unix CLI is very much seen as a kind of API, and appreciated mostly for API-level decisions (pipe-able commands, everything is a file, everything is text), not necessarily so much for CLI-level features (such as variable handling, looping etc.).

Also, some Unix OS APIs are much preferred over Windows alternatives - e.g. many people think fork()/exec() is much more elegant than CreateProcess(), same for pthreads vs the Windows threading model etc.

The bottom line though is that people have opinions about API design, it is clearly seen as a creative process, it is not rote technicality.

Designing an API is a creative act. An API is source code. Witness thousands of languages, all with recognizably different standard libraries, including languages like Go or Dart created by Google themselves. The problem is less with individual examples like "max" vs "maximum" or "write" vs "scribble", but more with thousands of packages, classes and methods, 99% of which have the exact names and structure as the Sun's Java ones. That is blatant theft. Google stole Java code from Sun. Shame on them.

What we need the law to do is to distinguish between copying a piece of code and using a piece of code. Just because I use your code doesn't mean you own my code too. What we need the software industry to understand is that relying on a proprietary library makes it impossible to cheaply switch your code to an alternative implementation without rewriting your own code. Alternatives exist: use software with an open license model, or shim out the proprietary library.

> The problem is less with individual examples like "max" vs "maximum" or "write" vs "scribble", but more with thousands of packages, classes and methods, 99% of which have the exact names and structure as the Sun's Java ones. That is blatant theft.

You know, it might be worth asking the engineer who wrote java.lang.Math how he came up with those names. Actually, you don't--he already answered it one of the amici briefs. The answer was that he took it from C.

In other words, taking Oracle's argument at face value means that the example API it is accusing Google of illegally copying is itself an illegal copy of the UNIX copyright, whoever actually owns that now.

Perhaps the Sun engineer did indeed copy from UNIX to some mild degree The line between "inspired from" and "copied from" is a fine line indeed. When does a term stop being proprietary and enter the vernacular of a specific profession or of humanity at large? I lean rather liberal on this question, and I hope the law will too. OTOH, what is blatant theft is for your 'original' work to overlap 99%, in both names and structure, to prior work. Google engaged in blatant theft, there is no doubt about it. We are not even talking about a derived work, we are talking about copying word for word a substantial part of somebody else's work.

Look up the names of the functions in java.lang.Math. They are exactly the names and semantics used in the libm functions. Even down to the presence of the atan2 function which computes tan¯¹(y / x).

(You could also point out that JavaScript literally lifts java.lang.Math and java.util.Date into JS code as well, down to Date.getYear returning the Gregorian year - 1900).

First, this is not a 99% blatant copy. I see things on the java side that are not in the libm side, like addExact, IEEEremainder or nextDown. I see things on the libm side that are not in the java package, like fpclassify, gamma or jN. I see things that have been adapted to match java conventions, like copySign vs copysign. The Jaccard similarity index appears to be pretty far from 1, whereas it is a perfect 1 in the case of Google. The perfect 1, up to keeping the 'java' in 'java.*', makes it a 'blatant theft' in the case of Google.

Second, unclear what the legal status of libm is. It appears to implement a standard, thus is legitimate to ask whether the set of implemented functions and their names are the original contribution of libm authors, or are derived from the standards. Generally, if one wants to implement a standard, one needs to acquire the rights to do so, usually in the form of a reasonable fee.

Third, if there are significant overlapping parts that are the creative work of libm authors, and they can establish a prior art claim, they are entitled to seek fair compensation from Sun / Oracle.

https://docs.oracle.com/javase/8/docs/api/java/lang/Math.htm...

https://sourceware.org/newlib/libm.html

PS. Re: atan2, wikipedia: 'The function atan2(y,x) first appeared in the programming language Fortran (in IBM's implementation FORTRAN-IV in 1961). It was originally intended to return a correct and unambiguous value for the angle θ in converting from cartesian coordinates (x, y) to polar coordinates (r, θ).' Perfect example of a term that arguably migrates into the common technical vocabulary over decades.

>I see things on the libm side that are not in the java package, like fpclassify, gamma or jN.

Which were added in C99, which postdates the initial release of Java.

Almost completely irrelevant side note: atan2 is immensely useful because it actually does more than calculate the arctangent. It handles all the corner cases in converting a 2d vector to an angle. There's no chance of division by zero, it gets the answer into the correct quadrant automatically, and so on. Those things add up to an annoying series of if statements if all you have is an arctangent function.

Reply on news.ycombinator.com