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.
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.
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.
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).
"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.
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 cause...
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).
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.
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.
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.
28 comments
[ 3.6 ms ] story [ 40.5 ms ] threadDecision 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.
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?
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.
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.
Is this illegal?
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:
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 cause...
http://www.techeye.net/software/father-of-java-forced-out-by...
Oracle went on strangling Java by putting up registration forms everytime I want a clean JRE or JDK, asking me to leave all my details or to login...
Hang in there Java, you're in for a hell of a Oracle ride..
I don't see too much about the copyright claims in here, though.
The creation of this sort of legal uncertainty around a project that was open-source in name if not always in spirit is a concern though.
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.
i thought google already completely trashed their claims in quite harsh words
You can view the example here ->
http://www.scribd.com/doc/40316099/orclgoogcode