Slashdot Mirror
Oracle Subpoenas Apache Foundation In Google Suit
angry tapir writes "Oracle has subpoenaed the Apache Software Foundation in connection with its ongoing intellectual property suit against Google. Oracle filed suit against Google in August, alleging that its Android mobile operating system infringes on seven of Oracle's Java patents. Google has denied any wrongdoing. The subpoena, which was received by ASF on Monday, seeks 'the production of documents related to the use of Apache Harmony code in the Android software platform, and the unsuccessful attempt by Apache to secure an acceptable license to the Java SE Technology Compatibility Kit.'"
considering that apache is pretty openly documented, subpoena'ing them is probably mostly useless. I mean they could probably point Oracle to their own wiki.
Google didn't extend Java, and they didn't embrace it either. No Java program will run on Android. No Android program will run on a Java VM. Not even if you recompile them. You can do some code and library reuse, but that's about it.
Embracing and extending isn't usually a bad thing when the fork is open source.
In fact that's the whole point of open source.
(FYI basically the entire Android platform has been open source so far)
Mod me down, my New Earth Global Warmingist friends!
"Google has denied any wrongdoing. "
What else are they going to do?
saying, "Yeah we did it but suck balls Oracle! NYAHH NYAHH!" typically will upset a judge.
Do not look at laser with remaining good eye.
Strange... I didn't hear about Darl McBride joining the Oracle executive board.
Is Oracles attempt at suing Google to return the cost of buying Sun? and maybe making some money off of it too? /sigh
In what way is Google creating platform lock-in? I am not saying that they aren't, I just haven't read anything that suggests that they are (and I have read several stories that indicate they are spending extra money to ensure that users of some of their products are not locked in).
The truth is that all men having power ought to be mistrusted. James Madison
Good point! Nope, they're not! Which is why they documented the hell out of it, released it openly for anyone else to examine and implement, kept compatibility with the original language, only changed the underlying stuff, and made it perfectly clear this is an Android derivative of the language so as to not actually destroy Java.
I hope the court gets that documentation too.
Comment removed based on user account deletion
Code written for Android can't be run on another platform without rewriting large portions of the code. In essence, it's basically just the same sort of additions that Microsoft did and got tons of bad press about.
I wonder if anyone at Oracle realizes how they're continually mangling their image? I didn't ask if they care, simply if they realize it.
bzzt wrong!
You can go download the source to dalvik and use it on what ever platform you want. Blackberry is going to be doing just that.
So where is this source to the Microsoft JVM?
> MS were bad to embrace and extend Java to create platform lock-in. Google are good to do so, right?, Hazel Bergeron
When Google claims to own JAVA and demands royalties for JAVA running on Windows, then they'll be just as evil as Microsoft :)
MS Java extended java core. If Android extends net.google.foobar libraries and leaves the com.sun libraries alone, they aren't doing the same thing.
Embrace and extend isn't usually a bad thing, as long as it isn't embrace, extend and don't disallow anyone else from implementing a compatible extension.
The best documentation may be source code, and documenting the extension is a Really Good Thing if you depend on ISVs at all, but even the lack of documentation doesn't make embrace-and-extend a bad thing.
What makes embrace-and-extend a bad thing is disallowance of alternate implementation through general legal mechanisms like anti-reverse-engineering provisions in law, as well as specific legal mechanisms like patents.
tasks(723) drafts(105) languages(484) examples(29106)
Code written for Android can't be run on another platform without rewriting large portions of the code. In essence, it's basically just the same sort of additions that Microsoft did and got tons of bad press about.
Android application code really doesn't care where it's running. It's running on a VM after all. If someone ported Dalvik to another platform, Android apps would run there too. In fact RIM have done that already, porting Dalvik over QNX. If they can do it then it's clearly not proprietary or lock-in. I'd actually like to see Dalvik ported in this way since it would speed up development no end and might prove useful for other purposes
As for Microsoft's issues with Java, it's not the same at all. First Dalvik / Android are not Java. Never have been, never claimed to be. It's always been made explicitly clear that devs write with the Java language but the target is not a JVM.
You do not understand what lock-in is. If you are free to fork something, there is 0% chance that it has the capability to lock you in.
I am sure that Ellison has sleepless nights over that concern.
---- Booth was a patriot ----
My request is for an informed and knowledgeable slashdotter to point readers to a site that potentially debunks each one of Oracle's patent infringement claims.
MS were bad to embrace and extend Java to create platform lock-in.
Google are good to do so, right?
Demonstrate where Google was presenting an extended Java. Then explain how they were creating platform lock-in.
That's the worst analysis I've read in a while.
Anyone can implement anyone else's API/protocol, possibly by reusing code they supply under a permissive licence. The problem is that you have to actually do that with every platform you want to run your software on - and in every case it'll be a lot more work than just recompiling (to begin, which cross-platform lower level API are they using? oh...).
And because, in practice, that costs a lot of effort, proprietary extensions create lock-in.
And that's why we have hardware/software standards. Not because compatibility layers are impossible without them, but because things are more difficult, and you're always playing catchup.
A very big difference is that Microsoft presented what they did as Java. Google is not presenting Java, they're presenting Dalvik. And as others have noted, Dalvik is Open Source and is being ported to various non-Android platforms by various entities that are not Google.
Code written for Android can't be run on another platform without rewriting large portions of the code. In essence, it's basically just the same sort of additions that Microsoft did and got tons of bad press about.
How is that different from developing a Blackberry application?
J2android says otherwise. It has mysteriously vanished from the manufacturer's website, but there are videos of it in use and there are still copies floating around the intertubes. http://www.pcworld.com/businesscenter/article/192044/myriad_tool_converts_java_apps_for_android_phones.html
Get a web developer
SC/Oracle
From the SDK: All applications are written using the Java programming language.
A search +java +site:android.com will make it abundantly clear what Google is "presenting".
Second request addressed above.
You and several posters are being deliberately obtuse.
That's a conversion tool. Pyjamas will convert python to javascript. Does that mean Python programs will run on Spidermonkey? Thought not.
The soylentnews experiment has been a dismal failure.
Java the language is only tangentially related to the JVM.
Much like I have no issue with wanting to use C# because it has nice features, but have huge issues with wanting Mono unless and until MS makes a BINDING agreement not to sue over use of Mono.
It is different in that Blackberry will run Dalvik (Android Apps) code fairly shortly, where Android is not going to be running Blackberry Apps any time soon.
The GP is just ignorant about software, systems and progranmming
Agent K: A *person* is smart. People are dumb, stupid, panicky animals, and you know it.
Ahhhh... Some people just plain don't understand how Embrace, Extend and Extinguish works.
Java programming language is not the same as Java(the whole stack). Microsoft extended the same Java with own "features" that you could accidentally use. Android, however, extends Java in the same way as SpringFramework "extends" Java. You use it just another library in the language. Runtime however is something different.
And yes, Google is very much blunt that Android apps should be written in Java. Yet the part that counts was never called Java.
Oh wait... There is really no purpose in arguing with a person that knows nothing about those days...
You cannot run Android programs in a JVM, because while it is Java, it is not JVM. The difference is that the JVM and Dalvik are more like "compilers" than anything else, much like you can write a program in C and compile it for PPC or i86 using GCC or Intel or IBM compilers. However I doubt that your C code compiled by Intel Compiler will run on PPC architecture.
Java is a language.Oracle wants to assert control over the language because it has a "compiler" in the form of JVM. Good luck with that.
Agent K: A *person* is smart. People are dumb, stupid, panicky animals, and you know it.
This was already a complicated issue to explain to even those knowledgable with FOSS with all the differing licenses and requirements but now that the corporate lawyers from every major tech company in the world has gotten involved things will come to a standstill with everyone afraid of potential lawsuits for any new development or implementation utilizing FOSS as the starting point. The only positive thing I can see is if someone might be pressed to develop an entirely new framework (OS, DB, and development tools) that is not evolved from any exisiting work products. I know it's practically impossible but there might be someone with the brains to pull it off.
Who is going next?
Why?
tasks(723) drafts(105) languages(484) examples(29106)
And what did it look like?
From the SDK: All applications are written using the Java programming language.
A search +java +site:android.com will make it abundantly clear what Google is "presenting".
Excellent. You can use the Java language to program for Android. Now show me the Java VM that Google produced like Microsoft did. So far, the only VM I've seen mentioned is Dalvik.
Second request addressed above.
Not really, no. Google is not creating a Java VM that only works on Google devices. They are not claiming to implement Java and breaking compatibility with other Java environments. And even if you take offense to coding in Java for a Dalvik environment, anyone can take the Apache License Dalvik VM and port it to other platforms (which more than one entity is doing).
You and several posters are being deliberately obtuse.
I thought thats what you were doing. I mean - your nickname implies that. But lets not fall in to the trap of calling each other names while forgoing a good conversation on the issues at hand.
You make a very interesting point. There are similarities between Google's DalvikVM and Microsoft's JavaVM. But there are also some pretty stark differences as well. And I find it a stretch to imply Google is causing confusion in the Java application space, damaging the write-once / run-everywhere promise of Java, and creating a lock-in subset of Java in the process as did Microsoft.
The 5 letter swear word.
Why would it impede implementation? Android and the underlying Linux code has already attracted the attention of companies looking to make a fast buck by claiming patent or licensing violations by their competitors. When a corporation commits to using a certain technology they are potentially putting themselves at risk, especially if there are companies and individuals making patent claims against any of the technology they are using. Even if the claims are BS the company would still have to spend the money to fight back against the claims. If someone was to come up with a totally new OS and app stack that is not dependent in any current source code you could set a new baseline for determining prior work claims and patent violations. Sort of like starting over again and doing it right this time in regards to openess.
Blackberries use J2ME, which is as close to straight Java as you can get. It's true that there are custom RIM libraries available, but you can write a Blackberry app without every touching them and the resulting binary will run on any J2ME-compliant VM (even featurephones!)
Oracle is also suing Satan for patent infringement, as they seem to have acquired the rights to evil.
Now show me the Java VM that Google produced like Microsoft did.
This is a red herring. Developers don't write in bytecode so it doesn't matter whether the resulting binaries are slightly different or very different from standard.
If I build something Java-y but with MS extensions, it will work on the MSJVM but not on a standard Java VM.
If I build something Java-y but with Google extensions, it will work on Google's virtual machine but not on a standard Java VM.
Not really, no. Google is not creating a Java VM that only works on Google devices.
A VM is obviously written for a particular native platform, so I don't know what you mean here.
They are not claiming to implement Java
If you're implying that "the Java programming language" is not part of Java, then you're being intellectually dishonest. If you're implying that you don't "implement Java" unless you implement every single spec related to Java, then nothing "implements Java". What are you actually trying to say?
and breaking compatibility with other Java environments.
MS tools compiled standard Java source code and ran execute Java bytecode. The programmer could choose to use incompatible extensions. In a sense, this is better than what Google is offering, where AFAICT standard Java mobile libraries aren't properly implemented and you have to use non-standard extensions to get things working on Android.
Again, the choice of compiled executable format is irrelevant. Every developer can run a compilation script to produce an executable for various different platforms. What takes time and matters is whether the source must be changed
And even if you take offense to coding in Java for a Dalvik environment, anyone can take the Apache License Dalvik VM and port it to other platforms (which more than one entity is doing).
Yeah, because what we need is another non-standard where alternative implementations are always playing catchup. Thanks for illustrating the problem.
That's not the precise question. The precise question is, "why does the involvement of corporate lawyers from every major tech company in the world lead things to a standstill with everyone afraid of potential lawsuits for any new development or implementation utilizing FOSS as the starting point?"
Nothing you describe makes developing off of Linux, Android or other open-source or free-software products any more of a risk than it was a year ago, perhaps even two years ago. We've seen this pattern of events before, with SCO, but Linux kept growing. We've seen IP risks come into play with BSD, with AT&T being the plaintiff, but UNIX kept growing.
I have absolutely no doubt that, somewhere, the Linux kernel and/or minimal userland runtime infringes upon patents held by Microsoft, IBM, Intel, AMD, Google and others, but the most you see is Microsoft threatening to pull a trigger they've never dared to in the past. Why? Because the other big names would bring their own patent portfolios to bear on them, because all the big players except Microsoft and Apple heavily depend on Linux, and the world of patents is one giant pile of Mutually Assured Destruction.
The patent sea submariners won't be able to do any more damage than they've ever been able to do, and they're not interested in innovators; innovators are almost invariably too small of fish for them to care about.
tasks(723) drafts(105) languages(484) examples(29106)
Now show me the Java VM that Google produced like Microsoft did.
This is a red herring. Developers don't write in bytecode so it doesn't matter whether the resulting binaries are slightly different or very different from standard.
If I build something Java-y but with MS extensions, it will work on the MSJVM but not on a standard Java VM.
If I build something Java-y but with Google extensions, it will work on Google's virtual machine but not on a standard Java VM.
I don't think this is a red herring at all. In fact, I think this is the exact point. What's being coded is something "Java-y" in both cases. But in Microsoft's case, they were presenting it as writing for a Java VM. That implies everything that comes with a Java VM. Google presents it as writing for Dalvik. And while there are certainly similarities between a JVM and Dalik, there is little implication that the Java-y code you write for Dalik is going to work on any given JVM and visa versa.
Again, the choice of compiled executable format is irrelevant. Every developer can run a compilation script to produce an executable for various different platforms. What takes time and matters is whether the source must be changed
I think this highlights the difference. Is Google misleading developers in to thinking that what they code for Android is going to work on any given JVM? I don't think there's any such implication. And so someone coding for Dalvik is going to know that the promise of Java does not apply to this project.
And even if you take offense to coding in Java for a Dalvik environment, anyone can take the Apache License Dalvik VM and port it to other platforms (which more than one entity is doing).
Yeah, because what we need is another non-standard where alternative implementations are always playing catchup. Thanks for illustrating the problem.
Fair enough. I'm not saying what Google is doing is The Right Way. But the point here is that it's hardly lock-in as anyone can make a Dalik VM work anywhere because the code is available. That works against lock-in.
I am not saying the risks are any greater know then they were 2 or 3 years ago I am saying the patent lawsuits and counter claims have started to gain momentum. SCO had a weak case from the beginning and the courts clearly recognized that. There are claims being filed know that are just as dubious but what happens when Google loses their fight with with Oracle. What happens when the patent holding companies, companies with no stake in implementing the patented technology, begin getting favorable rulings? Most of the big companies have signed cross licensing agreements over the past couple of years in an effort to avoid legal entanglements and expense but that will be no protection against the patent factories. I don't suggest people stop using whatever they are using I just pointing out the increasing complexity and absurdity of the entire process.
It was in no way clear to the court in the beginning that SCO's case was weak. It was clear to us, but we were technical experts with no small degree of bias. It may have been clear to people in IT departments, but it wasn't have been clear to the people who control company's purse strings.
Cross-licensing agreements have been in place between big names for decades. AMD and Intel have them. Intel was in the habit of making them before AMD existed.
You don't need to worry about the likes of them. If they're large enough to have the need and clout to sign cross-licensing agreements, they're large enough that they can handle patent submariners. Even if they lose their court case and are ordered to pay, they'll go on doing what they were doing anyway; if they didn't expect to make money on it in the first place, they wouldn't have done it. Even if they're ordered to pay settlement fees, they'll still continue to make money.
There was just as much (even more) ambient fear 2-5 years ago as there is today, but it's really not something worth getting in a twist over. You really can't halt something like this, because for every big-name company that backs off, three more are waiting in the shadows to get in on the market.
tasks(723) drafts(105) languages(484) examples(29106)
Your argument now rests on the assumption that Microsoft was misleading developers that its extensions were part of standard Java.
Microsoft was never doing such a thing.
Moreover, it's fairly obnoxious to suggest that people developing using Microsoft solutions are all so dumb that they wouldn't be able to figure out that (e.g.) a call to the native Windows API is not cross-platform, even if MS had somehow tried to convince people of that. Which, again, they weren't doing.
What Microsoft was doing was enticing developers to use the non-standard extensions so they'd be able to choose Java as a language but end up with software that wasn't actually portable. Clearly Java was the fashionable new language, but Windows was the traditional desktop OS. So this method would rope in people whose skills and existing codebase was Java, as well as persuade those whose real knowledgebase was in the Windows API to never really leave Windows.
Some of this mirrors what Google are doing: leverage existing Java codebase and developers but require (not even just entice) them to use non-standard extensions so further work remains tied to their platform.
This is the danger of "embrace and extend", and this is what Google are doing. They're just much better than Microsoft at maintaining the odour of roses.
as above what a bunch of tossers
Your argument now rests on the assumption that Microsoft was misleading developers that its extensions were part of standard Java.
Microsoft was never doing such a thing.
Moreover, it's fairly obnoxious to suggest that people developing using Microsoft solutions are all so dumb that they wouldn't be able to figure out that (e.g.) a call to the native Windows API is not cross-platform, even if MS had somehow tried to convince people of that. Which, again, they weren't doing.
I agree that it's an obnoxious view. I don't believe all developers are "so dumb." But I do believe enough are. If it weren't so, we wouldn't have the problem with so many IE6-only web sites / apps. That is the world we were in back then and there's echoes of it still today.
What Microsoft was doing was enticing developers to use the non-standard extensions so they'd be able to choose Java as a language but end up with software that wasn't actually portable. Clearly Java was the fashionable new language, but Windows was the traditional desktop OS. So this method would rope in people whose skills and existing codebase was Java, as well as persuade those whose real knowledgebase was in the Windows API to never really leave Windows.
Let's not forget that Microsoft was also specifically trying to "pollute" Java. From the court case:
Clearly, this was more than Microsoft trying to leverage experienced Java coders. They specifically wanted Java coders creating Java code that would run nowhere else but windows for the sole purpose of polluting the Java environment.
Some of this mirrors what Google are doing: leverage existing Java codebase and developers but require (not even just entice) them to use non-standard extensions so further work remains tied to their platform.
This is the danger of "embrace and extend", and this is what Google are doing. They're just much better than Microsoft at maintaining the odour of roses.
At which point one has to ask whether Google is also really attempting to pollute Java like Microsoft wanted to do. You seem to think so. I don't think there's any evidence. I think you have a valid point in so far as the general outcome might be the same no matter what the intention is. But that's a far cry from trying to insinuate hypocrisy between how Microsoft and Google are perceived.
When I said SCO had a weak case I was speaking as an IT professional with 10+ years of development experience working with the Unix source code involved in the case. The cases coming up today are mainly in the smart phone industry. This includes patent challenges to the hardware, software, and the ever popular and nebulous patented system designs and methodologies. MS, Goggle, Motorola, AT&T, CISCO, Oracle, and Apple have all been challenged in some capacity. These cases are in areas where cross licensing was either turned down or not even offered. I have no doubt the big companies will compromise with each other after the initial posturing phase is over with. The real threat to both the big corporations down to the individual developers are the patent holding firms looking for a quick buck. Even if 90% of their patent holdings are proven to be BS the remaining 10% that are upheld spells trouble. These companies wouldn't be playing this game if there wasn't a pretty good chance to make money in the first place. I doubt they entered this arena without first consulting with knowledgeable technical and legal resources who can understand and assess both the technical and legal pros and cons of a particular patent.