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.
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."
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.
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).
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.
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.
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.
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.
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).
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?
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.
"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.
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.
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.
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.
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]
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.
64 comments
[ 2.8 ms ] story [ 133 ms ] threadUPDATE: FlorianMueller posted comments on the ZDNet post.
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.
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."
edit: Thought the blog post was removed from Techmeme, but was mistaken.
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).
http://en.wikipedia.org/wiki/Florian_M%C3%BCller
UPDATE: thanks for the reply. I thought the WTF was something directly related to this story.
Wikipedia: "founder of the NoSoftwarePatents campaign."
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.
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.
http://android.git.kernel.org/?p=platform/libcore.git;a=tree...
Especially considering they did register their copyright on Java 5. I know because I have read the court exhibits.
http://android.git.kernel.org/?p=platform/libcore.git;a=tree...
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?
I think this speaks to the poor quality of tech journalism. A part of the problem are poorly informed consumers.
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.
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'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.
I am guilty of this too - being drawn to inflammatory headlines - but to be honest, the truth is much less interesting in this case.
On the plus side, the story got here only 4 hours after the original one.
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.
Proof positive that even among HN readers the crowd is a bit less than intelligent
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.
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.
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.
jordan air max oakland raiders $34–39;
Ed Hardy AF JUICY Bikini $25;
Christan Audigier BIKINI JACKET $25;
gstar coogi evisu true jeans $35;
coach chanel gucci LV handbags $36;
coogi DG edhardy gucci t-shirts $18;
===== http://www.2kuu.com =======
===== http://www.2kuu.com ========
===== http://www.2kuu.com ========
===== http://www.2kuu.com ========
==== http://www.2kuu.com =======
==== http://www.2kuu.com ========