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).
To start, I'll say that I think Oracle has damaged their Java brand with their lawsuit. I have no idea how things will end up in courts, but that is another matter. What Oracle is accusing Google of having done is hardly comparable to what thousands of programmers, myself included, have done in thousands of Java projects over the years. I understand the skepticism and doubts about the direction of Java under Oracle's guidance, but I certainly don't have any fears about using Java as I have been.
I don't think Oracle particularly cares about the Java brand.
The Java brand was important to Sun because in recent years its value had eclipsed the value of the Sun brand, to the extent that they even renamed their stock ticker 'JAVA'. They poured resources into Java and Java-related projects because it was all that was keeping the ailing company relevant.
Oracle has no such problem with its brand. The company hasn't a great reputation as a philanthropist, and you have to look at what Oracle can get out of its ownership of Java. Those things are (a) exploiting the Intellectual Property, and (b) maintaining support for Oracle's own Java products.
Being a 'good steward of the language' is only important if it serves one of those two goals: i.e. if it improves Oracle's products, helps existing paying Java licensees, or creates opportunities for Oracle to license Java IP.
I'm not sure this is a healthy way for a programming language to be maintained.
Why didn't google go with more open technologies? They wrote the fastest javascript interpreter and they couldn't figure out how to use it in their phones for app development. I guess Java has more libraries and whatnot but honestly how many apps make any real use of them.
It wasn't Google who made the decision to use Java. What we today know as Android OS was developed by Android, Inc (purchased by Google in 2005). Android, Inc. was led by Andy Rubin and their technology was essentially the same as the technology used in his previous startup, Danger Inc, started in 2002.
Decision to use Linux for the kernel and Java as a language for user space programs was therefore made in 2002 and at the time it was a very sensible decision.
V8 was released 6 years later and even today JavaScript is extremely bare bones as a language and wrt. to base libraries (only recently there has been a push to standardize on basic things like file support, modules etc.).
As such JavaScript is not capable enough to write many kinds of programs one would like to write. Not today and definitely not in 2002.
Additionally, Dalvik Java VM in Android is much better tuned for constrained, low memory, low power mobile devices than V8, which was designed for desktop class computer. Technically it's a better solution for the target devices than V8.
"Decision to use Linux for the kernel and Java as a language for user space programs was therefore made in 2002 and at the time it was a very sensible decision".
And when they failed to come to terms with Sun to license JavaME, they could have revisited that decision, especially considering that they essentially threw out the Android UI when iPhone came out and changed everyone's notion of what a smartphone should like. Android post-iPhone looks and acts nothing like Android pre-iPhone.
Even if they kept their code in Java, they could have made it so that the official way to write third-party applications was to write native code. That would have given them the flexibility of migrating away from Java without impacting third parties in the case of future problems over Java intellectual property.
"As such JavaScript is not capable enough to write many kinds of programs one would like to write. Not today and definitely not in 2002".
What kind of program for a mobile device would Javascript today not be capable of?
Handling binary files? The language itself is fine but some support for special things is still lacking. But that's changing fast, in the future it would be an ok choice.
Your point about being fine tuned for low memory+power devices is spot on. Each app process on an Android phone is given 16mb of native heap space to play with - it's a lot for some functions but requires disciplined memory use to write stable apps (sorely lacking still).
Google utilized Apache Harmony, which is a clean room implementation of Java. I guess it'd be best to read the actual complaint, and look at the code in question, but this seems to be a real shot across the bow of Apache.
That is definitely true..
Java is one of the languages I really like, and now Oracle forces out the father of Java, James Gosling.
And they didnt even treat him nice..
Yeah it's really annoying to have to give them any info just to download the JDK. Ugh, and I started to really like clojure. I don't want to have to go the Mono way.
Dunno....looking at the code examples , particularly PolicyNodeImpl.java looks like they where simply converted straight from the original code. There is simply no way the Google code was not copied/generated from the Sun code.
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.