Oracle: 'Eight Android files are decompiled Oracle code' Oracle has claimed that Google derived its Android code from the specifications for "hundreds" of Oracle's copyrighted Java files, and that at least eight Android files are actually decompiled Oracle object code. Last week, Google asked a federal court to consider dismissing the copyright portion of the patent and copyright …
...that you never looked at others' code while developing and testing stuff? Even if it was your own code that you wrote earlier for another company?
Let me get this straigh: Do you consider programmers to be incapable of performing jobs in another company after they worked in $Oracle, lest they reuse their own ideas in their new job?
Let me put it even straighter: Do corporate employers intend to force programmers to go from their work at the company directly into retirement?
Or maybe work as waiters?
Who "owns" the code? Who owns my mind?
Let's say I sit down at home and write a little function, play with it, polish it a little and think, "That's neat" - and then a few weeks later I;m coding at work and find the same piece of code/method works well so I reuse it ... who owns that code? Did I just lose my "rights"? Did I have any "rights"? But this conundrum only exists because of the idea that code can be copyrighted.
If you want to maintain your "rights" to the code then use the trade secrets method and keep your mouth shut .... sure - you can decompose the binary but that's generally not worth the hassle - it's way easier and a hell of a lot more robust to just write your own code.
You have this concept... your code is a 'work for hire'. That is, depending on the wording of the contract, your client owns the code. Depending on the client's contract, you may have to surrender your notes or any physical copy of the code at the end of the project.
But what the client doesn't own is what's in your head.
Yes, you're right, you could always go back and write a better version of the code, but you will have to do it from memory. Going back to your previous client's notes or copies of the code for 'hints'... thats a no no. And yes, if you get caught 'reusing' your code for a different client... you'll get sued. (I've seen it happen.)
But unless you have perfect recall, you won't recreate the same functional code using the same variables, like you would see if someone decompiled your code to reverse engineer it. This is why Oracle kind of has Google on this one.
Google's other tactic is trying to get the patents overturned. And that's a different story...
but at the time I was taught to group certain variables and consistently use them for types of things I was doing. So if I worked at Oracle and wrote a piece of code, and then I worked at Google and was asked to write a similar piece of code, I would be likely to hit the same variable names. After that there tends to be an orderly progression of variable declarations. Where commutative properties apply, did Oracle reorder for purposes of comparison?
Yes there might be actual copyright infringement. But it's not a slam dunk based on this single piece of evidence.
"Let's say I sit down at home and write a little function, play with it, polish it a little and think, "That's neat" - and then a few weeks later I;m coding at work and find the same piece of code/method works well so I reuse it ... who owns that code? Did I just lose my "rights"? Did I have any "rights"? But this conundrum only exists because of the idea that code can be copyrighted."
Umm, no. I'd say there is about a 10% chance of there being any conundrum as it will almost always be covered by the documents that make up your contract of employment.
If you read this you will usually find something along the lines of "any IP you create as part of your work for The Company, or on systems and hardware owned by The Company belongs to The Company". So, do it at work -> theirs. Do it at home on your work laptop -> theirs. Do it at home on your own PC/laptop (and not SSHed in to/using software licensed by The Company) is your IP.
In that latter case you should keep a verifiable copy o the code 'at home' to prove it was created there first and, unless you get a legal agreement with The Company otherwise you are giving them implicit global rights to that code if you re-use it as part of your work.
See, not that hard really if you put your mind to it and actually read your contracts/know anything about IP law.
If you include the work of others in a body of your own work then it is proper to include a reference to that work, and this helps avoid claims of plagerism.
Also, when people start work with a company, they sometimes have to sign a contract which states 'anything you create during work hours on our money on our premises shall belong to us'.
One reason for open source is that it enables transparent specifications and testing. When you're working in a not-so-open environment you need test vectors for your product, if you don't you'll end up with the traditional Windows "spray and pray" type of programming where you ship buggy code and wait for users to complain.
Programmers typically churn out reams of code. Although its all technically "valuable IP" its really only so to an accountant. A lot of it has 'no commercial value' -- unless its used to fuel inter-company lawsuits.
It's hard to see how the function (or do the call them methods in Java?) could really have been implemented any differently. All the interface definition lines have to be the same anyway in order to ensure compatibility, and the semantics of the function (what it's supposed to do) will also dictate in general terms exactly what the general flow of the code should be. Add to that the fact that the code is only four "if" or "if/else" statements plus a short number of assignments, and I can't see any wiggle room for doing things any differently. In fact, the function looks for all the world like it's nothing more than a constructor/initialiser for some sort of object. Just how many ways are there to write such things anyway? My guess: just the one.
A developer will write the most efficient code he can. He will write that code for the employer. The same developer finds another employer and as usual writes the most efficient code he can.
If any of the projects of the two employers have anything in common it is highly likely that our roving developer will have written code that has much in common with the code he wrote previously for his/her last employer.
One writes good, useful and reusable code for a reason.
Petty and greedy, that must be why we all get along so well.
Maybe it is hard to write some functions differently, but when you have parameters called "set" and "set1" (both of which are sets) and "flag" and "flag1" (both of which are boolean) you start to think they must be de-compiled.
Just because it's hard to write it differently doesn't mean you can copy it.
Sure, it is a simple function, and sure, any implementation would likely be structurally similar. But the point is it has likely* been lifted from the Java Source and relicensed as if it were Google's IP to relicense.
*The Android version has tell tale signs of having been produced by a code generator, in it's naming of the local variables, names which wouldn't have appeared in the final compiled .class file. If only they'd had the sense to mixup the declaration ordering of the member variables, that might have been the 'wiggle' room they need to get off the hook.
A decompiler will also duplicate the names of the private fields. That's also not generally regarded as part of the class interfaces, though it can be observed through reflection or JNI.
The assignment of false to an instance variable in the constructor; that's also a decompiler artifact.
Javac cheerfully converts those (unnecessary!) instance variable initializations to assignments in the constructor, and the decompiler faithfully renders them that way.
Note that an innocent explanation is entirely possible, but it looks exactly like code that would come from a decompiler.
Original has the "boolean field = false;" instance variable declaration. There is no direct equivalent in the bytecodes. Instead, the bytecodes have the assignment in the constructor, and the decompiler reflects this in the generated Java -- in exactly the way you see it in the Android version.
I mean, you would expect two different programmers working independently on the same thing to do at least SOME things differently. If nowhere else than in the private declarations, which IIRC are mostly order-independent. Yet the two examples are shown to match line-for-line, including the declarations.
Well, they match line for line partly because the person doing the comparison removed all the comments and adjusted the spacing. Since all that's left is the functionality (and has been mentioned, a very small amount of functionality), the odds that two good programmers (or the same one working for two different companies) would produce the same code are not actually that low.
Those declarations are order-independent. Different ways of thinking can EASILY result in a different arrangement to an order-independent grouping because it's less a matter of objective logic and more a matter of subjective style.
It's like taking the four queens of a deck of cards and having people arrange them in whatever order they feel. The odds of two different people putting them in the same order starts to drop because each person can think differently and may have a different sense of arranging things (in other words, a different style). The end result will still compile the same no matter how you arrange them (just as quad queens are still quad queens no matter how you arrange them).
"Those declarations are order-independent. Different ways of thinking can EASILY result in a different arrangement to an order-independent grouping because it's less a matter of objective logic and more a matter of subjective style."
As for as Unit-Test code goes, I'm unsure, but the actual Java APIs are quite thoroughly documented, including private variables, etc. so one can extend them and use them properly in your own Java code. The need for 100% compatibility with Java forces the Android developers to completely whole-sale rip off the Java docs so custom extends and be supported. The easiest way to do this? Duplicate the Java API classes and member variables then write code that utilizes them. As far as classes such as Array and Iterator are concerned, there's not much leeway in how to implement the code utilizing only the member variables (and functions!) listed in the Java Docs. Given a very small set of pre-moulded Legos and told to build the same simple structure, it's no surprise programmers came to the same conclusion (code). Although, as a side note, they likely did just decompile UnitTest code. What better way to test compliance and compability of their own Java build than to use the actual Java Unit Tests? Bad? Likely. Good to ensure complete compatibility? Definitely.
These are implementations of a very simple interface. There are thousands of ways a poor programmers or a room full of monkeys could implement this. But a good programmer using best practice and following the very detailed Java style guide would always come up with something very close to Suns original code.
People, unlike software are not usually happy living purely off the donations of others.
How exactly can a person be opensource? Other than being a beggar or laborer for hire who will work for food (e.g. a monk)
Being paid to do a job certainly does not preclude you from watching and observing on the opensource market, or even offering your opinions on it.
Now if you said WTF? he works for Oracle that might carry weight and make sense.
All this was completely unnecessary. I suspect that Google only built Dalvik to try to create a closed app market place so that they collect more revenue. I doubt that any claimed technical benefits are worthwhile from an end users point of view. It's just another virtual machine on an ARM not terribly different from any other.
If they'd just done a normal Java setup, just like everyone else has ever done (apart from Apple), or a just allow native apps, then none of this would have occured. Instead there is this legal question mark hanging over Android. Just imagine the consequences to Android and all those who have bet on it if the US courts put some sort of sales blocks on it? If this court case starts swinging Oracle's way, what are the manufacturers supposed to do?
If Google ultimately lose it will make them look quite careless. Android updates are a joke. Being found to have copied large chunks of someone else's work would be ridiculous. Android's anarchy will ultimately cost end users.
If Google had licenced Java, Android *could not exist as a useful OS* because Sun absolutely refuse to certify anything above ME for mobile devices. In that scenario Android would be just another Java phone, with its own new set of incompatibilities with every other 'standard' Java phone.
Dalvik exists because of Sun (and now Oracles) intransigence, Sun wouldn't play nice so Sun got bypassed in the Android ecosystem. Oracle is a near step for step repeat of SCO vs IBM, new guy asserts claims that the history does not support and spends years blustering on, hoping the rising costs will force a settlement.
Only this time it wont fizzle out in an engineered bankruptcy with nothing important decided and Google have more than enough time to remove Java completely if things start looking bad. In about 9 years time this will be decided, either Google wins or Oracle gets a chunk of cash but there's nothing left to tax. The beauty of Dalvik is: it's not Java, it doesn't need Java source and the VM patents aren't likely to survive.
Java ME wasn't what Google wanted. It was too limited. It was Java SE that they wanted: the Java that's gotten supported enough and mature enough to have common ground. But Sun/Oracle said, "No way! Full-blown computers only!" So Google was in a lose-lose. Java ME was too finnicky, and Java SE was Verboten. So they went to the third option: since Sun/Oracle didn't want to play, they took their ball elsewhere.
Are Oracle saying that they own the right to use Java and that if you want to use Java (as in write a module that accesses a Java-like module in the same way as Java at a low level) then their Patent applies?
Let's face it Larry - you're kinda late to this party - although personally, if he want's to take his ball and go home, I for one would pay his bus fare.
P.S. Damn, how I wish I'd patented the MOV instruction...
hi,
Just because the code is the same does not mean Google is using copyrighted Oracle code. The "2.5.29.32.0" seems to from a standard called X.500 PKI. I Googled "private static final String ANY_POLICY = 2.5.29.32.0 ;" and found two exact source codes under GPL 2 released by Sun. To me this means that Google could have used the GPL version not Oracle's version.
http://www.java2s.com/Open-Source/Java-Document/Security/Bouncy-Castle/org/bouncycastle/jce/provider/PKIXCertPathValidatorSpi.java.htm
http://www.java2s.com/Open-Source/Java-Document/6.0-JDK-Modules-sun/security/sun/security/provider/certpath/PolicyNodeImpl.java.htm
The code looks like stuff GPLd by Sun many years ago.
Those do look very similar. I would say that the code provided for comparison was modified from the GPL code. I wonder if they are breaking the copyright by not posting the GPL 2 license with that small piece of code or by removing it after it was modified if it isn't in the full Java version.
Java/sun wouldn't rewrite the code, they would modify it. With the header/copyright notice saying it cannot be removed or altered.
If android did not have that header/copyright notice then I would say they are looking for trouble. Other than that It looks like what anybody else would have come up with.
1) if Google are going to argue that they used the GPL'd version, then they have to admit not complying with the terms of GPL - the fact that they could have complied doesn't alter the fact that they didn't
2) to support the argument that they used the GPL code and simply "forgot" to comply with the GPL terms, they would then have to explain why there code looks LESS like the GPL'd version and MORE like a decompiler product
--
Google - Don't get caught doing evil.
How did they not comply? by not including the GPL copyright? Remember, the shot we're shown here has had COMMENTS REMOVED -- so it's quite possible that the GPL copyright was there and was removed by the person comparing the code (if not, there was a GPL violation, if so, there was a good faith violation by the person removing the comment.)
must be a duck.
The point is that if you're looking at code that appears to be 'de-compiled' the odds are it is.
Apply Occam's Razor.
Coincidences like that aren't likely to occur by accident....
The other area in discovery is to see what the svn servers contain.
Soon Oracle will own Google. Either that, or we'll start to see Google charging $$$ for using its ad service.
No need to wait for discovery, we know about PolicyNodeImpl and friends because the repository has already been looked at. It tells a rather obvious story: engineer does bulk checkin (2500+ files), 8 weeks later engineer reverses the checkin, some time later a corrected checkin happens.
That suggests to me simple error, an engineer committing more files that (s)he was supposed to, an error quickly fixed by Google. Remember, this all happened more than a year before Oracle started alerting Google. My own daily battle with SVN tells me how easily these tools will stab you in the back if you aren't constantly vigilant.
Changing the licence is a serious problem, even if done accidentally (running automated search&replace on copyright&licence headers is fairly common), but if Google can establish this was a corrected error de minimus neuters the penalties.
The other half of the issue is the nature of copyright: copyright controls *copying*, it does not directly control *use*, that's what licences are for. And that's how its possible to legitimately have copyrighted source in a working copy that cannot be distributed, because it's possible to have a licence to use without a licence to copy. The source for these particular files was available under a variety of permissive licences (including direct from Sun), severely reducing the scope of Oracles complaint to just dumping them into a public repository with a changed licence for a couple of weeks.
Oracle may be able to win on the fact that the files were made available for distribution, they can't win on Google *using* these files, cant establish Android needs or uses them and cant establish any meaningful damage was caused. So good Google bashing PR that leads nowhere.
@Do Not Fold Spindle Mutilate err, you've got the whole thing backwards. Is the original code GPL of ASL? If it's GPL, then why is the Google code under the ASL?
It's ironic that you use the "fail" icon, because you've failed completely in understanding the problem: you can't just take GPL code and slap an ASL on it. If thats what Google did, if, as your statements indicate happened, then the code is really GPL. When you remove the GPL boilerplate bad things happen.
Once you break the conditions of the GPL, you lose patent protection as well. That's, basically, Oracle's argument. You may think you're supporting Google, but your argument *actually* supports Oracle's contention: that the code was copyrighted. All Google had to do was to keep the GPL boilerplate and there wouldn't be a problem.
Which raises the bigger question, of why Google didn't just fork OpenJDK -- much easier. However, any such fork would, naturally, be under the GPL and *not* the ASL.
I think this is just a case of a business (Google) deciding that the ASL is preferable, and then a mix-up. However, the facts, as you present them, make that a really expensive case of copyright infringement (and patent, as well, because when you drop the GPL you lose patent protection).
Penguin for the GPL :)
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
