Hacker News new | comments | show | ask | jobs | submit login
Oops: No copied Java code or weapons of mass destruction found in Android (zdnet.com)
584 points by sigzero on Jan 21, 2011 | hide | past | web | favorite | 57 comments



A few observations from a lawyer perspective:

1. At the risk of sounding simplistic, it is the patents, and not the copyrights, that matter most here.

2. Copyright infringement might provide a basis for a damage award but this, in a worst case, could readily be absorbed by Google, even as it works around any copyrighted code issues in future Android releases. What is more, the main copyright claims appear to center on a bizarre technical point, at least as framed by the court pleadings - that is, that the so-called open-sourcing done by Sun of the Java SE specification was, in effect, illusory because no such license was valid unless a vendor (such as ASF) could show "compatibility" with the Java specification via test suites made available by Sun through a license of its TCK, which in turn required that vendor to pay license fees and to agree to restrict distribution to the desktop only. Whether that claim stands remains to be seen but it would seem to me that Google (even if had to pay damages) could clean up any infringing code without too much harm to its prospects for the Android market in doing its future releases.

3. The patent claims pose the greatest risks for Google. Should it lose here, Google could be permanently enjoined from doing further Android distribution and would (I assume) find it exceedingly hard to do any workarounds. In that case, Google stands to lose potentially a vast, critical market and would effectively have to make Oracle its strategic partner for all of the mobile space in order to solve this problem. Very bad news indeed.

4. The good news is that Google has a strong track record of fighting off extortionist patent claims and has hit back hard (see, e.g., the HN discussion on a piece entitled "Google Bowls a Googly," http://news.ycombinator.com/item?id=1899156).

I would be interested in how those who are technically knowledgeable assess the risks to Google from the legal framework set forth above or in how you might clarify or reframe those legal issues based on technical points that I have missed.


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]


Not exactly.

A Googly is a type of delivery bowled by a bowler where the ball, after pitching on the ground, turns in the opposite direction of the majority of the balls bowled by the bowler. Thus a bowler who predominantly bowls off-spin ( ie, a ball which, after pitching on the ground, turns from left to right ) bowls one which goes from right to left.


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.


"As any programmer will tell you, you don’t ship your unit tests with your product. Unit tests are tools used internally to ensure the quality of the software before you ship it."

Two things.

1. When you do Open Source - you ship the source. 2. I don't remember copyright law being concerned with "shipping". I think "distribution" is what counts and if it's in the git tree - that's distribution.


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.


I'd like to see what a judge has to say about this.

I'm not convinced that there will be much distinction between the infringing works being in the binaries or not. They are in the source tree and that is essentially part of the build process. What's more, the source tree is distributed to all Android manufacturers. Google are shipping the source code.

I'm sure Oracle don't see it that way.

What we should be talking about is how they got into the git tree in the first place.


To cut to the chase, the Engadget's poster isn't a developer (according to ZDNet's poster) and he forgot to mention that the files that we're similar do not ship with Android, they are either used for testing or debugging.

UPDATE: FlorianMueller posted comments on the ZDNet post.


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.


Ryan's post is good, he explains things more thoroughly.

Very important: "It's not clear how the zip file got included in the AOSP, but it's obvious that it wasn't intended to be there and isn't actually used by Android in any capacity."


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.


I love that he protests the "He is not a lawyer" with "Some of my blog posts have been recommended by leading legal websites"


Sadly, while sensational articles like Engadget’s and Mueller’s will get splashed all over the web and lavished with thousands of views and hundreds of comments, the boring truth will rate no such attention.

I think this speaks to the poor quality of tech journalism. A part of the problem are poorly informed consumers.


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.


Indeed. Ever notice how when you read something in the news on a subject you are very familiar with the piece is often misleading and filled with inaccuracies? Ever wonder how that works out for every other news story?


The one bright point is with that terrible, fast-updating internet journalism, people can at least try to get out that a story is plain wrong within a few hours, as opposed to days, weeks, or months later (when few people care much about the story).


Nevermind that, at least one study showed that if someone with view X is presented with "evidence" that it's indeed true, and then later presented with a full debunking of it, view X will be reinforced.


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


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


Also interesting how the original oops submission had close to 100 comments whereas this one has less then 50.

I am guilty of this too - being drawn to inflammatory headlines - but to be honest, the truth is much less interesting in this case.


It's been up-voted more, however.

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


> It's been up-voted more, however.

Exactly. The headline "Surprising Event Happens" is bound to draw more discussion than it's mere overturning....unless the discussion becomes about the meta issue of journalism.


Florian continues to comment on the post, posts this link for confirmation of the source files still being in Android source

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


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?


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.



Note however that deleting the files don't suddenly make the copyright infringement claims invalid.


Sure, but it appears that there was no intent and that the actual damages from the infringement are roughly $0. It may result in a small penalty, but it's in no way a threat to Android's future.


Yup, statutory damages for copyright infringement suck for individuals, but for someone like Google they're not awful (AFAIR it's something like $7,500 or $150,000 depending on something per count).


