by Mike Masnick
Wed, Jun 6th 2012 7:15am
by Mike Masnick
Thu, May 31st 2012 3:46pm
from the a-bit-narrowly-focused dept
So long as the specific code used to implement a method is different, anyone is free under the Copyright Act to write his or her own code to carry out exactly the same function or specification of any methods used in the Java API. It does not matter that the declaration or method header lines are identical. Under the rules of Java, they must be identical to declare a method specifying the same functionality — even when the implementation is different. When there is only one way to express an idea or function, then everyone is free to do so and no one can monopolize that expression. And, while the Android method and class names could have been different from the names of their counterparts in Java and still have worked, copyright protection never extends to names or short phrases as a matter of law.As some have pointed out the ruling is somewhat narrowly focused just on these 37 APIs, but the principles involved in why those 37 APIs are not copyrightable certainly will apply to plenty of other APIs as well. The ruling itself (embedded below) is pretty thorough and detailed. We had noted earlier that Judge Alsup had admitted that he'd learned to code Java in order to better understand the case (and that he'd had a history of knowing other coding languages as well) -- and it shows. Rather than using braindead broad analogies that don't make much sense, as we see all too often in court rulings, Alsup gets to the heart of the matter and clearly understands what an API is and how it works. His ruling is actually a decent primer on some parts of code for those who have never coded.
It is true that the very same functionality could have been offered in Android without duplicating the exact command structure used in Java. This could have been done by re-arranging the various methods under different groupings among the various classes and packages (even if the same names had been used). In this sense, there were many ways to group the methods yet still duplicate the same range of functionality.
But the names are more than just names — they are symbols in a command structure wherein the commands take the form
java.package.Class.method()Each command calls into action a pre-assigned function. The overall name tree, of course, has creative elements but it is also a precise command structure — a utilitarian and functional set of symbols, each to carry out a pre-assigned function. This command structure is a system or method of operation under Section 102(b) of the Copyright Act and, therefore, cannot be copyrighted. Duplication of the command structure is necessary for interoperability.
From that, Alsup points out just how ridiculous this entire case has been -- and specifically notes that he's explaining the level of ridiculousness of Oracle's position for the benefit of the appeals court who will surely hear this case once Oracle appeals (and which almost certainly will be staffed with judges not nearly as clued-in as Judge Alsup).
Oracle has made much of nine lines of code that crept into both Android and Java. This circumstance is so innocuous and overblown by Oracle that the actual facts, as found herein by the judge, will be set forth below for the benefit of the court of appeals.He goes on to explain not just how insignificant the situation was, but he details how it happened and why it's crazy to consider it worthy of a copyright infringement suit. It's a pretty complete smackdown of Oracle's position.
Again, it is quite likely that Oracle will appeal, even though this ruling is so firm it might be smarter for Oracle to issue a giant apology to the tech community and just get on with doing business. That seems unlikely, of course, as Oracle probably hopes to find less knowledgeable judges on appeal. One hopes, however, that the appeals court judges will recognize the very, very thorough nature of Judge Alsup's ruling, and reject any appeal as well.
by Mike Masnick
Wed, May 23rd 2012 11:08am
from the there-goes-that-one dept
Groklaw has the details with "no" answers across the board:
Question 1: has Oracle proved by preponderance of evidence that Google infringed?
Claim 11: not proven
Question 2: not proven
Question 3: no answer, no response, not applicable.
by Glyn Moody
Mon, May 21st 2012 3:10am
from the you-can't-fool-me dept
Recently Techdirt wrote about the heated debate on the subject of whether people should learn to code. We pointed out that some knowledge of that subject could be particularly useful in helping people understand why copyrighting APIs or patenting software is just crazy -- whatever the abstract legal arguments, in practice both make programming much, much harder.
An obvious situation where such practical knowledge could be crucially important is in court cases dealing with software. Rather neatly, the long-running court case between Oracle and Google, where the former is accusing the latter's Android of infringing on its code in various ways, has thrown up a perfect example of this.
It arose in an exchange between Judge Alsup and Oracle's main lawyer, the high-profile David Boies, best known for representing the US Justice Department in the United States v. Microsoft case. Boies claimed that the fact that the jury had decided Google's "rangeCheck" code had copied Oracle's implementation of the same function was evidence that Google was trying to save time. The argument of Boies was that Google consciously copied those few lines from Oracle in order to accelerate development -- and thus to start making money faster through daily activations of phones running its Android operating system.
But Judge Alsup was having none of it:
I have done, and still do, a significant amount of programming in other languages. I've written blocks of code like rangeCheck a hundred times before. I could do it, you could do it. The idea that someone would copy that when they could do it themselves just as fast, it was an accident. There's no way you could say that was speeding them along to the marketplace. You're one of the best lawyers in America, how could you even make that kind of argument?
This is a perfect example of a judge being able to draw on his personal experience of coding to dismiss what a clever lawyer probably thought was a clever argument.
Contrast this with another judge, talking this time about software patents, as recently reported on Techdirt:
Judge Michel seemed unaware of the depth of the software industry's dissatisfaction with the patent system. He suggested the patent system's critics were relatively marginal figures not representative of the views of the broader technology industry. And he didn't seem to understand the dynamics of the patent arms race currently affecting the software industry.
No one who has tried to code in any depth could dismiss the problems caused by software patents so glibly -- it would be hard, for example, to imagine Judge Alsup saying this.
"If software is less dependent on patents, fine then. Let software use patents less as they choose," Michel said. "If other industries are terribly dependent on patents, then let's not wreck the system just because software people are unhappy."
Learning to code certainly isn't a panacea, nor is it relevant for everyone. But for those professionals who must make important decisions about software -- judges, for example -- a basic programming literacy is indispensable. As it is, the tech industry must count itself lucky that the Oracle vs. Google case seems to have ended up in front of one of the few judges qualified to decide it.
by Mike Masnick
Fri, May 11th 2012 4:01pm
from the wow dept
When Alsup heard Jacobs say this, he warned that if Oracle goes down this path, they might not win anything at all, adding that it is the “height of ridiculousness” to think that Oracle could claim “hundreds of millions” of dollars for nine lines of code.The only thing I can figure here is that Oracle is doing this just to be a pest. Even if it does eventually win on the copyright issue (still an open question given the judge needing to rule on the copyrightability of APIs), it's not going to get that much money either way. The $150,000 statutory damages numbers are pocket change for either company, but as the judge made clear, in all likelihood it would get less (or nothing) if it tries to get "infringer's profits," because the contribution of the code in question is so minimal. However, it is possible that the fight over what those "profits" might be will simply prolong the case... and the expense of the case. So perhaps this is just a strategy by Oracle to drag things out? Maybe its lawyers are hoping that will make Google want to settle? Other than that, I'm with the judge in being a bit perplexed by the reasoning here.
“The law can’t operate that way,” Alsup said. “In my mind, you’re making a mistake.”
In a later discussion on Friday morning, David Boies, also representing Oracle, tried to defend this strategy, arguing that the burden of proof is on Google here — not Oracle.
“What we are saying is once you proved infringement, we think under the law we have claim for infringer’s profit case,” Boies asserted.
by Mike Masnick
Mon, May 7th 2012 11:48am
from the if-it-was-fair-use,-it-wasn't-infringement dept
According to The Verge (who is in the court room), the jury also wasn't buying the claim that Google relied on Sun's statements saying that Google's use was okay. The jury's main problem with Google's claim here wasn't that Sun hadn't made clear that the use was acceptable. It was that there wasn't much evidence that Google actually relied on such claims from Sun. I can understand why the jury might claim this, but I wonder why it would matter. Given that Sun made clear that Google's use was acceptable, in what world could you later turn around and claim that its use was unacceptable?
Either way, the fact that the jury couldn't come to an answer on the fair use/de minimis questions effectively sinks the entire process. Google immediately asked the judge to declare a mistrial, and the judge has supposedly asked both companies to prepare arguments over whether or not a mistrial should be declared, so this is far from over.
by Mike Masnick
Fri, May 4th 2012 5:31pm
Ongoing Patent Fights Mean Startups Are Now Wasting What Little Money They Have At The Patent Office
from the not-cool dept
Unfortunately, it appears that not all startups are working that way. With Yahoo's patent fight against Facebook getting so much attention these days (not to mention other big patent fights involving companies like Google, Apple, Microsoft, Oracle and others...), it seems that startups are (rather reluctantly) spending a lot more time (and money) at the Patent Office.
This is, to put it mildly, crazy. The two biggest scarce resources for startups are time and money. Throwing them away on getting patents is a huge waste, and it's main purpose is to act as insurance against failure or against jealousy over extreme success. Basically, most patents are completely useless. But if a company is failing, then perhaps it can sell off its patents. And, if a company is succeeding, then suddenly others will start suing it for patent infringement -- and the hope (rarely realized) is that having at least a few patents in the portfolio means that other practicing entities won't sue for fear of getting sued back (patent trolls are exempt from this, however).
It's really too bad that the state of the patent world today is such that are most innovative companies are basically forced to throw away time and money to apply for patents they never want to use.
One separate aside on this story. The article talks about the Twitter IPA agreement, and later quotes the founders of the startup Everyme as saying they support the IPA, but: "their first three apps were already with the U.S. Patent and Trademark Office by the time IPA was available, though, and they don’t plan to refile them." This sentence makes no sense. The IPA has nothing to do with the USPTO and the patent filing. It's merely a part of the assignment agreement, leaving some portion of control with the inventor. In fact, Twitter -- who does have some patents -- has said that it's using this agreement retroactively with patents that were applied for before the IPA existed. So there's no reason to refile the applications at all. In fact, the IPA is entirely separate from the actual patent application.
by Mike Masnick
Wed, Apr 25th 2012 2:03pm
from the it's-now-how-people-code dept
For starters, software often does not require the type of heavy investment that should result in a 20-year monopoly. Instead of expensive laboratories or years of testing for FDA approval, for example, you often just need a coder and a computer. Even complex programs don’t require 20 years of exclusivity to recoup their investment. Software patents are often not even necessary for successful businesses: Facebook and, yes, Google — never relied on software patents to grow their early businesses.Of course, tons of software developers recognize this implicitly. I know an awful lot of software developers in Silicon Valley. I can't think of a single one who thinks patents are a good thing or even remotely useful (and this includes many developers who have patents). In development circles, it seems that nearly everyone thinks patents are a waste of time and money. And that's because software doesn't work the way that the patent system envisions.
Software patents are also notoriously vague and difficult to understand, making it impossible for small inventors to navigate the system without expensive legal help. And that brings us to the most dangerous aspect of software patents: litigation.
It turns out that software patents are nearly five times more likely to be the subject of litigation as other patents. In fact, lawsuits surrounding software patents have more than tripled since 1999, and they have become part of the price of doing business in America. Take Spotify. After realizing much success in Europe, Spotify launched its U.S. product in July, and just weeks later it found itself facing a patent suit.
Perhaps most troubling, the patent system fails to recognize how people create and use technology. Software is fundamentally situated as a building-block technology. You write some code, and then I improve upon it — something the open source community has figured out. Google’s use of Java in its Android OS also demonstrates how innovators create, by making its own product and and incorporating some elements of the Java language (which, incidentally, Java’s creators have a history of supporting). And when those two come together, it results in an incredibly popular product, here the Android OS.It's the difference between an idea and actually bringing that idea to market. That difference is always ignored or underestimated by patent lawyers -- but developers know the difference. The patent system wasn't designed by software developers, though. And it shows.
by Mike Masnick
Tue, Apr 17th 2012 8:01pm
from the shouldn't-have-gotten-this-far dept
Oracle has been quite public with its argument (pdf), which is mostly based on taking snippets from Google emails that suggest a need to license Java. The favorite of the bunch is this one:
They also point to some snippets of code that do appeared to be copied:
If you just see that side of it, you might be convinced, but the details suggest a much less convincing story. First off, there are serious concerns about whether or not an API even can be covered by copyright. In fact, before Sun was acquired by Oracle, Sun's own CTO had said that "internet specifications are not protectable under copyright," which (you might think) gives Google an implied go ahead to make use of the API. Furthermore, many of the email snippets that Oracle presents are taken out of context -- they show little snippets of big emails and pull from very very different time periods -- ranging from 2005 to 2010, when different factors applied. Oracle also scrubbed a blog from former Sun CEO Jonathan Schwartz in which he warmly welcomed Google to the Java family when the company launched Android.
Perhaps more damning: Larry Ellison himself in 2009 at the JavaOne event spoke about Google's Android development and how they were contributing code back to Java. Ellison himself was put on the stand and appeared to contradict his own depositions when it came time to discuss the specifics of the copyright. That can't go over well. Not only that, but he stumbled, and claimed he was "not sure" when asked specific questions:
On cross-examination, Google came out firing and the room got tense quickly. “Do you understand that no one owns the Java programming language?” lead counsel Robert Van Nest asked.Oracle's response, of course, will be that it just meant for developing apps, not for using the API -- but its other statements are a lot less clear on that. Either way, it seems pretty clear that Sun gave an implied open license to these things, so to come back now and insist otherwise is pretty questionable. Furthermore, there still are questions as to whether or not an API can actually be covered by copyright at all.
Ellison began a longer answer, but Judge William Alsup interrupted him and said it was a “yes or no” question. Finally Ellison said, “I’m not sure.”
“And anyone can use it without royalty?” Van Nest followed up.
“I’m not sure,” Ellison said again.
Then Van Nest showed a video of Ellison receiving the same question on a deposition video and answering “That’s correct” to both.
Separately, Oracle keeps talking about just how much work it is to create APIs, and even points to some Google statements about the difficulty of doing so. That's smoke and mirrors. Difficulty has no bearing on copyright law. It's kind of surprising that Oracle's lawyers would even bring it up, as "sweat of the brow" arguments won't get very far. Hell, even if it biases a jury, it would get rejected on appeal. It seems like Oracle's strategy here is just to confuse the jury and go for guilty by association because they're going to have trouble showing actual guilt.
As for the specific code snippets shown above, those a few lines out of 50,000 or so files. Under copyright there's a defense known as de minimis copying, if you're just found to have copied a very tiny portion of something. It seems like that might apply here as well.
Also, you may have heard stories about the results of this trial potentially being worth billions of dollars or something, but that was before most of the patents got thrown out. The patents left over aren't worth very much at all, and the end result means that if Oracle wins, it'll likely get less than $100 million. That's still a significant sum, but it's a lot less than what Oracle had hoped to get in this lawsuit.
In the end, as it seemed from the beginning, Oracle's case looks pretty weak (and getting weaker).
by Mike Masnick
Mon, Aug 22nd 2011 10:16pm
from the we-may-find-out dept
Oracle has now responded and is arguing that copyright for APIs is perfectly reasonable, claiming that the APIs "contain many original and creative elements." Just as Google quotes a former Sun CTO, Oracle (somewhat snarkily) quotes a current Google employee (and former Sun employee) in noting, "API design is an art, not a science."
As Groklaw notes in the above link, Google probably won't win on the motion for summary judgment on this issue, even if it has a better chance at trial:
Although we don't buy all of Oracle's arguments (most importantly, we don't believe much of what they assert is copyright protected subject matter is, in fact, protected by copyright, such as API's), Oracle has probably done enough in its response to put the issue of copyright infringement before a jury. Of course, the court still needs to rule on Google's summary judgment motion.Indeed. I have trouble seeing how APIs can be covered by copyright. Oracle's key argument beyond that misleading quote is that creating a good API is "difficult." Difficulty alone does not determine if something is copyrightable, of course. Either way, allowing for copyright claims on APIs seems like a good way to create a lot more problems for important (legal!) things like reverse engineering. Once again, it seems like stupid intellectual property laws may get in the way of important methods for innovation.