FOSS Patents

Ten years ago to the day, the first FOSS Patents blog post went live. (In the table of contents on the right side you can also find an entry for January 2010, but that one was added subsequently--and backdated so the contact form would be listed behind all of the actual content.)

When I talk to readers at courthouses or on other occasions, I realize most people don't even know what the "FOSS" stands for. That means Free and Open Source Software, a "politically and philosophically correct" term that describes both persuasions of the same movement. At the outset, the idea was indeed to focus on patent threats and assertions against open-source programs such as Linux. I always viewed the Open Invention Network (OIN) very skeptically as it appeared to part of the problem to a several times greater extent than it was part of the solution. And I was aware of some threats no one had reported on at the time. In fact, there is one that I hadn't written about in the more than 16 years since it was made, but with so much water under the bridge by now--and with Microsoft being a member in good standing of the open-source community these days--I'm going to reveal it on this occasion:

In early 2004, Microsoft's patent licensing department contacted MySQL AB, the originally Finnish-Swedish and, at that time, heavily Americanized open-sourced database company (whose CEO I was advising at the time). What Linux was in comparison to Windows, MySQL was to Oracle, Microsoft SQL Server, and IBM Db2. The term isn't used much anymore, but back then the "LAMP Stack" meant Linux, the Apache webserver, the MySQL database, and one of the P languages (mostly PHP, with a few people using Perl, or even Python): an open-source technology stack powering more websites than any other comparable configuration. MySQL had risen to popularity alongside Linux. It was a symbiotic relationship. Microsoft, of course, favored Windows + Internet Information Server + SQL Server + Visual Studio (C# or Visual Basic).

What Microsoft--and again, the Microsoft of then is not the Microsoft of now when it comes to these types of issues--told MySQL (a company that had received tens of millions of dollars of venture funding while Microsoft already had roughly 10,000 times greater resources) was that they claimed to hold a patent that covered functionality at the very core of the MySQL database engine. From a software development perspective, a database engine is a relatively monolithic (as opposed to modular) thing. If someone asserted a patent against the basic architecture of your engine, it could mean that you have to almost start all over. You'd lose years.

Microsoft was clear about its demand: a 2% royalty on MySQL's (tiny) sales. Two things were not clear, however: whether Microsoft had an agenda to actually start a patent war against open source and, particularly, the LAMP Stack, so that an initial royalty agreement would not have been an amicable resolution of an IP issue but could have been the beginning of the end for MySQL and LAMP; and Microsoft declined to disclose that mysterious killer patent.

The concern I just outlined--that Microsoft would wage an all-out patent war against open source--was not merely paranoia. A Microsoft exec in charge of corporate strategy at the time had told some Silicon Valley venture investors a year or two before that "if it comes to worst with open source, [they'd] just use some of [their] patents." So what was presented as a shakedown might have been a concealed attempt at a shutdown.

Microsoft was the only company at the time to have an issue with Linux; the rest of the industry viewed Linux as a chance of liberation from Microsoft dominance. When it came to MySQL, however, two other major patent holders--IBM and Oracle--potentially had just the same strategic motivation to attack the successful startup, as those companies were pro-Linux, but faced a disruptive-innovation threat from MySQL. While that would have been a gigantic violation of antitrust law, one of MySQL's founders even feared that Microsoft, IBM and Oracle might have agreed to launch near-simultaneous patent attacks on them. And they had only a very few patents (from a smaller startup they had acquired)--likely of zero retaliatory value.

MySQL didn't accede to Microsoft's demand, and Microsoft never stepped up the pressure or sued. Part of the reason may very well have been (and in my view, most likely has been) that there were two things going on in the EU that Microsoft had to be cautious about. The European Commission going after Microsoft for its conduct in some other conduct; and the EU's legislative bodies (Council and Parliament) were working on a Directive for the Patentability of Computer-Implemented Inventions, i.e., software patents directive. Concerns by the open-source community played an important role in the political debate.

At some point MySQL was seriously considering making Microsoft's patent royalty demand public. We had already prepared a press release, and it was going to be centered around an open letter to EU policy-makers urging them to abolish software patents in Europe (though that wouldn't have solved the problem for MySQL anywhere else, and it actually generated most of its revenues in the U.S. anyway). We didn't escalate the conflict, and ultimately that was better for everyone involved.

Oddly, about five years later Microsoft actually tried to defend MySQL's independence. Oracle was in the process of acquiring Sun Microsystems, which had acquired MySQL the previous year for 1ドル billion. While Sun wanted MySQL's business to grow, there were reasons to assume Oracle simply wanted to control it so as to eliminate a competitive threat. Microsoft and SAP (even though mostly concerned about Java in the beginning) were the two large complainants, and MySQL's founder, Michael "Monty" Widenius, was the third complainant, with help from me. So MySQL's founder and I ended up in an alliance with Redmond about five years after we had thought Microsoft would potentially use patents to destroy it.

If not for that old Microsoft patent threat against MySQL--16 years under wraps--, I might never have gotten involved with patent policy in the first place. And I had it very much in mind when I launched FOSS Patents. At that time, I already knew that Microsoft wasn't necessarily a foe (as the Oracle-Sun merger review showed). In fact, I felt that some FOSS people, maybe because they received funding from the likes of IBM and Oracle, weren't being fair: they turned a blind eye to some other large tech companies' (especially their financial backers') questionable patent dealings and pro-software-patent lobbying, but even when Microsoft had good intentions in specific areas, they looked at whatever Microsoft did or announced like Sherlock Holmes with a magnifier glass and, if all else failed, simply made up concerns that weren't warranted. Part of the FOSS Patents agenda was to focus more on companies whose patent abuse got less attention, but "deserved" more. The first big story here was the second post ever: on an IBM threat against an open-source mainframe emulator.

This blog's focus evolved dynamically. In fact, just about four weeks before I launched FOSS Patents, Apple had filed its first patent infringement complaint against an Android device maker (HTC). Android became the most heavily-attacked piece of open-source software that year as Oracle sued Google (a case that later became only a copyright dispute as Oracle's patents failed in court), Microsoft sued Motorola, Motorola sued Apple (which countersued using largely the same patents as against HTC), and the following year Apple sued Samsung.

Of the roughly 2,300 FOSS Patents posts I've written to date (also, there were a few guests posts), roughly 63% (1,456 posts) went live in the years 2011-2013, the three years in which the "smartphone patent wars" were raging on a very large scale. By 2014 they had already subsided, and in 2014 various disputes came to a partial or complete end.

With those Android companies countersuing, my litigation reporting simply had a mobile focus (and occasionally even gaming consoles). If I had anticipated that, I'd have named the blog "Mobile Patents" or "Phone Patents."

Actually, "FRAND Patents" would have made even more sense. I already took a clear position against injunctions over standard-essential patents in 2010. And a few years later, a Research In Motion/BlackBerry lawyer accused me, after a Mannheim trial, of having "devalued" SEPs and that companies were cutting back on their standardization activities (obviously not true, as we all know now with the benefit of 2020 hindsight).

More recently, this blog has almost been an "automotive" blog, only because car makers are currently the ones that SEP holders like Nokia primarily seek to prey on.

So there's probably no point in ever renaming a blog, much less when it is as well-known as this one. I'm very grateful for having so many loyal readers, and a number of highly important people in the industry as well as in the judiciary, executive and (to a lesser degree) legislative branches of government. I really am.

There's one thing I had envisioned for the 10th anniversary that I haven't found the time for: a redesign. This blog still uses the "Blogspot" platform's original blog layout. Blogspot became Google's "Blogger" service, and undoubtedly supports more fashionable layouts. However, since I have manually entered and edited all the HTML tags here from the outset, it's a bit risky to switch to a newer layout (I ran a test and the result looked awkward)--I or someone I'd pay for it might have to go over 2,000+ posts and make countless manual adjustments. Nevertheless, it may happen later this year--certainly sometime before the potential 20th anniversary :-)

There were times when I was seriously considering discontinuing this blog, or handing it to some other organization, such as an IP-focused publishing company. But in recent years there have been some really exciting developments--and I've found a way to keep blogging while continuing to run an app development company (I'll have a new game to announce this summer).

