Well, technically, since this not a criminal case, nobody has to 'prove' anything. One side just has to have a preponderance of evidence. So far, the analysis of the code shows that only a fraction of a percentage of it is close enough to Sun/Oracle's to warrant looking more closely at it.
And while it offers no direct evidence one way or another, Google's intention from the beginning was to have the source code to Android published and would expect many, many eyeballs on their source code. If nothing else, it's inconceivable to me that the strategy at Google was, "let's clean-room implement 99.5% of this code, but then directly copy this other 0.5% of the code in order to save us time and money." A single engineer being lazy, on the other hand? I could buy that, maybe.
Clean-room reimplementation is not a new or obscure activity in software. It's been done for many decades and the legal hoops to jump through to perform it are well known. Standard practice is to have anyone who contributes as much as a line of code to sign an affidavit stating that they had never so much as glanced at the source code to what is being reimplemented. I suspect that Google has quite a lot of evidence that the clean room implementation was done according to legal standards. The truth is, though, a lot of APIs behave in ways that provide very few reasonable code structures to accomplish its implementation and therefore it is to be expected that even a clean-room implementation will have more than a passing resemblance to the original.
This whole thing seems rather silly. First of all, yes, clearly Google copied the Java API. How can they even begin to deny that? Secondly, there is a crapload of legal precedence that indicates that an API is not legally protected by copyright.
What am I missing here??
Well, if it's 'hard' Real Time, It means that the kernel is designed to give certain guarantees for responsiveness. An example could be that a process that requests it can be certain that it gets a timeslice every certain number of milliseconds either most of the time (for a 'soft' RTOS) or completely deterministically (for a 'hard' RTOS).
As a (former) Blackberry developer, I've decided that I will be doing no more development for their platforms. They pissed away any goodwill I had for them by their crappy tools, crappy support and their ridiculous policies. As an example, in order to become a development partner, which is the ONLY way to get real support from them, you have to sign a license that basically gives RIM rights to use any of your source code that you develop for their platform. Or typically, if you tried to discuss a problem on their support forums, they would allow developers to spend weeks or months trying to figure out a problem before stepping in and say, "Oh, ya, we know about this. It's on our internal bug tracking system," and then close the discussion to new posts. This was often for bugs that had been around for several major API versions, or even from the very FIRST API version.
Fighting through the mess seemed like it was worth it when it seemed like everybody in the market for the software I was developing had a Blackberry, but now that it's dropped down to almost zero, you want me to invest my time and money into a brand new platform? No, thanks. At this point, I'm content to see you slip beneath the waves and to try to forget you exist. Goodbye.
Do you forget that DVD also has DRM? It's functionally equivalent to the one for Blue-Ray: it took a while to crack, and now is essentially completely toothless.
You should probably have checked that before posting... Are you confusing LCD with LED?
Business is a good game -- lots of competition and minimum of rules. You keep score with money. -- Nolan Bushnell, founder of Atari