Oops: No copied Java code or weapons of mass destruction found in Android

If this is all there is (and we're definitely not sure about that yet) then google does have some egg on its face, but only a little bit.

As far as I can see at this moment none of this code ever made it in to the actual distribution that is used to operate the android devices, it is but a series of tests to ensure that compiled code functions correctly.

Still, these tests shouldn't have been in that tree and google will have to remove them and possibly will end up settling for the damages, though what those damages are will be very tough to argue. How does one quantify the damage of having these tests copied? In programmer hours required to re-create the code?

So, I agree with you that the copyrights are not the issue and even if a lot more code surfaces that google does not have a right to redistribute and it did end up in the android kernel they have the resources to work around it and to absorb the damages.

If the patent claims will stick and google will be prohibited from further distribution there will be an immediate and hard to resolve issue.

A case like that could drag on for a very long time and it would be next to impossible to stop infringing on a patent that is specified vaguely enough to require such litigation in the first place.

I'm probably slightly evil for hoping that this case actually will revolve around the patent and will prove once and for all how bad the patent system really is and that software patents do little to nothing to encourage innovation and actually do a lot of harm.

If there is one party that has the resources to fight such a battle successfully it is google.

The big winner in a fight like that would be Apple with the Apple system being untainted by any of these claims and presumably unencumbered by these particular patents.

Of course Apple has its own patent issues to contend with (http://www.guardian.co.uk/technology/2010/dec/16/nokia-apple...), on the whole it looks as though the mobile world is an all out battle ground for patent lawyers.

For those not well versed in Cricket (the game), Googly is when a spin-bowler bowls a ball in the reverse direction of that he usually bowls. So, if the ball usually spins from right to left, a googly would spin from left to right and trick a batsman and get him out. Hence the phrase "Google bowls a googly". [This is probably better suited for reddit's TIL]

Yes, but if the final built product does not contain those elements then at least the final product can continue to ship because it is not infringing.

The tests can then be removed and any damage claims will likely be settled and/or workarounds will be created.

If the code is in the core of android and ends up in the product as shipped by the various handset manufacturers then it's a completely different story.

His comment doesn't seem to amount to anything. His contention is that the files are still there in AOSP git tree when the key point was that those are "TESTS" which means they are likely not "shipped" with Android and so the assumed impact if any is not anywhere near as dire as the original Engadget post or Folrian's own blog post made it out to be.

EDIT: Ryan Paul's take - http://arstechnica.com/open-source/news/2011/01/new-alleged-... . He confirms that the files in question are non-shipping ones.

His comments amount roughly to: "I am too a real developer," and lots of "maybe this code was shipped," but nothing concrete.

edit: Thought the blog post was removed from Techmeme, but was mistaken.

It might, if it wasn't actually a problem in all forms of journalism. The bleeding lede wins, and most of the people who come across an incorrect story won't even hear about the correction.

Yea, how many tech journalists know how source code control systems works?

A heck of a lot of people on HN voted up Engadget's article. Are they all poorly informed consumers?

It's been up-voted more, however.

On the plus side, the story got here only 4 hours after the original one.

The nice thing about open source is that the public can investigate what exactly is happening here, which is exactly what I am trying to do.

Clue: Go up to the support directory and click the HEAD link and notice the difference.

I think Florian was looking at Froyo, while the author was looking at master. The offending source files are not in Gingerbread:

http://android.git.kernel.org/?p=platform/libcore.git;a=tree...

His response seems to be along the line of "how do we know the unit test code didn't get put on a device and shipped?":

For this one as well as quote #3, what's missing is an analysis of the code actually shipped with Android-based devices. There are many such devices. Some may be more security-oriented (hence more likely to make use of the "acl" and PolicyNodeImpl type of classes) than others.

So we're talking about a totally unsubstantiated claim here. There may be build scripts, and some files may not be in them by default. That doesn't mean that no maker of an Android-based device actually decided to build them into a product, especially if Apache license headers appeared to allow it.

If this scenario did in fact occur, then isn't it the device manufacturer's fault and problem, and not Google's responsibility?

Which party builds/packages the Android distributions for the actual phone devices that the OS will appear on?

W T F!?

http://en.wikipedia.org/wiki/Florian_M%C3%BCller