Some of you encouraged me to keep going--even some who have rather different positions on SEPs or on patent policy in general. Thanks for that, too. I'll keep sharing my honest observations and opinions with all of you for quite some more time!

Follow @FOSSpatents

Share with other professionals via LinkedIn:

I've seen comments on Internet discussion boards according to which the long-running Oracle v. Google copyright infringement dispute has been practically settled, given that Google has just confirmed to VentureBeat that its upcoming release of Android (Android N) will come with Java language libraries that follow "an OpenJDK-based approach." The OpenJDK is licensed by Oracle under the GPLv2 with a so-called Classpath Exception.

It's too early to agree with those who believe it's a virtual settlement (except that damages for past infringement might still have to be determined in court). I do remember that Oracle's lawyers released a statement ahead of the 2012 trial in which they basically said that Google had two options for using Java in Android--a proprietary license or using it on open source terms with the obligation to contribute back to the open source community--but, by simply using Java without either kind of license, Google had committed copyright infringement. That was more than three-and-a-half years ago. Why wouldn't Google have taken this step long before, if such a seemingly simple solution to the legal problem as OpenJDK had existed all along?

There are two possibilities:

• It could be that Google is now (that Android has unstoppable momentum) indeed fine with GPL'ing all of Android and just wanted to avoid it earlier on. Android already uses Linux, which is available under only the GPL (no proprietary option there). Now it's also going to use the OpenJDK libraries. So maybe Google doesn't care about applying copyleft--the rule that derivative works incorporating GPL-licensed code must also be published under the GPL (or they must not be published at all)--to Android as a whole. It previously preferred the Apache Software License, which gave Google and its partners more flexibility in terms of throwing closed-source components into the Android mix.

• Without knowing how Oracle views this and what Oracle will do, I consider a second possibility no less likely than the first one. It could be that Google still isn't going to put Android as a whole under the GPL. Maybe Google interprets the copyleft rule in the GPL (in this case, in conjunction with the Classpath Exception) in a way that differs from the way Oracle would interpret it. Maybe Google believes it can just replace those Java APIs with something based on the OpenJDK but still doesn't have to put any additional components of Android under the GPL. In that case, Oracle would likely disagree. And that disagreement could then give rise to another lawsuit.

The first possibility is, for now, a possibility. Maybe Oracle will look at Android N (when it's released) and say: this is in compliance with our rules, we just want to get damages for past infringement (including older Android versions that are still out there).

The second possibility, however, would lead to the most significant and dramatic GPL enforcement litigation in history. With the greatest respect for what the likes of Harald Welte and the Software Freedom Conservancy have done on that front, a lawsuit with which Oracle would seek to force Google to release the whole of Android under the GPL would dwarf everything that has ever been done to enforce the GPL.

As a litigation-focused blogger, I can't resist from speculating about what this scenario would mean in procedural terms.

So far, GPL enforcement lawsuits have typically been settled. To the extent that judicial decisions have come down, there is no indication that one can successfully seek what is called specific performance and have a court of law order a GPL infringer to release something under the GPL. It appears that the original right holder can at best obtain an injunction against continuing to distribute the derivative work without making it available on GPL terms.

Let's assume for a moment that Oracle defeats Google's "fair use" defense at next year's trial. It could then seek an injunction against further use of the proprietary Java API declaring code. If Judge Alsup and/or the appeals court agreed, Google would then be barred from continuing to distribute the proprietary Java APIs as part of Android unless it takes a license from Oracle.

But Google would then say: that five-year-old lawsuit is about the proprietary Java APIs, and new Android versions follow what Google now calls its "OpenJDK-based approach."

In that case, Oracle might argue that the injunction still applies, and seek sanctions against Google. So there would be an enforcement dispute.

If Oracle prevailed on the enforcement question, the whole OpenJDK thing wouldn't have helped Google in the end.

However, in order to enforce an injunction arising from the five-year-old lawsuit against Android N, Oracle would have to convince the district court (and/or the appeals court) that this is really an issue that was decided in the original lawsuit. Google, of course, would argue that the copyleft implications of its use of OpenJDK are a completely different matter. I don't want to state a position on this yet, but if the dispute reaches this presently-hypothetical point, I will say what I think (based on the facts that will be on the table at that point, and one of those facts would be the exact wording of the hypothetical injunction Oracle would have won in the meantime).

Without stating a position on a combination of hypothetical events, I think it's not too speculative to say that a not entirely impossible outcome of such an enforcement dispute would be that the court(s) would say: sorry, Google's use of OpenJDK raises one or more new legal questions that must firstly be decided on the merits. In that case, Oracle would have to bring a second complaint against Google, which would be OpenJDK-centric. All of this would take a long time--also including any appeals--to be resolved.

I don't think it's purely coincidental that Google is going down the OpenJDK avenue just in time before Oracle has its next opportunity to obtain an injunction, which will be after the upcoming trial.

If you'd like to be updated on the smartphone patent disputes and other intellectual property matters I cover, please subscribe to my RSS feed (in the right-hand column) and/or follow me on Twitter @FOSSpatents and Google+.

Follow @FOSSpatents

Share with other professionals via LinkedIn:

This commentary on the Microsoft-Red Hat partnership is a back-to-the-roots post for me. This blog started as a Free and Open Source Software Patents blog--hence the FOSS Patents name-- and only because of all the (ultimately not too meritorious, let alone impactful) patent attacks on Android, it effectively became a smartphone patent wars blog (but by then it was too late to rename it without losing traffic).

While I don't mean to endorse everything Dr. Roy Schestowitz has written about Microsoft on his TechRights blog (and certainly not everything he's ever written about me), I agree with him that media reports on the Microsoft-Red Hat deal could have dug deeper, especially into the patent aspects of that deal. I furthermore agree that Red Hat is apparently happy about making it easier for Microsoft to impose a patent tax on Linux and that Red Hat has simply sold out FOSS values. According to TechRights, Red Hat executives tried to dissuade Dr. Schestowitz from his vocal criticism of the deal, but failed.

I've been saying for years that Red Hat is utterly hypocritical when it comes to patents. It has a history of feeding patent trolls and fooling the open source community. There is, to put it mildly, no assurance that all of its related dealings actually comply with the GPL.

Sometimes I like the positions Red Hat takes in its amicus curiae briefs on patent issues, but more than once I got the impression that those filings were written primarily in an effort to create the appearance of defending the FOSS cause in this context. It was just window dressing.

The fact of the matter is that Red Hat seeks to be a major beneficiary of the software patents mess.

Red Hat is large enough by now that it can just make the trolls go away by paying them off, giving them funds and legitimacy to go after other companies, including other open source companies.

Red Hat has also accumulated a certain amount of patents over the years, which puts it into a better position than individual open source developers and smaller companies in this space to retaliate in the event of a strategic attack by a competitor.

Red Hat now wants to tell Linux users that the way to be protected with respect to patents is to use Red Hat Linux. "Reduce your exposure, buy from us." That is a way of seeking to benefit from software patents.

All of this is no surprise when considering that Red Hat has always just been about taking advantage of something. In terms of its product and licensing policies, Apple may be the very opposite of a "free software" company (no matter what it may do with respect to its Swift programming language). But you have to grant them one thing: they're not fooling anybody about their philosophy. They never even tried. They don't "openwash" anything. They don't pretend to be a charity. They want to make money, more than any company before them. But one could not create products more independently and single-handedly than Apple. And all by themselves they have brought about a revolution that the likes of Nokia and Microsoft would never have created.

By contrast, Red Hat's business model is parasitic (though some like to euphemistically describe it as symbiotic). While Red Hat has been a major contributor to Linux, Red Hat became what it is not because of what it did but because of what Linus Torvalds and others had done. And Red Hat is not nearly as honest as Apple. "Not nearly" may even be an understatement.

The question of whether covenants not to sue over patents (which appears to be the structure of the Microsoft-Red Hat deal and would be consistent with a Microsoft Android patent agreement that was filed publicly last year) violate the GPL v2 has not been addressed by a court of law yet. I would actually like to see someone sue Red Hat for breach of the GPL and obtain clarification, but even the Free Software Foundation and its satellite organizations are not as principled as they pretend to be. They never compromise their values per se, but they have their strategic priorities when it comes to where and how forcefully to defend them. It will be interesting to see their reaction to the Microsoft-Red Hat announcement--not in terms of what they say but in terms of what, if anything, they will do. I guess they won't do anything. Why? Red Hat is a donor, Red Hat is a code contributor, the deal offers benefits for "GNU/Linux" as they call it...

I want to give Simon Phipps (with whom I've often disagreed) credit for distinguishing between the positive and not so positive ramifications of this partnership from an open source point of view. The Open Source Initiative is an organization on whose board Simon Phipps serves with, among others, a Red Hat lawyer.

Without the Red Hat connection, Simon Phipps would presumably have criticized Red Hat clearly as opposed to just making it sound like Microsoft should do more. He says Microsoft should relinquish its patent rights because that's how he defines "love" for Linux. However, he doesn't talk about what Red Hat could have done. Red Hat could have challenged any Microsoft patents that allegedly infringe Linux: in court (declaratory judgment actions) and through reexamination requests. That course of action would have done free and open source software a greater service than a deal.

I, too, have a (past) Red Hat connection, but it's none that I would be proud of. Over the decades I've done work for a variety of companies, and Red Hat is the only one I wish I had never worked with. They supported my NoSoftwarePatents campaign in late 2004 and early 2005, probably because they just thought a sponsorship was useful for currying favor with the FOSS community. They were far larger than MySQL AB but contributed a far smaller amount. In terms of commitment relative to company size, MySQL AB was like 100 times more committed to the cause. But the worst part was that shortly before the European Parliament's decisive vote on a software patentability bill, Red Hat tried to keep the legislative proposal alive. The Red Hat lawyer who did so later responded to that, and he never denied the simple truth that he wanted the legislative process to continue.

On this blog I announced, years ago, working relationships with Microsoft and Oracle. Both are a thing of the past. But I would never say that I wasn't proud of them.

The Microsoft I worked with as a consultant was not the Microsoft under Bill Gates that made artificial scarcity of software a strategic objective and got into serious antitrust troubles. I found Microsoft to be no better or worse than the vast majority of companies in this industry. I overestimated the merit of their allegation that Android infringed on many of their patents, but I corrected that assessment more than a year ago based on the results of numerous Android-related patent lawsuits and, after a second-class settlement between Microsoft and Google/Motorola, declared Google the strategic winner. The number one priority of my work for Microsoft was about giving FRAND meaning, a cause I continue to promote (see today's post on Apple v. Ericsson). In that regard, Microsoft was the victim of abusive tactics by Motorola. Sure, that was just Motorola's retaliation for Microsoft's patent assertions against Android, but two wrongs don't make a right (as Microsoft accurately said in the FRAND context).

Oracle has been a longstanding advocate of reasonableness with respect to standard-essential patents, and of open (and ideally free-of-charge) standards. I'm happy to have helped them in that regard, too. As for their Google copyright lawsuit, everyone can see on this blog that I've always taken the same pro-interface-copyright positions. I took them before (going back to a conference in the European Parliament in 2004) and after working against Oracle's acquisition of Sun Microsystems, and before and after doing work for Oracle. I view Google's position on API copyrights as a wholesale attack on the copyright protection of all computer software. Google doesn't call for the abolition of software copyright, but there appears to be no limit to the collateral damage it's willing to inflict to software copyright only to avoid paying Oracle for using Java in Android.

I am now in the most independent position to comment on IP, antitrust and industry policy issues ever. I'll continue to be consistent, just like I'll continue to draw the necessary conclusions from new intelligence (as I did when all those anti-Android patent assertions turned out to have no merit in most cases and negligible merit in the remaining cases). That's why I can just say what I think about the Microsoft-Red Hat deal. I think it's great for Azure, and I like Azure, though my app development company is using it only to a small extent and will use a different cloud service provider for most purposes. The free and open source software community should, however, be opposed to this and shouldn't trust Red Hat with respect to patents. They weren't trustworthy with respect to the European legislative process on software patents; they weren't trustworthy with respect to various settlements with patent trolls; and they aren't trustworthy now in connection with what appears to be a covenant not to sue, which is a license by any other name, with Microsoft, when the alternative would have been to bring a declaratory judgment action that says "Linux does not infringe a single valid Microsoft patent claim and we're now going to prove it."

It's one thing to be a Linux parasite. It's another to be a Trojan horse. And the worst option is to be both at the same time.

If you'd like to be updated on the smartphone patent disputes and other intellectual property matters I cover, please subscribe to my RSS feed (in the right-hand column) and/or follow me on Twitter @FOSSpatents and Google+.

Follow @FOSSpatents

Share with other professionals via LinkedIn:

As the founder of an app development company with one Swift-based project underway, I was excited to hear about Apple's decision, announced yesterday at its WWDC, to open-source the next generation of its latest and greatest programming language. I'll say a few more things about my own perspective at the end of this post (just in case anyone cares to know) but before we get there I'd like to focus on the broader strategic implications.

According to yesterday's announcement, "Swift source code will be released under an OSI-approved [OSI = Open Source Initiative] permissive license." This means Apple will relinquish its rights in that code to the greatest extent it can under all the kinds of software licenses I know. "Permissive" means Microsoft, Google, Samsung (Tizen) and anyone else can just take that code and incorporate it, for free, into their own products, including closed-source, commercial offerings.

The alternative for open-sourcing Swift would have been to release the Swift source code under a copyleft license such as the GPL. That license would give users the same rights but also impose an important obligation: any derivative product would have to be made available on copyleft terms as well. I know the Free Software movement doesn't like the terms "viral" or "infectuous." But I mean them non-judgmentally and they describe the effect. If the smallest piece of a larger work is GPL'd, the whole thing must be GPL'd, too.

The copyleft "share-alike" obligation would have been a poison pill at least for Microsoft and Google. The whole Oracle v. Google Android-Java copyright infringement litigation would never have happened if Google had adopted Java under the GPL (the license under which Sun Microsystems already made Java code available before being acquired by Oracle), but it feared that copyleft would prevent its device makers from differentiating through proprietary add-ons.

The original right holder, Apple in this case, still remains free to make the same code available on two ("dual-licensing") or more licenses in parallel. So Apple could have protected its own ecosystem from copyleft, and could have negotiated case-by-case licenses with others in the industry for the same purpose, while forcing the rest to make an all-or-nothing decision. I have my own (positive) experience with dual licensing as an early shareholder (more than 10 years ago) in MySQL AB, maker of the namesake open source database (which was later acquired by Sun, thus got bought by Oracle alongside Java).

The first beneficiary of Apple's choice of license type that comes to my mind is Microsoft (and, by extension, companies like mine who would like to build Windows versions of their apps provided it doesn't cost us much time). In April, Microsoft announced that it would make the porting of Android and iOS apps to Windows easier. They weren't talking about emulation, just about letting us compile Objective-C and Java code under Windows and giving us direct replacements for key iOS and Android API functions. It was more about familiarity than compatibility, but still very useful. Support for Swift was not announced at the time. With Swift becoming available under a permissive open source license, however, it should only be a matter of time, and probably not a whole lot of time, until Microsoft supports Swift as well. It would be crazy if it didn't.

Sure, Apple could theoretically do the same with .NET and its Common Language Runtime, which Microsoft released under the permissive MIT license. But it wouldn't make sense because Apple doesn't need this to attract developers to its platform. In the post-PC world, Apple is the #1 in economic terms, Google has the largest user base, and Microsoft is a distant third by either measure. If the primary winner and the primary loser in a given market adopt the very same licensing strategy for their platforms, there are only two possibilities: either their license choice is the only one that makes sense regardless of how successful or unsuccessful you've been (for example, it might be great for the ones at the top and the ones at the bottom but squeeze the one(s) in the middle) or one of them has made the wrong choice.

It will take years to find out which of the two is the case. This here is not a prediction post; I just want to discuss the potential implications.

Apple has undoubtedly thought about what Microsoft and Google (and others) might do now. Microsoft will benefit, and I could see Tizen benefit in a similar way. Google has a huge developer base that is happy with Java, and if it ever wanted to replace Java, there's a couple of alternative languages that it's been developing for some time.

Apple may feel that neither Windows nor Tizen are ever going to be a threat, no matter how small the effort to port Swift apps to those platforms might be in the future. Apple could even hope that more market share for Windows and Tizen will just hurt Google (divide and conquer, sort of).

But what is Apple trying to achieve here? A permissive open source license for Swift is the answer... but what is the question?

If Swift had adoption problems, open-sourcing it would be a Hail Mary. But in only a year it has experienced an incredible uptake. App developers have understood quickly that Objective-C is just a legacy and in a few years it may be deprecated.

I already thought five years ago that Android was going to do to the iPhone what Windows had done to the Macintosh. It could still happen, but not too soon. The one thing that would really threaten Apple's business model would be if app developers decided to put major new releases out on Android first, or invested more in their Android versions than in their iOS versions. There comes a point when the collective innovative capacity of an entire ecosystem dwarfs even that of the world's most valuable corporation. It was the Windows ecosystem, not Microsoft alone, who marginalized the Mac. However, as of now, those network effects are still favorable to Apple, simply because its customers spend more on and especially inside apps, so app developers (like my little company) have a greater opportunity, depending on their geographic target markets of course, on iOS. It's also a prestige thing to succeed on iOS. "If you can make it there, you can make it anywhere."

Even in Germany, where I see far more Android than iOS devices on trains and in public places, Google Play revenues have just recently, according to at least one market research firm, exceeded App Store revenues. On a worldwide basis, the Play Store appears to be catching up slowly, and an increasing reliance of app developers on advertising revenues (for example, giving you in-game coins in exchange for watching video ads) could also benefit Android over time. But iOS is still in a strong and safe position, probably due in part to the fact that many Android phones are technically smartphones but practically used like dumbphones. And even if Apple feared Android's ability to close the gap, what good would it do to open-source Swift?

It's really a mystery to me. The iPhone and iPad don't need this; for the Mac it would actually have been an opportunity to be the desktop platform that iPhone/iPad developers can support with the smallest effort, but if Microsoft adopts Swift in some way, this will be just as much of an opportunity for the Windows desktop and, by extension, for devices like the Surface. And on the desktop, the collective purchasing power of all Windows users is clearly greater than that of the Mac user base.

Even in the absolute best-case scenario for Swift, a permissive license would then enable Google (or any company in its ecosystem) to make it easy to port Swift apps to Android. The effect would be commoditization, which is not in the interest of the one with the highest profit margins.

If this strategy didn't work out for Apple, for example because of others having a greater benefit from it than Apple itself, it could always release a future version of Swift -- 3.0, 4.0, or later -- exclusively under a proprietary software license. It can't re-close the source code published by then, but it has no obligation to publish more code on open source terms. And that's why the rest of the industry, in the absence of a multi-company consortium that would control future development of the language, won't rely on Apple's newfound openness anyway. They will just evaluate ways in which they can opportunistically benefit from it. "Embrace, extend, extinguish" will be hard as long as Apple invests significantly in Swift, but it's not impossible.

I'm sure the Free Software movement is very disappointed right now that Apple, like Microsoft, has chosen a permissive software license rather than the GPL. However, permissive licensing might turn out not to be in Apple's commercial interests, and maybe a future version of Swift will be published under the GPL.

[Update] I've received messages via social media stressing that Apple won't open-source the Cocoa APIs. Right: just the compiler and the standard libraries. But this isn't about wholesale emulation. It's about Microsoft (and possibly others in the future) letting you stay in the programming language in which you've developed your original app and giving you replacement API functions. [/Update]

Own perspective

At the beginning of this post I said I was going to focus on the broader, industry-wide strategic implications of Apple's licensing decision and would talk about my own company's perspective only at the end. I've mentioned my game development plans on various occasions since the second half of 2013. I haven't announced any title or even a genre, so arguably this isn't "vaporware," but it's true that it's taken a lot longer already than I would have thought. Part of the reason is that I firstly had to restructure my work so as to be able to focus almost 100% on app development. An even bigger part is that the original project became ever more ambitious, and late last year I decided to start a second project in parallel, with external developers. The internal project will result in a game that I want to revolutionize an old genre. My goal is that people who look at it think it's 90 or 95% new and only 5% or 10% of it is what they have already seen in other games in that category. The second project will have a completely novel task at its center, as the Rubik's Cube or Tetris had. It's not a blend of existing categories either. It will create a whole new category. You'll see.

Right now both games are well on track to be released in the second half of the year, in the fourth quarter more likely than in the third. And both will be published on iOS first, though the internal project originally started on Android. Internally we use Swift, and I'm glad we made that choice last year despite its "childhood diseases," but what really made me determine that "iOS first" was the right choice at the moment is that especially for the internal title a large part of the commercial opportunity will be in the U.S. market, where iOS has been able to even regain market share thanks to the iPhone 6. Apple is doing way better at this stage than I would have thought a year or two ago that it would now.

I still like Android a lot and our Android versions will have the same quality as our iOS products, and at some point I hope to port at least the Swift-based game to Windows as well, so Apple's decision to make Swift available under a license that will enable Microsoft to make iOS-to-Windows ports pretty efficient for Swift apps is good news for me. I still don't understand how this will benefit Apple. Maybe I'll find out over the next few years just like I found out that Apple's (largely) failed patent enforcement efforts were unnecessary anyway because of other success factors it benefits from.

If you'd like to be updated on the smartphone patent disputes and other intellectual property matters I cover, please subscribe to my RSS feed (in the right-hand column) and/or follow me on Twitter @FOSSpatents and Google+.

Follow @FOSSpatents

Share with other professionals via LinkedIn:

James Niccolai of the IDG News Service was first to obtain a copy of Oracle's response to Google's petition for writ of certiorari (request for Supreme Court review) in the Android-Java copyright case. Here's the brief (this post continues below the document):

14-12-08 Oracle Response to Google Petition for Writ of Certiorari by Florian Mueller

[フレーム]

This is one of those documents that are most interesting when read backwards. The order in which it lays out Oracle's argument against Google's petition makes sense for those looking at the case for the first time, but after more than four years of coverage on this blog, I guess most of you already know the history of the case and the fact pattern that gave rise to this case in the first place. If the latter is new to you, or if you're looking for a refresher, the "Ann Droid" story Oracle told to the Federal Circuit is a more lively version of it. Then Oracle goes on to explain why the law has always been what it is, and I have viewed it that way for a long time, including a time when I was at loggerheads with Oracle. There's a simple plausibility test for the whole non-copyrightability claim: look at whatever cases Google and its allies show you in which copyrightability was denied (and that's different from finding in favor of fair use); then look at whether the affected material was a similar combination of quantity and originality as in the case of the Java API declaring code, and you'll find in each case that there was no such combination--and you can find numerous examples of cases in which material way less worthy of protection than the Java API declaring code was held copyrightable by U.S. courts. Life's too short to be a broken record, so I'll focus on what's new and what it means in strategic terms. And to that end, it happens to be most fruitful to start at the end.

Interlocutory appeal: why now? why not later?

The very last section argues that Google's interlocutory appeal to the Supreme Court was premature. An interlocutory appeal is an appeal prior to a final judgment. Here, the alternative for Google would have been to let the remand to California happen, to have the judge or another jury decide on "fair use", and to further appeal after losing the case. (Oracle's appeal to the Federal Circuit was not interlocutory because, if it had not been brought, the case would have been over.)

When Google chose not to ask the Federal Circuit for a rehearing, I was already wondering whether Google would focus on "fair use." Maybe Google was also thinking about the pro's and con's then, but at any event it decided it wants to take this case directly to the Supreme Court.

That, all by itself, does not mean Google's petition will fail. As the SCOTUSblog wrote in 2005, "the importance of the interlocutory status of a case is often grossly overstated." In reality, "[t]he Court regularly grants cert in non-final cases that raise important issues even when the proceedings on remand could illuminate the record in relevant respects and could affect the legal issue presented."

In this case, there is an extraordinarily strong connection between the questions of copyrightability and fair use, and that is so because of the way Google elected to argue the case in district court and on appeal. Oracle is right that Google can't seriously claim the software industry needs a quick resolution of an alleged "circuit split" (inconsistencies between different regional appeals courts) that it claims has existed for decades when the U.S. software industry, and especially the software industry in the Ninth Circuit (i.e., the West Coast, meaning mostly Silicon Valley and Microsoft), undoubtedly thrived. Still, the interlocutory status of the case doesn't guarantee the failure of Google's petition (nor does it make things any easier for Google given the huge number of petitions the Supreme Court receives).

The reason I'm interested in this has nothing to do with what the Supreme Court may or may not decide. Other factors are going to have more weight in that regard, so in case the Supreme Court denies the petition, the interlocutory status probably won't have been the reason. The most interesting aspect is that Google, to say it cautiously, does not quite exude confidence in its "fair use" defense with this tactical choice. It's old news that I don't buy the "fair use" defense here. But if Google really believes in it, why doesn't it just let the case go back to district court, try to win the "fair use" debate based on its "compatibility" argument, and if Oracle appealed again, Google could still try to take the copyrightability part, if it became necessary, to the Supreme Court? This is conjectural but the more I think about it, the more I feel that Google is not nearly as convinced of its two defenses-- non-copyrightability and "fair use"--as it claims and as its supporters claim. The Federal Circuit provided some guidance on "fair use" that ups the ante for Google, and what will up the ante to an even greater extent is that its equitable defenses failed, enabling Oracle on remand to ask the district court to preclude Google from making certain arguments that the first jury (with a bright foreman who couldn't dissuade other jurors from an illogical stance) probably thought had a bearing on "fair use" (Schwartz testimony etc.).

I can't see a winning strategy here for Google with respect to copyrightability, and its only chance with fair use is to get another jury involved that doesn't figure it out, though it will be easier to figure out next time. I wouldn't put it past Google that this here is mostly about delaying the resolution of the case. Nonsensical arguments like saying the software industry (which is mostly on Oracle's side anyway) needs this resolved immediately don't look strong.

There's another indication (that is not in the Supreme Court briefs) of Google's lack of faith in its defenses. Yesterday, Google finally released the first official non-beta version of Android Studio, version 1.0. The Android developers on the team I'm leading and I really like Android Studio (in light of Apple's Swift, Google should do even more to increase developer productivity). But somehow Google is cautious about directly integrating Java material into Android Studio, as this Stack Overflow discussion shows (it slightly predates version 1.0, but the situation is still the same). This doesn't solve Google's entire Java copyright problem. Still, what reason other than a desire to at least limit the extent of the problem would Google have to deliver an IDE--which means Integrated Development Environment--without fully integrating Java, if it's supposedly for the taking?

Google's petition addresses only one of the two reasons for which the Federal Circuit agreed with Oracle

The first subsection of the last section of Oracle's brief is short--merely two paragraphs--but raises an important issue:

"Although one would never know it from Google's petition, the court of appeals found that Oracle's work is protected on two separate bases: (1) the original declaring code and (2) the packages' creative structure and organization."