True, but if they did ship something tainted, then that could be a very large count.


> It may result in a small penalty

Especially considering they did register their copyright on Java 5. I know because I have read the court exhibits.


Considering Florian Mueller has too breathless-and-dubious anti-Google pieces here in the last two days and given my survey of his site (no problem with handing Novell's patents to Microsoft, etc, etc), calling him a pro-patent Shill actually seems fitting.



Florian's whole shtick comes from supposed free software cred. But he does have a somewhat spotty history when it comes to supporting Microsoft and spreading FUD about GNU/Linux. It is a tough call what his true motives are, but things aren't always what they seem.


I think he is a strong advocate of getting rid of SW patents. But I think he thinks companies like IBM hide behind the GPL for somethings to get community favor and then use their patents in other endeavors (like Hercules).

I'm speculating, but I think he views the problem as being patents, and thinks the effort around the GPL to be a distraction and one that fundamentally doesn't solve the patent issue. Again, only speculating, but I think he'd like to see a real patent nuclear attack which will push the industry to move to get rid of patents.


Speaking of things not always being what they seem, a lot of the complaints about Florian can be traced back to FUD from Groklaw, which doesn't take kindly to people who criticize IBM.


I don't get it?

UPDATE: thanks for the reply. I thought the WTF was something directly related to this story.


joe_the_user: "calling him a pro-patent Shill actually seems fitting."

Wikipedia: "founder of the NoSoftwarePatents campaign."


From the wikipedia article above: "In 2004, Müller received the support of corporate sponsors 1&1, Red Hat and MySQL for launching NoSoftwarePatents.com"

So he lobbied against patents in the past and been paid by a corporation for supporting a particular cause in the past. I would invite you to look at the positions he's taken on his blog and decide which he's doing at present.


Just serves to reinforce the point made here http://news.ycombinator.com/item?id=2128038


and how many clueless entities down voted all of us stating that the article this morning was not the full story?

Proof positive that even among HN readers the crowd is a bit less than intelligent


Unit tests still is code used for dev., this time copied code from Java?


[deleted]


This is a little pedantic. Is overarching point is correct. In most cases your test code doesn't get shipped.


Open source projects always ship test code (when they have some).


This isn't quite the same thing as installing open-source code onto a cellular phone.


So the OO.o binaries -- http://download.openoffice.org/other.html#tested-full -- include unit tests?


Tests are shipped with code, not binaries. Why would one ship tests with binaries?


That's his point: the vast majority of Android distributions are likely to be binaries installed on devices, not source distributions including the allegedly infringing code. This changes the discussion at least with respect to Oracle's remedies should Google be found guilty.


The exception that proves the rule. I think the Python community is, to a certain degree, split on the usefulness of doctests, and in my experience most devs see them as useful documentation first, and tests second.


I use unittest (and the 2.7 features backported in unittest2) unconditionally over doctest. I don't think I'm alone there, as most of the Python devs I know do the same thing. The learned skill of unit testing the Java way carried over nicely.


Doctests make very useful, always up-to-date and tested, documentation.


I don't understand why this was down-voted. IMO, the primary value of doctests is in having example code that you know actually works and being forced to change the example if the implementation changes.

On the other hand, unittest is far cleaner for testing corner cases and the like. I've used both in a project quite happily (and like that Django has default support for both).


Or really any more recent developments. I daresay most Ruby, Python &c. projects ship with tests or specs.


Python and Ruby both ship source with the product. Most (all?) Android builds (and most other compiled binaries) don't include the unit tests.


Raises the question if it'd be reasonable to have the installer optionally run unit tests, if supplied, on the client device?




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: