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.
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.
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.
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.
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.
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..
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.
[+] [-] dododo|15 years ago|reply
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.
[+] [-] tzs|15 years ago|reply
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 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:
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.
[+] [-] andrewf|15 years ago|reply
[+] [-] tbrownaw|15 years ago|reply
[+] [-] davidw|15 years ago|reply
I don't see too much about the copyright claims in here, though.
[+] [-] olefoo|15 years ago|reply
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.
[+] [-] noarchy|15 years ago|reply
[+] [-] greenlblue|15 years ago|reply
[+] [-] kkowalczyk|15 years ago|reply
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.
[+] [-] davidw|15 years ago|reply
[+] [-] spot|15 years ago|reply
[+] [-] jawee|15 years ago|reply
[+] [-] nkassis|15 years ago|reply
[+] [-] unknown|15 years ago|reply
[deleted]
[+] [-] rexyo|15 years ago|reply
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..
[+] [-] eldenbishop|15 years ago|reply
You can view the example here ->
http://www.scribd.com/doc/40316099/orclgoogcode
[+] [-] cshekhar|15 years ago|reply
[+] [-] bhiggins|15 years ago|reply
[+] [-] yvombinator|15 years ago|reply
i thought google already completely trashed their claims in quite harsh words
[+] [-] known|15 years ago|reply