This is correct. Here's a quote from the Federal Circuit's own summary of its reasoning:

"[W]e conclude that the declaring code and the structure, sequence, and organization of the 37 Java API packages are entitled to copyright protection."

Oracle notes that Google's petition is all about the declaring code per se and "does not address the structure-and-organization rationale." According to Oracle, the failure to address an adequate alternative basis for affirmance means the petition must be denied.

Google's request for Supreme Court review (unlike certain amicus curiae briefs) is all about the functional nature of code. However, as Oracle writes in its response, "[w]hatever might be said about declaring code, the structure and organization is not used 'to operate the methods, i.e., the pre-written programs.'"

This potential reason for denying Google's petition is closely related to what Oracle says in the next subsection: Google now bases its theory on "system" and "method of operation" in the cert petition "[b]ut in the court of appeals, Google made no such argument."

I've said it before: Google's approach does not exude confidence. In its quest for some reason to get 7,000 lines of highly creative (and creatively-structured) material held uncopyrightable, it isn't consistent.

It would be easy for the Supreme Court to deny Google's petition

The previous paragraphs discussed potential reasons for a denial of Google's petition beyond the simple fact that such a massive body of highly creative (and creatively-structured), original, expressive material has always been and will always have to be copyrightable.

This article discusses how litigants are most likely to succeed in opposing a cert petition and says the following about the top court's selection criteria:

"Instead of seeking merely to correct erroneous decisions, the Court is looking, Chief Justice Rehnquist has written, for cases 'involving unsettled questions of federal constitutional or statutory law of general interest.'"

Google's primary argument for presenting an "unsettled" question is that the Supreme Court was divided a long time ago over 50 words used as menu items. As Oracle's response to the petition clarifies, that is not a question of software copyrightability. The way I view it is (apart from the question of whether we're talking about text or code) that if the Supreme Court didn't unanimously hold those menu items uncopyrightable, Cisco is fine with its 500 multi-word commands, but even those multi-word commands are very simple if you compare them to some of the more complex lines of declaring code in Oracle's Java APIs, such as this example cited by Oracle in its brief:

public abstract void verify (PublicKey key, String sigProvider)
throws CertificateException, NoSuchAlgorithmException, InvalidKeyException, NoSuchProviderException, SignatureException

That's a lot longer than the Math.Max example Google and its supporters like to point to (and which may have helped Google to confuse the district judge).

Oracle's brief also notes that one can't compare (as Google did in its petition) the QWERTY keyboard layout (the order of a couple dozen keys) to declaring code like the line above.

Getting back to Judge Rehnquist's criteria, it has to be a combination of "unsettled" and "of general interest." Unless one lowers the standard, there is no such combination here.

When I read Google's brief and the amicus briefs urging a review, I can't help but feel that they base their hopes on factors that reside at a meta-level rather than the factual, logical level. They try to make this a case that is all about interoperability, and I'll talk about that in the next section of this post. They try (some more overtly, some more subtly) to capitalize on what they believe to be friction between the Supreme Court and the Federal Circuit.

It won't be easy for them to get a Supreme Court review on that basis, but even if they did, I still can't see how they could ultimately prevail at that meta-level.

"Partial interoperability" is a contradiction in terms, says Oracle

While not putting those Sony and Sega fair use cases front and center at this juncture, Google still tries to leverage the (important) concept of "interoperability" (or its synonym, "compatibility") to get the Supreme Court interested. Oracle makes a few references to this in its brief that I wish to highlight.

In connection with "overwhelming [record evidence] that Android is incompatible with the Java platform," Oracle describes the notion of "partial interoperability" as a "contradiction in terms." If products are interoperable, they work together. If they are not, they don't. They can obviously work together to varying degrees, but the problem in this case is that what Google and the district judge meant by "partial interoperability" would more accurately be labeled as "familiarity." Interoperability happens (or doesn't happen) at the technical level, while familiarity is a state of mind. Some will argue that one can make changes to Java code in order to make it run on Android, and vice versa. But apart from this kind of definition having no boundary, it involves some additional work to be performed by human beings.

Google didn't advance the cause of interoperability when it sought to shut down Microsoft products implementing two industry standards (a jury thought this behavior warranted a 14ドル.5 million damages award). It won't do the concept a favor by trying to stretch the definition of the term beyond recognition. So I, too, believe that "partial interoperability"--the way the district court and Google meant it--is a logical fallacy.

Oracle also addresses Google's argument that Oracle's asserted code must be devoid of copyright protection in order to prevent a "lock-in":

"[B]ecause Google deliberately made Android incompatible, when a programmer writes for Android, that programmer and program are locked into Android and locked out of the Java platform.

In the policy context, Oracle firmly rejects Google's (and Google's friends') argument that such material as the Java API declaring code would have to be free for the taking in order to enable innovation:

"Google is wrong that unauthorized copying of others' code is just how the software industry works."

