in part they seem to be claiming copyright on the java api. is that possible?
some other examples come to mind: wine's implementation of the windows api, various unices/linux implementing the unix api (but maybe there's some waiver here?), and so on.
Among SCO's myriad claims, they alleged Linux violates its copyright over the SysV APIs and ABIs. I doubt the court got around to addressing that issue.
If the above is correct, then under Oracle rules re-writing an API would be copyright infringement?
Not only would this restrict the ability to write alternatives to an API, but would effectively disallow code which is 100% yours from being run against an '''invalid''' "API". (I guess this is the Java trap RS defined?)
Some one should copyright println()or sprintf().
I have wanted to like the JVM for 10+ years, and now that technically it's in a good place for server-side code, looks like there is a battle over whether it is going to be "open" or not.
My opinion (without knowing enough about this situation in particular I'm afraid):
API's are "public" interfaces and an instrument for free speech. To restrict the use of an API goes beyond protecting the author of the API.
Many coders may not know Google wrote its own implementation, (or modified the original) and the "Java" brand and Java marketplace has been complicated. However, complexity is unavoidable and necessary when working with complex systems.
Company A makes bolt X (a patented bolt). Any company can make nuts. Company B makes a very different size bolt (Y) that is designed to use some of the nuts that fit bolt X. The bolt was not copied, but the diameter and threading is the same, by design.
In the US, 17 USC 101 lays out what can be subject of copyright. 17 USC 101(b) says that:
In no case does copyright protection for an original work of
authorship extend to any idea, procedure, process, system,
method of operation, concept, principle, or discovery,
regardless of the form in which it is described, explained,
illustrated, or embodied in such work.
I believe most legal scholars and most courts that have considered the matter have concluded that this means APIs are not subject to copyright.
On the other hand, we need to keep in mind that what actually constitutes an API is more limited than what we see in, say, a header file or interface definition file or whatever a particular language uses to define APIs.
Consider for example an API described in C that takes 4 parameters and returns one result. In the function prototype in the header, those parameters can be given descriptive names, and the types might be described by descriptive typedefs, and there might be a comment describing in detail what the function does, restrictions on the range of parameters, and so on. Suppose all 4 parameter's types actually end up being ints, once you work through all the typedefs. Same for the return type.
One could reasonably argue that this is the API:
int foo(int, int, int, int)
where "foo" is the name of the function, because in C that's all you need to know to call the function. All the typedefs, the optional names in the prototype, and the comment are not part of the API (since they aren't required to use the function). The typedef names, the parameter names in the original header file, and so on, could be seen as copyrightable elements that go beyond the API.
To be copyrightable, though, there must be some creativity. If your header file described the interface to your sin() function as "double sin(double x)", I don't think you could claim any copyright on choosing "x" for the dummy variable name, because "x" is a pretty normal dummy variable in mathematics. I suspect most dummy variables would suffer from this problem as far as being subject to copyright goes, but I wouldn't make a blanket claim to that effect because conceivably one could pick one's variable names in a sufficiently creative way to qualify.
Anyway, to sum it all up, it is going to come down to (1) what is necessary to actually implement the APIs in question, and (2) whether anything taken beyond that is sufficiently creative to be subject to copyright.
Claiming direct copyright on an interface is not the only way to try to control what people do with your interface. Many years ago, this situation arose: there existed a library, call it library Foo, to accomplish a certain task. There also existed another library, call it library Bar, to accomplish that same task. Foo and Bar were written by different groups, and had completely different interfaces.
Someone wrote a program (free software, distributed only in source form, if I recall) that among other things needed to do that task that Foo and Bar provided. The author of this program made it so that it could use either Foo or Bar. He distributed neither of these libraries with his program. You were meant to use whichever was already on your system, or obtain the other one if you preferred that one. All he had in his code was code that could be conditionally compiled for either. E.g.,
and similar at the places where he needed to do the tasks that these libraries supported. Both Foo and Bar were distributed under open source licenses (Foo under GPL, Bar under a BSD license).
The program also made use of a third library, which was a non-free library (in the free software sense) available as a free binary-only download from its developer.
The owners of Foo objected. They claimed that the program was violating GPL because that third party library was not licensed under a GPL-compatible license. This caused some confusion, as it would seem that the the program is not including any GPL code. All it actually has from Foo is the names of some functions from Foo, in the places where it does:
#if USING_FOO
x = some_foo_function(y, z);
#endif
#if USING_BAR
x = some_bar_function(y, z);
#endif
GPL is based on copyright--if you aren't doing anything that requires permission of the owner of some GPL code, you aren't subject to GPL. Writing code that says "some_foo_function(y,z)" does not require permission of the owner of the library that implements that function, unless the API itself is copyrighted and simply using the API requires permission.
Thus, it seemed that the owner of Foo was claiming a copyright on the interface to their library!
Later, they clarified their position. Their copyright theory was that when people obtained the source of the program and were given the choice of building the program to use Foo or Bar, some would choose Foo, and then go to Foo's site and download it. Thus, distributing the source code of a program that is capable of optionally using Foo will cause some copies of Foo to be distributed--and that makes distributing the program count as distributing Foo, and hence the program must obey GPL.
After much argument, the author of the program finally wrote a new library, Foo2, which provided the same API as Foo, but provided a different, public-domain implementation of the functionality. It wasn't a serious implementation--it used very inefficient algorithms. However, that satisfied the Foo owners, because now someone who chose to compile the program with USING_FOO defined might use Foo2 instead of Foo, so you couldn't say that the program was definitely inducing people to download Foo.
(This was pretty ridiculous. If X infringes Y's copyright, and then Z is created after X and Y, Z cannot affect whether or not X infringes Y's copyright. The creation of Foo2 cannot have any legal effect on the copyright relationship of the program and Foo).
(The Foo people could have tried to argue contributory infringement. That happens when party X does something that causes party Y to infringe party Z's copyright. This was one of the theories that was attempted against Sony in the Betamax case--the argument was that people who bought Betamax units were using them to infringe copyright, so Sony should be liable for contributory infringement. Two things are required for contributory infringement. One is that there is direct infringement. If Y is not infringing, then there cannot be contributory infringement. The other is that there be no substantial non-infringing uses of what X is doing. For Betamax there were plenty of non-infringing uses possible, and the court also ruled that time-shifting, one of the things the plaintiffs were saying infringed, was fair use. In the case of the Foo library, there is no direct infringement because GPL allows users to do pretty much whatever they want on their own systems, including using GPL code with non-GPL code, as long as they aren't distributing. No direct infringement by the user means no contributory infringement by anyone else).
Anyway, the point of the Foo/Bar example (which got a bit out of hand--I didn't mean to go into so much detail and take up so much space!) is that there are other ways besides a direct copyright on an interface that someone might try to control use of an API.
Copyright applies to things that express creativity. But also it does not apply to things which are strictly dictated by technical/compatibility requirements, even if they originated as an expression of creativity. So editline, Wine, Linux, Dalvik, and dynamic linking should all be OK (unless there's internal copying beyond what's needed to externally conform to the ABI/API).
some other examples come to mind: wine's implementation of the windows api, various unices/linux implementing the unix api (but maybe there's some waiver here?), and so on.