The CCIA has commissioned studies by Mike Masnick, CEO of Floor64. See http://www.floor64.com/about.php. Mr. Masnick has commented on the case on the TechDirt website and on his personal friendfeed.com account. See Ex. X (available at http://www.techdirt.com/articles/20120523/11050519050/boom-jury-says-no-patentinfringement- google-oracle-case.shtml and at http://friendfeed.com/mmasnick/a3a94012/jurygoogle- did-not-infringe-on-oracle-patents).

In this technological age, we take for granted the ability to access tremendous amounts of data through our computers and the Internet, a process that seems effortless and unremarkable. But this apparent effortlessness is an illusion, made possible only by technological wizardry. The amount of information that is used by many companies has outstripped the storage capacity of individual memory devices. The information must be stored across hundreds or thousands of individual memory devices and machines. The ability to keep track of information as it is distributed across numerous devices and machines, while still allowing users to retrieve it seamlessly upon request, is a feat that was impossible until recently. It was made possible by the innovations of technological pioneers like Melvin James Bullen, Steven Louis Dodd, William Thomas Lynch, and David James Herbison.

Bullen, Dodd, Lynch and Herbison were, among others, members of a company dedicated to solving the difficult problems that limited the capacity of computer technology and the Internet, particularly problems concerning data storage. These engineers found innovative solutions for these problems and patented several technologies for data storage, including the ones at issue in this case. Many of the data-access feats we take for granted today are possible because of the data-storage inventions of Bullen, Dodd, Lynch and Herbison.

It makes no difference, in a situation such as that at issue in the main proceedings, whether the copy of the computer program was made available to the customer by the rightholder concerned by means of a download from the rightholder’s website or by means of a material medium such as a CD-ROM or DVD. Even if, in the latter case too, the rightholder formally separates the customer’s right to use the copy of the program supplied from the operation of transferring the copy of the program to the customer on a material medium, the operation of downloading from that medium a copy of the computer program and that of concluding a licence agreement remain inseparable from the point of view of the acquirer, for the reasons set out in paragraph 44 above. Since an acquirer who downloads a copy of the program concerned by means of a material medium such as a CD-ROM or DVD and concludes a licence agreement for that copy receives the right to use the copy for an unlimited period in return for payment of a fee, it must be considered that those two operations likewise involve, in the case of the making available of a copy of the computer program concerned by means of a material medium such as a CD-ROM or DVD, the transfer of the right of ownership of that copy.

As Oracle rightly observes, ascertaining whether such a copy has been made unusable may prove difficult. However, a copyright holder who distributes copies of a computer program on a material medium such as a CD-ROM or DVD is faced with the same problem, since it is only with great difficulty that he can make sure that the original acquirer has not made copies of the program which he will continue to use after selling his material medium. To solve that problem, it is permissible for the distributor – whether ‘classic’ or ‘digital’ – to make use of technical protective measures such as product keys.

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.

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.

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.

Clerk:

Question 1: has Oracle proved by preponderance of evidence that Google infringed?

Claim 11: not proven
27: no
29: no
39: no
40: no
41: no

Question 2: not proven

1: no
20: no

Question 3: no answer, no response, not applicable.

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?

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.

"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.

Follow me @glynmoody on Twitter or identi.ca, and on Google+

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 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.

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.

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.

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.

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.

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.

"OK, maybe you don't infringe these seven patents. But we have 10,000 U.S. patents. Do you really want us to go back to Armonk [IBM headquarters in New York] and find seven patents you do infringe? Or do you want to make this easy and just pay us $20 million?"

In Sun's early history, we didn't think much of patents. While there's a kernel of good sense in the reasoning for patents, the system itself has gotten goofy. Sun didn't file many patents initially. But then we got sued by IBM for violating the "RISC patent" - a patent that essentially said "if you make something simpler, it'll go faster". Seemed like a blindingly obvious notion that shouldn't have been patentable, but we got sued, and lost. The penalty was huge. Nearly put us out of business. We survived, but to help protect us from future suits we went on a patenting binge. Even though we had a basic distaste for patents, the game is what it is, and patents are essential in modern corporations, if only as a defensive measure. There was even an unofficial competition to see who could get the goofiest patent through the system. My entry wasn't nearly the goofiest.

We tend to think of technology as a steady march, a progression of increasingly better mousetraps that succeed based on their merits. But in the end, evolution may provide a better model for how technological battles are won. One mutation does not, by itself, define progress. Instead, it creates another potential path for development, sparking additional changes and improvements until one finally breaks through and establishes a new organism.

Adobe, Apple, Arial Software, Autodesk, Carbonite, Corel, Kodak, IBM, Intuit, Microsoft, McAfee, Online Holdings, Oracle, Rockwell, Rosetta Stone, SAP, Siemens, and Sony.

The most interesting part of the article is where it talks about Oracle's effort to undercut Red Hat by offering the same software at a lower cost. Apparently, as we predicted, it hasn't been going too well. And it's not too hard to see why: Larry Ellison doesn't seem to understand Red Hat's business model. What Red Hat is selling isn't software, but support. And the value of a support contract is a function of the expertise of the company providing it. Not only does Red Hat have a number of key Red Hat developers on staff, but it also has a ton of strong working relationships with developers and vendors elsewhere in the Linux community. That means that if a customer encounters a bug in its Red Hat Enterprise Linux installation, Red Hat will either have an engineer on staff who can fix it, or it will have a strong relationship with the outside developer who developed that piece of software or the firm that manufactured the hardware. That makes it more likely that it will be able to address the issue quickly and incorporate the fix into the software for future releases.

Oracle has made comparatively little effort to either hire Linux developers or foster strong relationships with the broader free software community. As a result, Oracle isn't able to provide the same kind of value that Red Hat can. Yes, Oracle tech support can fix straightforward problems, but if they need to make changes to the code, they'll often need to go to a Red Hat engineer for help getting it fixed. And not surprisingly, most customers would rather cut out the middleman and go to Red Hat directly, even if it costs a little more.