The progress of science and useful arts is promoted by a balanced intellectual property regime that adds the fuel of interest to the fire of genius while ensuring that incremental innovation can occur and that competition is healthy.

If interoperability is the goal (and it's a very important one for sure), non-copyrightability is not the only and especially not the best means to promote it. Copyrightability is the first and not the last step of the analysis. Highly-creative program code is copyrightable but, depending on the specifics of a case, using APIs may be considered fair use. Alternatively, someone wielding too much market power based on ownership of APIs may have to grant a (compulsory) license on fair, reasonable and non-discriminatory (FRAND) terms. Fair use and a compulsory license involve a case-specific analysis of all the relevant facts and circumstances. If something is simply declared non-copyrightable, the point of a case-by-case analysis is never reached.

Somehow the quoting didn't work in the parent post but I guess it's easy for everyone to see which three things I quoted from the post above and then responded to.

While Groklaw mentioned me many times, I'd need to see a list of cases in which Groklaw made a prediction that turned out true and I made one on the same issue that didn't. The one you linked to is from the spring of 2010 and it's about the IBM mainframe antitrust matter. Stuff like that is obviously not decided by an online community (or the open source community). The way to look at complaints about allegedly anticompetitive behavior is not binary. It's a question of whether someone had a reasonable basis for being concerned. In this case, the basis was clearly reasonable given that the European Commission opened formal investigations (a few months later) and IBM ultimately made commitments (the following year).

Judge Alsup's non-copyrightability ruling was flawed even from a purely technical point of view (for example, the way he conflated the Java language and the APIs). I know that a lot of people here (and on Groklaw, for that matter) liked the outcome (sort of like 'the end justifies the means') but I doubt that they even cared to read the decision from a critical perspective. There was an unjustified apotheosis on the Internet after his decision (an apotheosis that the judge himself presumably didn't even want to happen). Then the Federal Circuit, which enjoys a great reputation around the world for its IP expertise, determined that he had confused even basic principles of copyright law (for example, by importing fair use considerations into the copyrightability analysis). Those who hated that outcome concluded, like the post I just quoted, that the Fed. Cir. must have gotten it all wrong. Again, they substituted their belief as to the proper outcome for an analysis of the actual reasoning. Just like I thing people missed the weak aspects (even in purely technical regards) of Judge Alsup's ruling, the same crowd missed the strong ones of the Fed. Cir. opinion. I recommend to those who disagree with the Fed. Cir. to read the actual opinion, including the footnotes (some of the best stuff is found in them). The Fed. Cir.'s description of the Java language-API relationship makes a whole lot more sense than what the district judge wrote.

To answer your question (before explaining why the first part is based on a misunderstanding), my refresher Q&A on this case says in its headline that while there was a billion-dollar damages claim, this case is about something more strategic. The commercial value of what's at stake far exceeds a billion dollars, and the key to the kingdom for Oracle is to prevail on the merits and obtain an injunction, not for the sake of harming Android but for the purpose of bringing Android back into the Java fold (as Oracle's lawyers described it in a court filing).

The fact that Oracle brought a billion-dollar damages claim came to light in mid-June 2011. I merelyquoted from a court filing and explained that this was the (financial) risk (of course, as always provided that the plaintiff prevails on the merits, which goes without saying). On the same day and at around the same time, Reuters reported the very same thing. So I wasn't the only one to deem it a newsworthy fact.

You may or may not be surprised, but despite various disagreements over the years I'd have liked Groklaw to continue or, after its 2013 shutdown, to have come back. For example, I think Groklaw could have made some useful contributions to the public debate over this year's Apple v. Samsung trial in the Northern District of California. Also, I do regret some of my derogatory comments about PJ, including that I wondered at some point whether there was more than one person behind the PJ name. Earlier this year I met a highly trustworthy source (a corporate executive) who confirmed PJ's participation in a certain (patent-related) meeting years ago.

The part I don't understand is how Groklaws "predictions were mostly more accurate than [mine]" or "[my] opinion was painted as clearly wrong there." With respect to approximately 98% of the IP lawsuits I covered, Groklaw never made any prediction whatsoever (for example, you won't find any Groklaw prediction concerning German smartphone patent disputes, and very few relating to U.S. smartphone patent cases). The overlap essentially came down to API copyright matters: the use of Linux kernel headers in Android and the API copyright part of Oracle v. Google. While Groklaw's position on API copyright was shared by one district judge in California, my opinion was unanimously validated by three circuit (i.e., higher-level) judges in Washington DC this year. Now Google is trying to take that case to the Supreme Court. Any conspiracy theory concerning the opinions I had expressed about API copyrightability in general and the API copyright part of Oracle v. Google in particular makes no sense unless someone is crazy enough to believe that those Federal Circuit judges are part of the conspiracy.

Slashdot invited me and I was happy to accept. I know there are some misconceptions out there, but that doesn't have to prevent me from sharing opinions and information on more important issues.

This is my first reply here because I can easily clarify the question of why, when and how disclosures were made and address some misconceptions.

The "court order" mentioned above came down in August 2012, see e.g. http://www.cnet.com/news/judge-to-oracle-google-did-you-pay-off-bloggers/, approximately four months after a voluntary, proactive disclosure I had made in April 2012, see http://www.fosspatents.com/2012/04/oracle-v-google-trial-evidence-of.html#oracledisclosure. Oracle attached that previous disclosure to its response to the court order:

Oracle has retained Florian Mueller, author of the blog FOSS Patents, www.fosspatents.com, as a consultant on competition-related matters, especially relating to standards-essential patents. Oracle notes that Mr. Mueller fully disclosed his relationship with Oracle in a blog posting dated April 18, 2012; that Oracle retained him after he had begun writing about this case; and that he was not retained to write about the case. Mr. Mueller is a frequent critic of Oracle and was a leading advocate against Oracle's acquisition of Sun Microsystems, Inc., which led to Oracle's ownership of Sun's Java IP portfolio. A copy of Mr. Mueller's disclosure is attached as Exhibit A at 5.

I disclosed consulting work for Microsoft in October 2011, see http://www.fosspatents.com/2011/10/study-on-worldwide-use-of-frand.html. At that point, no judge had asked for a disclosure, nor has this happened to date. I did it because it was the right thing to do.

At the end of last month I shut down my consulting firm in order to focus on my (Android and iOS) app development project. I'm still blogging, but less than before.

My consulting business had served numerous clients, not just Microsoft and Oracle. There were dozens of investment banks and funds who paid me to answer questions or participate in conference calls. I also did research for a couple of law firms and a German car manufacturer (that company allows me to refer to them like this but not to disclose the name, just industry and country).

I wish all others commenting on these types of issues were equally transparent.

You keep failing to acknowledge that what you claimed was wrong. It doesn't matter for this particular discussion between us what's in the Apple license agreement. You claimed that once Apple is admitted as an intervenor, it can bring up other defenses. That's why I pointed you to Apple's proposed answer to Lodsys's complaint, which is limited to only one defense (exhaustion). Don't try to confuse reasonable, unbiased readers here who follow our discussion. You said something utterly uninformed and you desperately try to muddy the water. But that's very transparent.

You attack all sorts of other points that I'm not interested in discussing with you. The topic here was what Apple's proposed defense against Lodsys is. That one is available on Scribd as a PDF document for everyone to read, and it raises only one defense: exhaustion. Here's the Scribd link. Compare the substance of that document to your off-base claim that Apple raised exhaustion only as a reason for an intervention without limiting its defenses to that one.

Thanks for this support. The fact of the matter is that the world's leading news agencies, newspapers and websites quote me regularly on these topics -- in the U.S., in Europe, in Asia, in Australia, at times even in Latin America. I furthermore have a host of financial services companies among my clients asking me for advice as they shape their investment decisions. Those audiences are obviously more important to me, and it turns out that the quality of Slashdot due to the criteria by which people vote posts up or down is a serious issue that I can't solve -- Slashdot has a lot of work to do if it wants to stay relevant.

I never predicted as much doom for Google as Google itself did on its corporate blog post recently in connection with Android and patents.

Your reading of the documents is completely off base. Apple's motion for an intervention comes with a proposed answer to Lodsys's complaint, which raises only one defense: exhaustion. You could have read that on my blog. The other points you make are equally off-base.

That's a very sophisticated, analytical approach then :-)

If things were as easy as you (gnasher719) say, it would certainly be just a matter of contract interpretation. But it's not. You wrote your post prior to reading my explanation of why it's far from easy to argue with the existing license agreement. I linked to that explanation before.

Apple (and Google and others) got a license to Lodsys's patents not from Lodsys itself but from Intellectual Ventures, along with roughly 30,000 other Intellectual Ventures patents. It's highly unlikely that Intellectual Ventures' standard patent licensing agreement says anything about 'app developers'. Chances are 99.99% that the term 'app developers' doesn't appear in that license agreement at all.

The analysis of whether or not Apple's license constitutes 'exhaustion' of any given Lodsys patent is no less complicated than analyzing Lodsys's infringement assertions. As I explained on my blog, 'exhaustion' is a concept that requires an in-depth technical analysis of the technology that is licensed (in this case, Apple's technology) and the one that is accused of infringement (the apps) and, very importantly, how those two layers interact. This means that the court has to go through a detailed technical analysis based on so-called infringement claim charts, which typically require the construction (interpretation) of the most relevant terms used in the language of those patents.

What I just said is also supported in full by Apple's own arguments to the court for why its intervention should be admitted (Apple stresses that only Apple itself can explain how its technology works) and a letter sent to the court by Atari, Electronic Arts, Quickoffice and Square-Enix in support of Apple's proposed intervention. Those four companies also stress the importance of access to Apple's information not only regarding the license agreement but also the technology at issue.

Exhaustion defenses are very difficult to analyze. Do some research on the case law and you'll see that those mattesr are by no means less difficult to analyze than infringement assertions.

I welcome the fact that Google finally does at least something (after months of not answering related questions from affected Android app developers), and Google did a very good job so far on patent reexaminations in its dispute with Oracle.

However, these reexamination requests are of very limited use on their own . They don't change the situation of developers who get letters from Lodsys or are actually sued by Lodsys and have to decide whether to pay up or fight. Even the combination of Apple's motion for a narrowly-focused intervention (Apple just raises contractual issues as opposed to defending app developers against Lodsys's infringement assertions per se; Apple's 'exhaustion' theory could work but it's far from certain to hold water) and Google's reexamination requests doesn't really strengthen little 'indie' app developers at this stage. Also, the Wired article pointed out that the U.S. District Court for the Eastern District of Texas grants stays pending reexaminations only in 20% of all cases. Most of the time, those federal lawsuits continue unabatedly, even though the patent may subsequently be invalidated.

Short of blanket coverage from Apple and Google, what those two platform companies do against Lodsys is insufficient. It would be great if they could give their developers some real guidance -- many right now don't even dare to implement in-app purchasing or links to an app store (Lodsys also brings assertions against links, not just in-app purchasing) because they don't want to take risks. Others have removed their apps from the U.S. market because of Lodsys (which goes after international developers, too, but can only sue them if those do business in the U.S.). Apple and Google fail to create a basis on which developers would be able to simply ignore Lodsys and go about their business.