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 …
US companies doing their Mickey Mouse lawsuit circlejerks again, I see.
"Harm done? We don't need no stinking harm done. All these ideas, all that code and all the work of your developers formerly employed at my place belongs to meeee...... Me MEEEE!"
"The seven files - one identified by Oracle, six by Muller - were from the "unit test" area of the Android open source code tree. Unit test code doesn't typically ship with a final product, and the files have since been deleted from the tree. "
So are you saying that this means it's OK to copy and steal code if you're only using it internally?
So, are you saying,,,
...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.
Its not about 'stealing', its about compatibility
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.
After years of software development, if my current employer (customer really) wants me to go straight into retirement, I say, bring it on!
@ Version 1.0
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...
"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.
Referring to work of others, and binding contracts
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'.
Granted it's been ages since I touched code, and it was never real code only BASIC,
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.
looking at the code ...
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.
The right code for the job
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.
looking at the code ... → #
Its like saying every piece of C code with #include <stdio.h> is copied (which it is in my case). Soooo freaken WHAT!
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.
Missed the point
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.
But LINE FOR LINE?
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.
Also, the private fields
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.
@LINE FOR LINE?
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.
I can't tell you how many times I've written:
for (int i = 0; i < count; i++);
I guess by your "logic" I must have decompiled that hunk of C++ each of those times.
You forget the declarations.
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).
@also the priovate fields
If what you are saying is true, and the decompiler inserts assignments into the declarations, then surely the Oracle code is copied from Android in this case, as the Android code lacks the declaration/assignment.
Reductio ad absurbum, QED, etc...
Why have you written that so often?
Unless you've got a sneaky #define of count hidden somewhere that causes side effects, what possible effect would that bit of code have, aside from wasting a few CPU cycles?
Typography is a skill...maybe I'll master it one day
It was late, and my semi-colon finger had..er...a spasm. Yeah...that's it...a spasm, yeah....
(Good catch. Seems you were the only one who caught it, though.)
Re: @LINE FOR LINE?
If you read the text right above the Android code, you will see it wasn't stripped of its comments.
And a non-commented piece of code with such variables as s, set, flag etc on a function declaration is a good indication of decompilated code.
"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.
You have it backwards
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.
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.
Its that FM man again
Quote "Well-known open source watcher Florian Muller"
wtf? He's a paid shill.
surely looks like it
Certainly a able self-publicist. Refused to deny he was paid by MS when accused of it on slashdot. He's getting onto the reg just a bit too often these days.
open source watcher...not Monk
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.
That is pathetic...
Even Microsoft writes its own bad code. No need to copy from anyone. Google just dropped the ball, again.
All your source are belong to us"
@looking at the code
It's not just down to the algorithm. They are remarkably similar, down to variable names
Reap what you sow
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.
G built Dalvik because Sun wouldn't play nice
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.
G built Dalvik because they didn't want to pay Oracle for licensing Java ME.
Just follow the money and your questions will be answered.
Actually - Sun (and Oracle) refused to license
So if Sun/Oracle refuse to license java for android because of their stance on mobile phones, how is it Googles fault that they had to rewrite a compiler to use a different vm than java?
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.
Why would Google have had to license ME (apart from the nexus)?
They built Dalvik because ME is, quite frankly rubbish and only fit for purpose in a few small niches (relatively speaking). Trying to write fully featured and portable in ME is in most case not worth the effort.
So what's patented here?
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...
Source is GPL 2
Just because the code is the same does not mean Google is using copyrighted Oracle code. The "188.8.131.52.0" seems to from a standard called X.500 PKI. I Googled "private static final String ANY_POLICY = 184.108.40.206.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.
The code looks like stuff GPLd by Sun many years ago.
enough for "prior art"
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.
2 problems with this excuse...
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.
Did not comply?
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.)
If it looks like a duck... smells like a duck... squacks like a duck...
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.
my theory of what happened with PolicyNodeImpl
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.
Source is GPL, or ASF?
@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 :)
"well-known open source watcher Florian Muller"?
Can we be a bit more down to Earth when describing Florian?
Such quotes make people stop reading these articles.
- Product round-up Ten excellent FREE PC apps to brighten your Windows
- Review Tough Banana Pi: a Raspberry Pi for colour-blind diehards
- Analysis Pity the poor Windows developer: The tools for desktop development are in disarray
- Product round-up Ten Mac freeware apps for your new Apple baby
- Chromecast video on UK, Euro TVs hertz so badly it makes us judder – but Google 'won't fix'