Oracle doesn't say that incremental innovation shouldn't occur. The question is just on which basis. Building on top of what others create and making products work together with existing ones, or making them run on existing platforms is fine, as long as you write your own code. Using what others created is fine if you take a license. But "[t]heft is theft whether the work is a novel or complex software." Except, of course, if the "fair use" defense applies (which could be evaluated very quickly if the Supreme Court denied Google's petition).

Free software advocates speak out against the Federal Circuit and Google's petition

The Free Software Foundation and the Software Freedom Law Center have filed an amicus brief that technically (but not substantively) supports Oracle. The free software advocates engage in a balancing act. They are on Google's side with respect to copyright and with respect to copyleft, but they have a procedural preference for denial of Google's cert petition.

I've read their brief and would just like to explain what I believe their strategy is, and the philosophical and legal issues involved.

Richard Stallman, the founder and president of the FSF, leads the life of an itinerant preacher and one can only admire him for how committed he is to his cause. I've disagreed with Eben Moglen, who used to be the FSF's counsel for some time and still works closely with the FSF through his Software Freedom Law Center, on more than one occasion, but he's always extremely interesting to listen to.

Tim O'Reilly described the problem with the free software philosophy more than seven years ago:

"I continue to feel that the focus of the free software movement on 'software' rather than on 'freedom' is the real lost opportunity. [...] Focusing only on free software is as limiting as focusing on free hardware. It's freedom that matters."

The GPL licensing regime puts the freedom of program code above the freedom of developers. The copyleft principle requires all derivative works including GPL-licensed code to be made available under the GPL. This ensures that one cannot enjoy the freedoms granted to him by the GPL and then publish a derivative work under, for example, a proprietary, closed-source license. By contrast, non-copyleft open source licenses don't guarantee that the related code will always remain available on the same terms, but they give commercial software developers the freedom to incorporate it into their products.

The GPL is not about freedom-freedom. It's about enforceable freedom. And in order for anyone to enforce the GPL, the legal system as it stands (where copyleft is not enshrined in statutory law) only offers copyright for a basis. Copyleft wouldn't work without copyright enforcement. Yes, this is an oxymoron.

The dependence of copyleft on copyright is why Richard Stallman counterintuitively criticized the Pirate Party for proposing to limit copyright terms. RMS (he's frequently referred to by his initials) warned that this would allow "marauding giants" to incorporate free software into non-free software after only a few years. For someone advocating general freedom as opposed to just software freedom, this wouldn't be a big deal: one could simply let both approaches, free software and commercial software, compete. But that's not acceptable to the free software community.

RMS and Eben Moglen are copyright minimalists. They want just the level of copyright protection that is needed to make the GPL work in principle. Anything beyond that is undesirable to them. The Pirate Party proposed a copyright reform that would fall short of what the GPL needs. But other than that, less copyright is more if you ask RMS or Professor Moglen.

And now comes the part where they are demonstrably inconsistent. While they generally don't want commercial software developers to incorporate free software into their products ("marauding giants"), and while Richard Stallman considers commercial software to be immoral, they still know that the popularity of Linux (GNU/Linux as they would call it) depends on the availability of non-GPL software (other open source software as well as commercial software) for Linux.

If they were 100% principled, they'd have to like the Federal Circuit's clarification of longstanding principles of U.S. copyright law because it can prove useful in GPL enforement, or at least they should be neutral about it because free software is not made any less free by it. But their objective now is to describe the Federal Circuit opinion (incorrectly) as an outlier that shouldn't have any weight going forward. That's what their brief is really about. They don't want the Supreme Court to look at it because (without saying so) they're afraid of the outcome, knowing that the law is what it is and has been for a long time. If the Supreme Court granted certiorari, the free software guys might file another brief or just hope that what they submitted yesterday would help Google at that stage. But ideally, they just want the process to end. They want to have their cake and eat it. They try hard (but in my eyes fail) to hide the fact that this initiative of theirs runs counter to free software philosophy and is driven by the less than principled desire to let free software like Linux power non-free software like Android.

One of their claims is that the copyrightability question plays no role in this dispute because Google could always use the relevant material under the GPL. The commercial reality is that Google doesn't want to release Android under the GPL. It's a complete non sequitur to me in the FSF/SFLC brief how Google could use the Java API declaring code under the GPL, incorporate it deeply into its own products, and not have a copyleft "share-alike" obligation. So the free software brief is more of a mystery than it provides clarification. The greatest mystery is how the GPL would moot the question of past damages. But frankly, it's not worth worrying about.

The FSF/SFLC brief does, however, show to the Supreme Court that even some of those who don't like the Federal Circuit opinion would like the case to go back to district court now for a "fair use" analysis.

I don't know if any other amicus briefs will be filed. Presumably the software industry at large is just fine with the Federal Circuit ruling, which means business as usual.

If you'd like to be updated on the smartphone patent disputes and other intellectual property matters I cover, please subscribe to my RSS feed (in the right-hand column) and/or follow me on Twitter @FOSSpatents and Google+.

Follow @FOSSpatents

Share with other professionals via LinkedIn:

The Microsoft-Samsung contract dispute in the Southern District of New York over the implications of Microsoft's acquisition of Nokia's wireless device business for the parties' 2011 Android/Chrome patent license agreement has already exceeded my expectations concerning transparency. Three weeks ago this case brought to light that Samsung forked over more than a billion dollars in patent royalties on its Android/Chrome devices to Microsoft in the 12-month period from July 2012 to June 2013. Last week, a Samsung motion to compel arbitration explained certain interdependencies between the parties' Android/Chrome patent license agreement and a second contract, a Windows- and Windows Phone-related business collaboration agreement.

Here comes the latest and greatest revelation, which in certain respects is of even greater interest than the billion-dollar figure: yesterday, Samsung's counsel in the New York case had to file a public redacted version of the declaration supporting Samsung's motion for referral to arbitration, including the key exhibits--the patent license agreement and the business collaboration agreement.

The following PDF document contains the declaration and the redacted versions of the two contracts (this post continues below the document):

Redacted version of Microsoft's 2011 contracts with Samsung.pdf by Florian Mueller

[フレーム]

These contracts are interesting from different angles. One of them is Samsung's motion to compel arbitration. At first sight (and I will have to look at it more closely and think about it some more) it does appear that the two contracts, both of which were concluded within a couple of months of each other, are indeed closely connected. The business collaboration agreement was signed first but already referred to credits (based on Samsung's success with Windows devices) against Android/Chrome-related license fees. Technically they both have the same date: July 1, 2011.

The aspect I found most interesting is all about exclusions. While the license agreement is not limited to a particular list of patents, it's no total-portfolio license either. There are two key limitations: "Excluded Technologies" and "Excluded Software" (any software licensed under an "Excluded License").

As for excluded technologies, Microsoft did not license to Samsung any of its patents relating to

1. Kinect-style gesture-based functionality (this exclusion has nothing to do with touchscreen gesture control, as the contract clarifies),

2. Virtual Reality, and

3. "Information Worker Software": a software or a service "designed or offered as a replacement" of Microsoft's office applications, with OpenOffice and LibreOffice being specifically mentioned as replacements for one or more Office components.

The definition of "Excluded License" includes any version of the GPL, LGPL, Mozilla Public License, and Common Public License, or similar licenses with a copyleft (share-alike) feature. This exclusion, however, relates only to "Other Samsung Products" and not to Samsung's Android and Chrome devices, where the only excluded license is the GPLv3. In other words, the license agreement does cover the GPLv2 parts of Android, such as the GNU operating system and the Linux kernel. This might spark some debate in Free Software circles. It also reminds me of what I said four years ago when there was a debate raging in Europe over "open standards" and the compatibility of free and open source software with FRAND (fair, reasonable and non-discriminatory) licensing terms. I said that patent royalties are paid on free and open source software, including GPLv2 software such as Linux, all the time, also by such companies as Red Hat. The now-public terms of the Microsoft-Samsung patent license agreement are another example.

Besides the actual exclusions I mentioned, there's also a mechanism in the contract that can lead to the exclusion of a category of devices. There are special rules in the contract for a "Deferred Android Device," defined as "an Android/Chrome Device that (a) does not have voice communication as a primary functionality, (b) has web browsing as a primary functionality and (c) has a display screen no larger than 6.25 inches across its diagonal." For such devices, the contract requires the parties to take certain steps for the purpose of agreeing on a license fee on such a device, but if the parties couldn't agree on a fee, then such devices would just not be covered by the license agreement.

If you'd like to be updated on the smartphone patent disputes and other intellectual property matters I cover, please subscribe to my RSS feed (in the right-hand column) and/or follow me on Twitter @FOSSpatents and Google+.

Follow @FOSSpatents

Share with other professionals via LinkedIn:

After Google's recent--and expected (this blog was first to report that it was coming)--petition to the Supreme Court of the United States for writ of certiorari (i.e., for a review of the Federal Circuit's decision in Oracle's favor, see my refresher Q&A after the appellate decision), I have seen a couple of articles that described the state of affairs and quoted observers on what all of this meant. In addition, I've seen all sorts of tweets. I don't want to link to them and criticize websites, authors, tweeters, and analysts (some of whom I actually like), but I do see a need to highlight the fundamental flaws in some of the commentary out there. Since the current state of the case--with Oracle being on the winning track--is consistent with what this blog has been saying for years no matter what the mainstream thought and claimed, I feel a certain responsibility to point out some important facts.

These are the most "popular" misconceptions (click on any one of them to jump directly to further detail):

1. Misconception: the stakes in this case are 1ドル billion.
   Reality: the strategic value to Oracle of bringing Android back into the Java fold, as opposed to Java being hijacked forever by Android, is a whole lot greater.

2. Misconception: this is about the right to write applications for platforms, including the right to write interoperable cloud services.
   Reality: it's only about partial or complete clones of platforms.

3. Misconception: third-party, independent implementations of APIs would become illegal unless the Federal Circuit ruling was reversed.
   Reality: copyrightability is only the first of several criteria that must be met in order for an independent API implementation to be unlawful. Many roads lead to Rome, i.e., API freedom.

4. Misconception: this is about control over the Java programming language, which Sun had said was free (or, by extension, any other programming language).
   Reality: the commands of the Java programming language are not, and never were, at issue. Google used the "free Java" promise as an equitable defense, which failed in district court and which Google didn't even try to resuscitate on appeal.

5. Misconception: this is about open-source implementations of the Java APIs.
   Reality: this case changes nothing at all about everyone's freedom to develop free and open-source Java API implementations under the GPL. Even Google never claimed so in court. Android is not published under the GPL.

6. Misconception: definitions of basic functions such as a Math.Max (greater of two values) method would become copyrightable.
   Reality: this is about the overall creativity that went into 37 Java APIs, which contain many definitions of great complexity, and their structure, sequence and organization, not about simple, isolated lines of code.

7. Misconception: the district judge got it all right because he learned to program Java, thus the appeals court must be wrong.
   Reality: not only is the Federal Circuit ruling legally stronger but it is also more accurate in technical terms.

8. Misconception: a certain "G" blog was, while it was active, a reliable source of information on this case.
   Reality: while that blog did a great job on a different copyright case a long time ago, it was off-base on Oracle v. Google.

Now the more detailed explanations.

Misconception: the stakes in this case are 1ドル billion.
Reality: the strategic value to Oracle of bringing Android back into the Java fold, as opposed to Java being hijacked forever by Android, is a whole lot greater.

It's not unique to this case but a general problem with litigation reporting that the claims formally brought and taken to trial (and, such as in patent cases against smartphone makers, the products formally accused) can be stated in ways that are not inaccurate in the narrowest sense of the word but don't reflect a plaintiff's strategic priorities.

I've come up with a new analogy: during the 2008 electoral campaign, it would have been numerically correct--but would have missed the point, which is why no one did it in that context--to describe the objective of the Obama campaign as "a senator from Illinois seeking a pay raise from 174,000ドル to 400,000ドル per year." In reality, Barack Obama would have been happy to become president for an annual salary of 1ドル (he was making millions from book royalties anyway). Mischaracterizations of this kind, which would be unthinkable in political journalism, occur on a daily basis in legal journalism.

Here, Oracle itself made very clear at a key juncture in the district court proceedings that its #1, #2, #3, #4 and #5 objective was a copyright injunction. Obviously, either company's--and any other company's--CFO will care about a billion-dollar amount going in or going out. But if the only net effect of this protracted litigation was a billion-dollar payment from Google to Oracle, and maybe some reputational implications for the convicted infringer, none of us (besides those companies' CFOs) would really have to care.

The remedies the statutes allow are just a means to an end. In some ancient cultures you could have asked the judge or king for anything to right a wrong, and the decision-maker had unlimited leeway, including the option of telling Google to make Android Java-compatible. Not so now, where we have statutory law and a rich body of binding case law. The prevailing (or likely-to-prevail) right holder will then sit down with the other party and work out a solution, but needs monetary and, even more so, non-monetary remedies to have leverage.

In my refresher Q&A after the appellate ruling, I already said that this case was not really about a billion dollars.

Misconception: this is about the right to write applications for platforms, including the right to write interoperable cloud services.
Reality: it's only about partial or complete clones of platforms.

I've previously criticized that certain amicus briefs (and campaigns to orchestrate support for amicus briefs) overbroadly and insolubly vaguely referred to the "use" of APIs.

The most common use of APIs is simply to write applications for a platform, or applications that communicate with cloud services, where APIs are communications protocols. That's what zillions of programmers do every day. Compared to that most common use of APIs, there's only a very small, almost negligible number of companies and developers that create partial or complete clones of platforms.

No app or cloud developer needs to worry that Oracle's enforcement efforts against Google have anything to do with the most common form in which APIs are used. This is not about Google having written Java apps.

If a company makes the APIs of its platform or cloud service available to third-party developers, it will normally be estopped (precluded because of its own actions) from enforcing API copyrights against those who reasonably rely on the right holder's interest in attracting developers to a platform. Developers would also be able to raise a "fair use" defense. But all of this is very theoretical because, in practice, a platform maker won't suddenly turn around against developers: it will continue to court them.

Misconception: third-party, independent implementations of APIs would become illegal unless the Federal Circuit ruling was reversed.
Reality: copyrightability is only the first of several criteria that must be met in order for an independent API implementation to be unlawful. Many roads lead to Rome, i.e., API freedom.

The Oracle v. Google case is a pretty good showcase of the various defenses an alleged copyright infringer can raise. That's why it's all the more misguided that some people look at the legality of third-party API implementations exclusively through the (non-)copyrightability lens.

The Federal Circuit remanded the case to the district court for a new trial on "fair use." That defense was not adjudicated at the first trial. The jury was hung, which meant that the issue needed to be revisited unless the material at issue wouldn't have been copyrightable, which would be dispositive in its own right (and which is what Judge Alsup thought but the Federal Circuit disagrees with). In this particular case, I don't think Google's "fair use" argument has merit, but there could be other cases in which independent implementers of APIs could prevail on the grounds of fair use.

The Federal Circuit also mentioned, in a footnote, the possibility of a compulsory license on FRAND terms. In cases of extreme market power, this is a last--but often effective--resort.

In a case in which a platform maker encourages widespread adoption of an API (and not just of the commands of a programming language), equitable defenses could also tip the scales in a defendant's favor. (Google's equitable defenses in this case failed, and Google didn't even try to revive them on appeal.)

It's unsophisticated at best and intellectually dishonest at worst to limit the question of independent API implementations to copyrightability, which is an extremely coarse filter because it does not enable fact-specific case-by-case determinations.

Misconception: this is about control over the Java programming language, which Sun had said was free (or, by extension, any other programming language).
Reality: the commands of the Java programming language are not, and never were, at issue. Google used the "free Java" promise as an equitable defense, which failed in district court and which Google didn't even try to resuscitate on appeal.

Sun encouraged everyone to implement the Java language. Its commands and keywords and syntax. But even the district court (whose non-copyrightability finding Google's supporters love so much) stated clearly that Google had failed "to prove an overt act by Oracle and/or Sun relaying its intent to abandon rights as to the specific elements asserted here." Relatively speaking, a 2007 blog post by then-Sun-CEO Jonathan Schwartz was Google's best argument, and even that one fell far short of what would have helped Google with respect to the intellectual property rights Oracle actually asserted in court.

The Federal Circuit was aware (as its ruling indicated) that there may be material in 3 of the 37 Java APIs at issue that one could describe as being inextricably linked to the Java language--but only 3 out of 37.

It speaks volumes that Google didn't try to get the appeals court to revive those equitable defenses.

Misconception: this is about open-source implementations of the Java APIs.
Reality: this case changes nothing at all about everyone's freedom to develop free and open-source Java API implementations under the GPL. Even Google never claimed so in court. Android is not published under the GPL.

A long time ago, Sun made certain Java material available under the GPL (GNU General Public License), a free and open-source software license. The key characteristic of the GPL is the "copyleft" principle: if you obtain a program under the GPL and modify it, you're not allowed to publish your modified version under a license that would deprive others of the freedoms the GPL had afforded you in the first place. In the Creative Commons universe, this principle is called "share-alike": share on the same or substantially similar terms as the ones you benefited from.

Google never opted for the GPL route. Otherwise it would have had to publish Android as a whole under the GPL. As a result, device makers would have had to publish their proprietary extensions (things like Motoblur, HTC Sense, Samsung TouchWiz etc.) under the GPL as well. This would have made it practically impossible for OEMs to differentiate through proprietary Android extensions. So none of the key players in the Open Handset Alliance would have liked the idea.

With or without the Federal Circuit copyrightability determination, the GPL applies, always has applied, and always will apply, to the open-sourced parts of Java. But that is not a commercial option for Google. For the open-source community it would be, and actually is, an option. After Oracle sued Google, the Free Software Foundation actually reminded people of the fact that Google could have avoided the whole problem by using Java on GPL terms.

API copyrightability makes the GPL's copyleft feature even stronger, but it's pretty strong in any event.

Google mentioned open source a lot in the early stages of this dispute. But it never raised a contract-based (license-based) defense. Not pursuing the equitable defenses on appeal was weak, but never even raising a GPL-based defense was weaker than weak. The smokescreen nevertheless worked with people who don't know how the GPL works and with some who did but intentionally misled the rest.

Misconception: definitions of basic functions such as Math.Max (greater of two values) method would become copyrightable.
Reality: this is about the overall creativity that went into 37 Java APIs, which contain many definitions of great complexity, and their structure, sequence and organization, not about simple, isolated lines of code.

What Oracle is asserting in this case is a body of 37 Java APIs with a total of approximately 7,000 lines of declaring code. Neither Oracle's theories nor the Federal Circuit ruling suggested that the threshold for copyrightability would be lowered to the point at which the definition of a Math.Max function would have become copyrightable in its own right. The hurdle isn't high, and the Federal Circuit threw out Google's attempts to have items like the nine-line RangeCheck function declared uncopyrightable. But if you want to get a single line of program code protected by copyright, you better present something reasonably expressive and creative.

A week ago I explained, toward the end of a blog post on how Google's argument has become an all-out attack on all software copyright (rather than a surgical strike against API copyrights), that Google misportrays the Federal Circuit's rationale by suggesting that anything that can be written in more than one way would automatically be copyrightable. I also looked at it mathematically. Even if one looked at only 70 (1% of 7,000) of the lines of declaring code at issue and assumed only an average of 3 alternatives per line (way too low), the number of possible combinations would have more than 30 zeros, not even counting possible permutations because different lines could be assigned to different packages, and for any given code there could be many different numbers of packages.

Misconception: the district judge got it all right because he learned to program Java, thus the appeals court must be wrong.
Reality: not only is the Federal Circuit ruling legally stronger but it is also more accurate in technical terms.

I can only shake my head when I read in certain articles that people were sooooooo impressed by the judge saying he learned Java, as he told Oracle's counsel in open court, and that he had programmed, in different languages, something like rangeCheck many times. Sorry, but that's not the way to distinguish between right and wrong decisions. If a judge, or a panel of judges, never programmed one line of code in Java or any other language, but correctly applies the basic rules of U.S. copyright law and correctly interprets the statute (particularly § 102) and the case law (including the Sega and Sony stuff Google's cert petition doesn't even cite to, despite references to multiple decisions by appeals courts, including other decisions by the Ninth Circuit), then that's what matters. And nothing else.

People also forget about the significance of a unanimous decision by a three-judge panel (at the Federal Circuit) as compared to a single judge's opinion.

Judge Alsup was right that programmers perform range checks all the time. Just this year I've written code of that kind on several different occasions. But rangeCheck, which Judge Alsup also deemed copyrightable (a fact some people seem to have forgotten; affirmed by the Federal Circuit, by the way), is not at the heart of this case. The declaring code of the 37 Java APIs is, and the Federal Circuit judges, who never claimed to have learned Java or any other programming language, accurately noted that apart from maybe 3 APIs, those are separate from the Java language, while Judge Alsup conflated language and API issues.

If the measure is whether someone has programming experience, the same people who were behind Judge Alsup's apotheosis after the erroneous 2012 non-copyrightability ruling would actually have had to trust me to a greater extent than a non-programmer paralegal's blog. I've done a lot of programming; it's what I'm doing again (and will go back to right after this post). I wrote 10 computer books, mostly on programming topics, while in high school. One of them was a commented version of the assembly (machine) language code of an entire operating system and language interpreter, of which I can show you a small excerpt (click on the image to enlarge):

So let's please go back to the facts and to what the law says and not make it a question of whom we want to trust, and let's especially not be misled by our enthusiasm for the idea of a judge ruling on a tech case having actual programming knowledge, no matter how much we like the notion.

Misconception: a certain "G" blog was, while it was active, a reliable source of information on this case.
Reality: while that blog did a great job on a different copyright case a long time ago, it was off-base on Oracle v. Google.

Checking in one's brain at the wardrobe in exchange for uncompromised allegiance to Judge Alsup (because he said he learned Java) is a major mistake. What's far worse is blind faith in a (no longer active) blog that wanted the world to believe it was an open discussion forum representative of the sentiment of open-source folks while having been convicted of a particularly malicious form of censorship whenever its own users disagreed with the propaganda and party line.

Further above I've explained why Google never had and never even tried to raise an open-source defense. It's unbelievable that a blog claiming to advocate open-source interests suggested that Google was in the clear thanks to Sun's decision to open-source certain Java material.

At this stage, Oracle v. Google is a copyright-only case, but initially various patents were at issue, and that blog totally blew out of proportion the significance of first Office actions formally "rejecting" patent claims. Most of the time, first Office actions mean very little, and if they are issued by an examiner who (as was the case for some examiners based on a sample that academics studied) initially "rejects" 100% of the challenged claims. A first Office action can be reasonably meaningful if it issues, as it happened in connection with an Apple autocomplete patent, about a year after a decision to reexamine. In that case, the examiner didn't routinely "reject" all claims but must have arrived at a reasonably well-considered conclusion. So one must look carefully at non-final USPTO actions so as not to jump to conclusions, as a certain "G" blog did just because it liked this. One of the initially-"rejected" Oracle patents was actually affirmed by the USPTO right after the start of the 2012 trial, but too late to still be presented to the jury.

The archives of that source of confusion and misinformation are certainly not a good place to start one's research (though I think that blog could have made some useful contributions to other recent debates, such as the way this year's Apple v. Samsung trial in California went).

I've taken consistent positions on API copyright in general and Oracle v. Google in particular at different stages, starting more than ten years ago (when I had a debate at a conference with an EFF staff lawyer on interface copyrights in connection with Blizzard v. bnetd) and even shortly after fighting against Oracle's acquisition of Sun. And I'll continue to defend those beliefs going forward. I'm very confident that the Supreme Court will either deny cert or will otherwise affirm the Federal Circuit. The Supreme Court won't get confused the way parts of the general public, the media, and industry observers apparently do.

If you'd like to be updated on the smartphone patent disputes and other intellectual property matters I cover, please subscribe to my RSS feed (in the right-hand column) and/or follow me on Twitter @FOSSpatents and Google+.

Follow @FOSSpatents

Share with other professionals via LinkedIn: