Could a GPL-style contribute-back clause be a reasonable compromise between Apple's walled garden and the Open App Markets Act?

It is interesting to watch how legislative initiatives, antitrust investigations, and litigation reinforce each other. Yesterday's announcement of the Open App Markets Act proposal by a bipartisan group of United States Senators marks a tipping point. It now seems rather unlikely that Apple can maintain its App Store monopoly on iOS. App store diversity is coming.

Apple may still be in a state of denial, and it can hire every lobbyist in DC and Brussels and elsewhere who isn't already working for its adversaries, but the time may have come to think about whether a reasonable compromise is possible.

I'm as independent as an Apple critic and complainant can be, and have recently remigrated to Android, which is the "lesser evil" in terms of the platform maker's control. I wrote my own antitrust complaints and my replies to Apple's (and Google's) responsive filings--every single word. When it comes to patent disputes, I've been sympathetic to Apple's desire for differentiation and to a certain attitude that could be described as exceptionalism. I do, however, draw the line where Apple denies app developers like me certain liberties that I believe are essential and very much in the interest of consumers.

On the one hand, I reject any arguments by Apple that come down to saying that its customers make the choice to deprive themselves of certain choices (such as access to apps not approved by Apple) and that this kind of choice deserves to be protected to the detriment of app developes and of all those Apple users who actually want more flexibility. Among one billion iOS users worldwide, there must be a diversity of views and positions. Even if they had only 1,000 and not 1,000,000,000 users, they wouldn't all share the same values and preferences.

On the other hand, it can't be reasonably denied that the Open App Markets Act in its proposed form would make the iOS app ecosystem less distinguishable from Android. In the end there would be cross-platform app stores, which would minimize switching costs (a consumer benefit) but further blur the distinction between the operating systems.

I don't claim to have the definitive answer, but I do wish to toss out an idea now: a GP-style reciprocity ("contribute back") clause in Apple's future IP license agreements with app developers.

Let me first describe what the net effect would be from a consumer's point of view:

• There would be more app stores than Apple's App Store.

• It's possible that competing app stores would undercut Apple's prices and/or outperform Apple on app curation.

• Some third-party app stores might do a better job serving a particular audience, such as gamers. That's called specialization.

• Still, under my proposed approach those who are religious about Apple's product philosophy--or simply trust no one as much as they do Apple--would find an Apple-aligned version of every app, except for apps that provide content or functionality Apple categorically disallows, on the App Store. As long as they don't install anything from other app stores, those users could continue to live in Apple's walled garden like before. By choice.

  There are people who don't trust a lot of companies. They are the ones who'd rather buy a new battery for their radio-based car key from an official Mercedes dealership than go to the next Best Buy and get a battery of the same quality at a fraction of the cost. And there are others who subscribe to a philosophy. I want freedom for app developers and users, but I don't want to deprive people of an "all in on Apple" type of choice.

Now some people may wonder how this "best of both worlds" situation could be achieved, given that

• competing app stores would normally have an incentive to enter into exclusive deals with app makers,

• some makers of extremely popular apps might leverage those titles to grow their own app stores, and

• some app developers might for whatever other reason (or just laziness) decide not to submit their apps to the App Store, but only to others (like itch.io).

The answer is a reasonable "contribute-back" obligation that Apple could impose by means of an intellectual property license.

Reciprocity clauses are found in the GPL (GNU General Public License), which is called a "copyleft" license for that reason and known for Linux (the technical basis of Android) and MySQL/MariaDB, and in the versions of the Creative Commons license that come with the "Share Alike" requirement. Those contractual structures have one key objective: whoever incorporates material into their own works under such a license should have to respect those values not only by lip service but also by contributing back to that values-based community the derivative work.

The GPL doesn't prohibit dual licensing. A long time ago I was an adviser to MySQL's CEO, and that company held all the copyrights (which no single entity does in the case of Linux), so they offered it to the whole world for free under the GPL--with the copyleft string attached--or, if you made a deal with them and paid license fees, you could incorporate it into your own products as a software component without having to publish your source code and allow free downloads.

What I'm proposing here for the iOS app ecosystem bears a strong resemblance to "copyleft" and to dual licensing:

• App developers would be free to submit a given app to as many iOS app stores as they please.

• Apple would not "tax" developers' revenues generated via other app stores. (A reasonable developer program fee is not what I mean by "tax.")

• The values-centric "contribute back" clause, however, would impose an obligation on developers to simultaneously--and in good faith--submit their app to the App Store.

  The only exception would be if an app would undoubtedly be rejected by Apple (for example, certain types of adult content). In that case, a submission to Apple would just waste everyone's time.

  Note that there would be no requirement for the app to be actually approved by Apple before other app stores could carry it. It would be submitted to all stores near-simultaneously (such as on the same day). The requirement is just to submit it in good faith.

• "In good faith" means that the App Store version of an app would have to be reasonably compliant. For example, if Apple insists on ad tracking ("ATT"), then a submission that flagrantly and unnecessarily violates that rule would have to be considered a bad-faith submission.

This way, competitive constraints would discipline Apple in many ways. If users found the App Store too expensive, or if Apple rejected too many apps that are worth publishing, or if others made themselves a name by outperforming Apple on curation quality, that could reduce Apple's app market share. The number one issue that Judge Yvonne Gonzalez Rogers raised on the last day of the recent Epic Games v. Apple trial is that Apple may compete for end users, but doesn't have to compete for developers. That's why app store diversity is needed. But a "contribute back" requirement to preserve Apple's differentiation and exceptionalism isn't antithetical to competition--and it means more choice, not less, for consumers.

I believe it would be fair to require developers not to charge more for themselves on Apple's App Store than on others. Developers should just say how much they want, and then the different app stores will add their margins on top. (When I do consulting for financial investors through expert networks, it works that way and I don't even know what the markup is.)

To the extent that Apple dissuades end users from granting that ATT permission, apps should be allowed to give users the choice to either enable ad tracking (particularly with a view to rewarded ads, which are key to ad-based games business models) or pay for certain goodies.

Then there's the question of how easy it should be for users to switch from one app store to another if they wish to use a given app on a different app store's terms. For example, they might download a game from Apple's App Store first, but later have an incentive (such as lower IAP prices) to continue playing that game, but redownload it from a rival app store. One would have to think this through, but where there is a will, there is a way. Consumers should have that choice--and app developers should have the right to inform them of the potential benefits, for the sake of having a serious competitive constraint.

Could there be functional differences? Yes. If Apple disallowed something that other app stores permit, there might be additional features once users download an app from another app store. This goes both ways, of course.

Is this going to happen? I'll be perfectly honest: I think the two sides of the debate are so entrenched that in the end there'll be a winning camp and a losing one instead of a win-win-win-win (Apple, developers, consumers who are totally Apple-aligned, and consumers who are not absolutely loyal to Apple). But at least I wanted to outline my thinking, now that Apple may really begin to think about how to mitigate the damage.

Follow @FOSSpatents

Share with other professionals via LinkedIn:

Share|

Hypocritical Red Hat hopes to leverage patents to cement its Linux market leadership: Microsoft deal

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:

Share|

Apple may regret its choice of a permissive open source license for the Swift programming language

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:

Share|

Oracle effectively says Google jumped gun with Supreme Court petition in Android-Java copyright case

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:

Share|

Here's a redacted version of Microsoft's Android/Chrome patent license agreement with Samsung

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:

Share|

Q&A on the Dec. 4 Oracle v. Google Android-Java copyright hearing before the Federal Circuit

On Wednesday (December 4, 2013), the Washington, DC-based United States Court of Appeals for the Federal Circuit will hold the long-awaited Oracle v. Google appellate hearing. Two major (and overlapping) ecosystems -- the Java and Android communities -- and all other software developers (large and small, open source and closed source) need clarity on the question of whether Google's unlicensed use of many thousands of lines of declaring code of the Java APIs in its Android mobile operating system is or is not above board in a legal sense. The appellate hearing is an important juncture and could prove to be a turning point. I'll listen to the official recording, which will become available a few hours after the hearing, and share my observations. But no matter what the decision (which will come down a few months after the hearing) may ultimately be, the legal process won't end at that point, unless the parties settle.

With a view to next week's appellate hearing I thought I'd put together this Q&A document that I hope will help those following the case very closely (including those who will attend the appellate hearing) as well as those who haven't looked at this matter recently but would like to get a recap of the high-level issues and the procedural situation in this landmark dispute. At this point I won't go into detail on the case and the applicable case law, which I'll discuss instead in my post-hearing report.

You can click on any of the Q&A bullet points below to jump to a detailed version.

1. Q: What are the parties' business objectives in this dispute?
   A. Oracle once stated its intent to "bring Android back into the Java fold" by making Google comply with the Java rules the rest of the industry has accepted. Google seeks to defend the status quo: the use of Java material in Android without a license.

2. Q: Does this litigation involve Google's rights to use certain Java code under an open source license?
   A: No. Google could have incorporated Java into Android on open source terms, but chose to eschew the GNU General Public License (GPL) because of its "copyleft" feature.

3. Q: How do the parties' business models and intellectual property strategies with respect to software platforms compare?
   A: Google's approach to Android has amazing parallels to Oracle's approach to Java. The parties disagree only on how to deal with someone else's IP in a platform.

4. Q: What was the outcome in district court with respect to copyrights?
   A: Google was found to infringe dozens of Java APIs, eight test files, and the rangeCheck function. The jury was hung on fair use concerning the Java APIs, and the judge held that the copied API code was not protected by copyright anyway.

5. Q: Whatever happened to Oracle's patent assertions against Google?
   A: The district judge obligated Oracle to withdraw most of its patents. Two of the seven asserted patents were taken to trial and not found infringed. Oracle is not pursuing those claims on appeal. Theoretically, patent assertions by Oracle against the Android ecosystem are still possible.

6. Q: What is the scope of Google's cross-appeal and how relevant is it?
   A: Google seeks to overturn the district court ruling with respect to some small amounts of program code that don't matter to Oracle, which promised not to seek damages over them unless it also prevails on the "biggie" (declaring Java API code). Google's cross-appeal is purely tactical, not strategic.

7. Q: What are the broader implications of this case and the positions taken by amici curiae?
   A: Oracle is defending the copyrightability of the most creative category of program code while Google claims that non-copyrightability of such material is necessary to ensure interoperability. Many amicus curiae briefs have been filed, with Oracle having far more support from industry and support for Google having been drummed up by activists and Google-funded lobbyists for the most part.

8. Q: If Oracle prevails, what will be the remedies and when and how will they be determined?
   A: Oracle is seeking an injunction and damages (in that order). It has asked the Federal Circuit to enter judgment on liability, in which case the district court's job would be limited to the determination of remedies.

9. Q: If Oracle prevails, what will it demand from Google and what procedural and strategic options will Google have?
   A: Google will have to make Android Java-compatible and comply with the Java rules. Google can request a rehearing, file a petition for writ of certiorari with the Supreme Court, and if the case is remanded to the district court, Google will primarily try to avoid an injunction.

10. Q: If Oracle's appeal doesn't succeed, what options will it have?
    A: Just like Google, Oracle could request a rehearing and file a petition for writ of certiorari with the Supreme Court.

11. Q: Why has this copyright case been appealed to the Federal Circuit, not the Ninth Circuit, and what standard of appellate review will be applied to the key issues?
    A: Oracle's original complaint included patent infringement claims, and the parties agree that the Federal Circuit has appellate jurisdiction, but it will apply Ninth Circuit law. The district court ruling will be afforded little deference on matters of first impression.

12. Q: Who will argue for Oracle and Google?
    A: Google's lead counsel is Robert van Nest, who also represented it in district court. Joshua Rosenkranz, who focuses completely on appellate proceedings and has already defeated Google in the Federal Circuit on Apple's behalf, will present argument for Oracle.

1. Q: What are the parties' business objectives in this dispute?
A: Oracle once stated its intent to "bring Android back into the Java fold" by making Google comply with the Java rules the rest of the industry has accepted. Google seeks to defend the status quo: the use of Java material in Android without a license.

Between the district court judgment and the appellate hearing, the two companies' CEOs blamed each other for the unresolved situation. In May, Google CEO Larry Page said that a positive relationship wasn't possible because "money is more important to them than any kind of collaboration". Oracle didn't respond to that allegation, but in August, Oracle CEO Larry Ellison reminded Google of its "Don't Be Evil" meme and said that "what they did [using Java in Android without a license] was absolutely evil". Mr. Ellison also called out Mr. Page on his personal responsibility.

There are disputes in which the only question is how much one party owes the other. If Oracle v. Google was one of those disputes that are only about money, I guess there would have been a settlement a long time ago. But this is really about two platforms: Java, which Oracle acquired as part of its $7 billion acquisition of Sun Microsystems, and Android, which lets programmers write apps in Java that generally won't run on Oracle's original Java. In January 2012, Oracle told the district court that it wanted "to bring Android back into the Java fold" (i.e., ensure true compatibility between Android and Java) and end "Google's lawless conduct". That allegation was based on the fact that Google was actually negotiating a Java license with Sun (before it was acquired by Oracle) and decided to go ahead and ship Android without a license. An order by the district court quoted the following October 2005 email by Android founder Andy Rubin:

"If Sun doesn't want to work with us, we have two options: 1) Abandon our work and adopt MSFT CLR VM and C# language - or - 2) Do Java anyway and defend our decision, perhaps making enemies along the way"

Google elected the second option, and by now Oracle has lost most of its Java business opportunity on mobile devices as a result of that. Java-based mobile platforms such as Blackberry and Nokia's Series 60 phones were extremely popular. Today, Android owns more than 80% of the worldwide smartphone market.

There are no signs of Oracle intending to cause harm to Android. It just wants Google to be a good citizen of the Java community. But Google wants to make its own rules. It's not just about whether Google would be willing to pay royalties (which it's not prepared to). For Google it's also about unrestricted autonomy. It wants to do with Java (and to Java) whatever it pleases. This, to Oracle, is fragmentation, which already had Sun worried back in 2007, shortly after Android was launched. It's of greater concern to Oracle what Google does with and to Java than whether and what it pays for using it.

2. Q: Does this litigation involve Google's rights to use certain Java code under an open source license?
A: No. Google could have incorporated Java into Android on open source terms, but chose to eschew the GNU General Public License (GPL) because of its "copyleft" feature.

When Oracle filed this lawsuit in August 2010, it may have looked at first sight like a patent attack by a closed source software company on a piece of open source software. In its answer to the complaint, Google raised some open source issues that were presumably directed at the court of public opinion rather than the court of law. From the beginning Google has been playing the open source card, but it never had a formal defense based on its rights under the GNU General Public License (GPL), the free and open source software (FOSS) license under which Sun Microsystems published Java. In other words, Google put up an open source smokescreen and told an open source tale, but if you use software on open source terms and someone tries to prevent you from doing so, you raise a defense that says, "I am licensed under [whatever open source license] and I'm perfectly entitled to do what I'm doing!"

If Google had ever claimed in this litigation that Android's incorporation of Java was authorized under the GPL, this would have been inconsistent with its claim that it didn't use any copyrightable material (you can only license something, on whatever terms, if it's protected) and, far more importantly, a blatant violation of Rule 11 (truthful pleading standard) resulting in sanctions for Google and its counsel. The GPL affords you four freedoms: it allows you to use software without paying for it (freedom 0), to modify its source code as you please (freedom 1), to redistribute copies (freedom 2), and to distribute your modified versions to others (freedom 3). But once you exercise freedom 3, you're subjected to the copyleft rule: you must make your modified version available under the GPL. As a result, Google would have had to publish Android under the GPL. But it did not. Android builds on top of Linux, which is GPL'd, but Android itself is, according to Google, Apache-licensed. The Apache Software License 2.0 is a non-copyleft license and, therefore, absolutely incompatible with the GPL. You're lucky if you can run GPL and Apache software on top of each other (which can also raise complicated copyright and copyleft issues), but you certainly can't take GPL'd software, such as Linux, and release it under the Apache license.

As I'll discuss in more detail in the next section, Google seeks to exercise as much control over Android as possible. If Android had to be released under the GPL (and only under the GPL, or at least a compatible copyleft license), Google would have a hard time keeping a growing number of core Android components like its Mail and Map clients or even the new on-screen keyboard (again, more about that in the next section) closed -- and Google's hardware partners would have to release their proprietary enhancements such as Samsung's Touchwiz and HTC Sense under the GPL, which would run counter to their objective of differentiation because their competitors could then use the same code.

So there is no open source license-based defense. The closest thing to it that Google raised related to only a limited amount of code that it obtained under the Apache license. But that is also irrelevant. If I take software that I don't own and put it under an open source license without authorization, this still doesn't deprive the actual right holder of anything and, especially, doesn't allow third parties to use that software without a license from the actual right holder. Those third parties may, however, point to their reliance on what appeared to be an open source license in connection with the question of willfulness. Google never made that argument in connection with the program code that's really at issue (many thousands of lines of Java API declaring code): it obtained that one directly from Oracle's (Sun's) codebase, not indirectly through other parties or third-party open source projects.

3. Q: How do the parties' business models and intellectual property strategies with respect to software platforms compare?
A: Google's approach to Android has amazing parallels to Oracle's approach to Java. The parties disagree only on how to deal with someone else's IP in a platform.

It would be mistaken to believe that Google's Android business model is more permissive or more generous than Oracle's approach to Java. Let's face it: these two companies wouldn't be as wildly successful as they are if they acted like charities. Oracle acquired and has further invested in Java to make money with it; Google acquired and has further invested in Android to make money with it, too.

There are some differences, but there are also striking parallels. At the structural level (not getting into detail on how things are run), the Open Handset Alliance (OHA) is to Android what the Java Community Process (JCP) is to Java. Both Android and Java are available under open source licenses (Apache and GPL) as well as proprietary licenses. There are neat things that can be done and indeed have been done on an open source basis -- but both companies know that those seeking to make money with Android or Java will, not in all but in most cases, prefer a proprietary license.

Both companies also have in common that they fight fragmentation of their respective platforms.

The claim that Android is "free" and "open" is no longer taken seriously by anyone in this industry. If you're interested in a thorough, well-written debunking of that claim, I recommend this Ars Technica article entitled "Google's iron grip on Android: Controlling open source by any means necessary" (also, note what it says right below this headline: "Android is open--except for all the good parts"). Not even the current Android on-screen keyboard is open source...

If things had worked out differently between these two companies and they had developed Android together (or if they had co-developed Java, but it goes back to before Google was even founded), there wouldn't be a fundamental disagreement over what's desirable or undesirable with respect to a jointly-owned platform. However, Oracle has a tradition of respecting other companies' intellectual property rights (I can't remember any major IP infringement action against Oracle itself, obviously excluding what some acquisition target may have done prior to a takeover), while Google faces IP infringement allegations by major companies and organizations all the time. Google has double standards whether its own IP or that of others is concerned (see my contribution to The Hill's Congress blog, "Sue when you're winning"). Also, Google's Android is known to the Federal Circuit as a product violating various third-party rights.

In short, they don't disagree much on what each company wants to achieve with respect to its own platform, but they have a problem because of what Google wants to do with and to Oracle's platform.

4. Q: What was the outcome in district court with respect to copyrights?
A: Google was found to infringe dozens of Java APIs, eight test files, and the rangeCheck function. The jury was hung on fair use concerning the Java APIs, and the judge held that the copied API code was not protected by copyright anyway.

Oracle originally asserted seven patents (addressed in the next section) and certain copyrights. In last year's trial, the jury rendered a partial verdict and was overruled by District Judge Alsup in only one respect, resulting in an additional finding of infringement (relating to eight Java test files).

There's been some confusion since the partial jury verdict on what really came out of last year's trial. The most stupid misconception (that I still found in some articles published this year) is that Oracle "lost" on fair use -- in reality, fair use is still in the pipeline and could be determined by the appeals court or another jury, depending on the appellate opinion. These are the facts concerning the copyright-related outcome in district court:

• More than 7,000 lines of declaring code of 37 Java API packages

  This is the "biggie", and Oracle's exclusive focus on appeal. By comparison, the rest of the copyright part of this case was always unimportant (see also the section on Google's cross-appeal). Oracle presumably raised other infringement issues only to show to the court and the jury the scope and scale of Google's copying. In terms of what an Oracle win means or could mean, anything other than the declaring API code item is simply negligible (I'll address it in this section only for the sake of completeness).

  Google raised four categories of defenses: non-copyrightability; non-infringement; fair use; equitable defenses. I'll discuss the related holdings by the district court in separate bullet points:

  • Non-copyrightability defense

    The parties agreed that this was for the court, not the jury, to decide. It would have been the most systematic sequence of events for the district court to firstly resolve the copyrightability question because a holding of non-copyrightability (which indeed came down, but only after the jury trial) would have obviated the need for the jury to even look at the issues surrounding the declaring Java API code. The same ruling prior to trial would have narrowed the case substantially for the jury. But District Judge William Alsup apparently knew all along that this was going to be a difficult question, and one on which the appeals court might overrule him. And the jury was going to have to render a verdict on some other (smaller) items anyway. So Judge Alsup decided to let the jury render on infringement verdict anyway, just so there wouldn't have to be a new trial on infringement in the event of a reversal and remand by the appeals court. As an additional benefit, he also got to listen to all of the testimony and argument at the trial before ruling on copyrightability.

  • Non-infringement defense

    The jury found that Google had "infringed the overall structure, sequence and organization of copyrighted works" in terms of "the compilable code for the 37 Java API packages in question taken as a group". The judge instructed the jury to assume that this material is copyrightable (and not to think about whether it really is, which is not the job of a jury).

    This holding, however, relates to infringement in a narrow sense (copying) and isn't relevant unless (i) the district judge's holding of non-copyrightability is reversed and (ii) the question of "fair use" -- presently unresolved -- is resolved in Oracle's favor either by judicial decision or a verdict by a new jury complementing the first jury verdict.

  • "Fair use" defense

    Even infringement of copyrightable material doesn't matter if the copyist has a "fair use" defense. This is an equitable question of fact, requiring the decision-maker to weigh four different factors. Equitable decisions are up to a judge. Determinations of fact are made by a jury. The "fair use" question is generally amenable to judgment as a matter of law. But Judge Alsup declined to find that Google had a "fair use" defense and also declined to find that it had none. He deferred to the jury, which he instructed in a way that I thought was prejudicial to Oracle because, for example, it suggested that the hurdle for transformative use (one of the fair use factors) was rather low. The jury -- except for its foreman, who told the media afterwards that he wanted to throw out Google's fair use defense -- got confused and couldn't agree.

    A "hung jury" doesn't mean that anyone has prevailed. If found to infringe copyrightable material (and absent any other defense, such as estoppel), Google must prevail on "fair use". Conversely, Oracle must prevail on this question (as it must overcome all other defenses) in order to win the case. If a jury is hung, the matter must still be determined (unless it's irrelevant, which it would be if Oracle couldn't get the non-copyrightability holding reversed). Neither party is in a better position than the other in this regard. Nevertheless Google managed to mislead some uninformed reporters into believing that a hung jury was a victory for it -- though it should have given some people pause that the verdict form said, "Has Google proven that its use of [...] constituted 'fair use'?" (emphasis mine)

    One of the issues in this appeal is a procedural question related to "fair use". In the event that the appeals court reverses the copyrightability finding but doesn't resolve the "fair use" defense one way or another, the case would go back to the district court, which would then find the "fair use" question in the number one position of its to-do list. Oracle's position is that the appeals court should resolve fair use and enter a finding of liability, in which case the district court would only have to order remedies; but in the scenario I just described (copyrightability reversed, fair use left open) a second jury should look at "fair use", while Google would then like to be able to re-argue the question of infringement, claiming that a jury must look at infringement in order to be able to determine "fair use". Similarly (and unsuccessfully), Samsung had argued that the jury in the recent limited damages retrial should have redetermined infringement and patent validity issues rather than just award damages to Apple for a set of products it was told had been found to infringe valid patents.

  • Equitable defenses:

    Google's equitable defenses (estoppel etc.) were decided by the judge, but he did ask the jury render an advisory verdict on a couple of related questions. The jury verdict was mixed and, on the bottom line, negative for Google in this regard. While the jury found that "Sun and/or Oracle engaged in conduct Sun and/or Oracle knew or should have known would reasonably lead Google to believe that it would not need a license to use the structure, sequence, an organization of the copyrighted compilable code", it did not find that Google had proven that "it in fact reasonably relied on such conduct by Sun and/or Oracle in deciding to use the structure, sequence, and organization of the copyrighted compilable code without obtaining a license". A chain is as strong as its weakest link. Google would have had to convince the court on both of these questions (and some more that the jury was not asked), not just on one of them. In the post-trial judgment, Judge Alsup threw out Google's equitable defenses. We can simply forget about Google's equitable defenses for the further process. Google didn't even raise these on appeal. The testimony by former Sun CEO Jonathan Schwartz (the CEO under whose tenure Sun nearly went out of business and ultimately lost its independence) served to confuse the jury on "fair use", but fell short of what Google would have needed to succeed on an equitable defense. The relevance of that testimony was, by the way, grossly overestimated by some reporters.

• Documentation of 37 Java API packages

  The jury identified no infringement (and consequently didn't have to look into "fair use" on this particular item). The judge didn't overrule the jury, and Oracle isn't pursuing this item on appeal.

• Three other items with respect to which the only defense was "de minimis"

  The jury was also asked to determine whether three items that Google had conceded to use in Android were "de minimis", i.e., too small to be of legal relevance. The jury found that the nine-line rangeCheck method in the TimSort.java and ComparableTimSort.java source files was not too small to matter, but found in favor of Google's "de minimis" defense wih respect to the "source code in seven 'Impl.java' files and the one 'ACL' file" (i.e., eight Java test files) and the "English-language comments in CodeSourceTest.java and CollectionCertStoreParametersTests.java". The court upheld the jury's related findings except that the eight decompiled Java test files (undoubtedly much larger than the rangeCheck function, which shows just how confused and inconsistent that jury was) were found to be more than "de minimis". Six of those eight files had been shown by this blog before they were even referenced in any (publicly-accessible) court filing.

  In a commercial and strategic sense, these files don't really matter, as I explained further above. Google nevertheless brought a cross-appeal in order to have those findings reversed. I'll address that one in a separate section.

5. Whatever happened to Oracle's patent assertions against Google?
A: The district judge obligated Oracle to withdraw most of its patents. Two of the seven asserted patents were taken to trial and not found infringed. Oracle is not pursuing those claims on appeal. Theoretically, patent assertions by Oracle against the Android ecosystem are still possible.

Oracle originally asserted seven patents against Google, and at the early stages of this litigation it looked like more of a patent than copyright case simply because each patent was one "count" of the complaint, while copyright as a whole was only one more count. But item counting is never the proper methodology for establishing the relevance of issues in a case.

Oracle's patents-in-suit came under reexamination pressure. I must admit that I've lost track of those reexamination proceedings, but first Office actions are of rather limited relevance and even "final" Office actions tentatively "rejecting" a patent aren't truly final (as the examples of certain Apple patents such as the '381 rubber-banding patent -- key claims ultimately confirmed -- and the "Steve Jobs patent" -- all claims ultimately confirmed -- show). But Judge Alsup leveraged the state of affairs in those reexamination proceedings against Oracle, urging it to narrow its case for the jury lest the case would be stayed pending reexamination (i.e., for years).

In January 2012, Oracle proposed that the patent part of the case be severed and stayed in favor of a near-term copyright trial. This was the first public filing by Oracle in this entire litigation that demonstrated an unequivocal focus on copyright infringement issues.

Judge Alsup didn't adopt this proposal because he didn't want to have more than one Oracle v. Google trial. Oracle then had to withdraw most of its patents -- even with prejudice, which, by comparison, another (patentee-friendlier) federal judge in the same district, Judge Lucy Koh, did not require Apple and Samsung to do (they only had to withdraw patents without prejudice, allowing them to reassert them later). Ultimately, two patents were shown to the jury, which didn't find them infringed, though Google's own source code comments and file names clearly weighed against a finding of non-infringement with respect to one of them. The judge didn't overrule the jury, and Oracle is not pursuing those patents on appeal (one of them has expired and the other one was of relatively low commercial value).

Oracle's withdrawal with prejudice of five patents and abandonment of two other patents on appeal relates to Google, not to other parties, and even with respect to Google only to the patents-in-suit. Should any of those patents be confirmed at the end of reexamination (including appeals), Oracle would not be able to sue Google over them, but it could (and I have no idea whether it would want to do that) still sue Android device makers (even before the end of reexamination). It could also sue Google over other patents. I'm not going to speculate on the likelihood. I just wanted to point out that Oracle's preclusion with respect to patent assertions against Android isn't unlimited.

6. Q: What is the scope of Google's cross-appeal and how relevant is it?
A: Google seeks to overturn the district court ruling with respect to some small amounts of program code that don't matter to Oracle, which promised not to seek damages over them unless it also prevails on the "biggie" (declaring Java API code). Google's cross-appeal is purely tactical, not strategic.

Google's appeal relates to minor items -- so minor that Oracle told the court last year it wasn't going to demand even one cent of damages for them unless it also prevails on the thousands of lines of declaring Java API code used by Google in Android. If both parties succeeded with their appeals, Oracle would be happy and Google wouldn't have any benefit from its cross-appeal. Google probably thought that a cross-appeal was an opportunity to get more time and space for its anti-copyright arguments, and would delay the process (at least at the briefing stage). There's a certain logic in this because the district court ruling is, unless one totally buys Google's "interoperability" argument, inconsistent in the sense that a nine-line function (rangeCheck) was deemed protected by copyright (as were eight Java test files) while more than 7,000 lines of declaring Java API code were not. But Google now has to take a radically anti-IP position -- arguing that everything at issue in this case at this stage is for the taking -- before an IP-friendly appeals court.

7. Q: What are the broader implications of this case and the positions taken by amici curiae?
A: Oracle is defending the copyrightability of the most creative category of program code while Google claims that non-copyrightability of such material is necessary to ensure interoperability. Many amicus curiae briefs have been filed, with Oracle having far more support from industry and support for Google having been drummed up by activists and Google-funded lobbyists for the most part.

Even though the parties' positions couldn't be further apart, they do agree that the stakes are high.

Oracle and its supporters warn that affirmance of Judge Alsup's holding of non-copyrightability would, as a former U.S. copyright chief wrote in his submission to the appeals court, "largely eviscerate[] copyright protection for some of the most creative aspects of computer software" and chill innovation. But Google and its allies also raise a huge issue: interoperability. They say that program code relevant to compatibility between programs must always be unprotected.

I've had a consistently pro-copyright position on these types of issues for many years. The first time I publicly disagreed with the Electronic Frontier Foundation (EFF), a Google-funded advocacy group, on copyright in an alleged "interoperability" context was in April 2004 at a conference in the European Parliament. (There are some issues in the patent reform context on which I agree with the EFF, by the way.)

In case of doubt, I for my part come down on the side of the authors. And in this case I don't even have doubt, frankly. I don't think Google's proposal of non-copyrightability is appropriate from a policy point of view, I don't consider it supported by case law, and in any event, I don't think Google can even rely on an interoperability argument given that Android fragments Java and that Android apps don't run on Oracle's Java platform, which Google's own witnesses confirmed in this case. In May an Oracle spokeswoman issued the following comment on certain pro-Google submissions to the appeals court: "I guess everyone is having collective amnesia about the uncontroverted testimony that Android is not compatible with Java."

The common-sense approach to restrictions of someone's rights (here, copyright protection for creatives) in order to protect someone else's rights (here, the right of developers to write software that is compatible with someone else's software) is to impose only such restrictions that are truly necessary to achieve the desired effect, and proportionate. Anything else would be overreaching and do unnecessary damage, tantamount to throwing out the baby with the bath water.

If you want to safeguard interoperability, U.S. copyright law (unlike patent law, by the way) has a tool at your disposal: fair use. Interoperability-related program code can be copyrighted, but certain forms of use (for example, development of an application for an operating system, using the APIs of the OS) would certainly be fair and, therefore, legal.

Not only is the "fair use" stage the right choice because it's a more proportionate approach than the wholesale denial of copyrightability but it's also the more logical one. Google argues in this case that the Android developers were restricted in their creativity when creating the Android APIs because they wanted to keep them (only selectively, anyway) consistent with the Java APIs. But the proper point in time at which to determine whether someone authored something sufficiently creative to warrant copyright protection is the moment when the related code was authored, not something that happens years, possibly many years, after the fact in some other place. I honestly considered it absurd for Google to argue that those APIs may have lost their copyright protection just like Aspirin lost trademark protection over time.

The choice of Java's developers wasn't restricted too much (if at all) when they wrote Java; and even Google's developers would have been free to develop their own APIs or license someone else's.

If a court looks at interoperability at the "fair use" stage, it can look at exactly what someone does with and to an earlier creator's code. Some use (such as my example of someone writing an app for Android) will be deemed fair; some other use may be unfair. Google, however, wants to have the whole question (of interoperability vs. intellectual property) resolved in its favor by nipping intellectual property in the bud, at the copyrightability stage. It presumably knows that it has a very weak "fair use" case considering the damage Android has done to Java.

In light of these positions and implications, it comes as no surprise that the leaders of the technology industry stand united behind Oracle. To the extent that Google has any support from other tech companies and industry groups, those are always Google-aligned (including Google-funded lobbyists) and known for an anti-IP stance.

I quoted from former U.S. copyright chief Ralph Oman's amicus brief. Google doesn't have any support from a former high-level IP official.

Both parties have support from professors. Google has a larger number of professors in its camp, but it obviously focused on academics since it couldn't get much support from industry players. Many of the law professors supporting Google on this copyright case also signed a letter to Congress advocating far-reaching patent reforms (which Google also promotes).

8. Q: If Oracle prevails, what will be the remedies and when and how will they be determined?
A: Oracle is seeking an injunction and damages (in that order). It has asked the Federal Circuit to enter judgment on liability, in which case the district court's job would be limited to the determination of remedies.

If the Federal Circuit agreed with Oracle to the full extent, it would enter a judgment on liability by reversing the district court's holding of non-copyrightability and by holding that Oracle was and is entitled to judgment as a matter of law (i.e., no need for another jury) on "fair use". The case would then be remanded to the district court for a decision on remedies. It would also be remanded if Oracle prevailed on copyrightability but not on fair use. In that case, the district court would have to hold a retrial on fair use (which Google argues would have to involve a new infringement determination), and depending on its outcome, there would be remedies.

Oracle is primarily interested in an injunction. Damages could also be significant, but compared to an injunction they wouldn't be overly important even in a best-case scenario for Oracle. Only an injunction will enable Oracle to "bring Android back into the Java fold", which is its stated goal.

The equitable decision on injunctive relief would be made by the district court. It could be appealed.

Both parties requested a jury trial, so damages will have to be determined by a jury. The big item would then be the Java APIs. Additionally, Oracle would also point the jury to any other (smaller) infringements identified (which findings Google is trying to get reversed on appeal), not because this would make a huge commercial difference but because a plurality of infringements is more likely to convince a jury that substantial damages are warranted.

9. Q: If Oracle prevails, what will it demand from Google and what procedural and strategic options will Google have?
A: Google will have to make Android Java-compatible and comply with the Java rules. Google can request a rehearing, file a petition for writ of certiorari with the Supreme Court, and if the case is remanded to the district court, Google will primarily try to avoid an injunction.

Assuming that the Federal Circuit sides with Oracle (at least on copyrightability, and possibly on "fair use" as well), Google will have to think hard about whether to settle or to continue to fight. In a situation in which Oracle has leverage, I believe a settlement would be about far more than just money: Google would have to bring Android into compliance with the Java standard within the foreseeable future.

Even with a Federal Circuit opinion in Oracle's favor, Google's procedural options would not be exhausted yet. Google could petition for a panel rehearing and possibly a rehearing en banc (full-court review). It could try to appeal the Federal Circuit decision to the Supreme Court by filing a petition for writ of certiorari. And if it can't prevent a remand on terms favorable to Oracle, Google can still continue the fight in district court. Fair use may remain to be resolved. Even with fair use resolved in Oracle's favor, Google can try to avoid an injunction (though the harm that Android has caused and continues to cause to Java is so obvious that I believe an injunction would normally issue) and to dissuade a jury from awarding a substantial amount of damages. The parties' focus in the remand proceedings would definitely be on the question of injunctive -- not monetary -- relief.

10. Q: If Oracle's appeal doesn't succeed, what options will it have?
A: Just like Google, Oracle could request a rehearing and file a petition for writ of certiorari with the Supreme Court.

Even with a Federal Circuit opinion in Google's favor, Oracle's procedural options would not be exhausted yet. Oracle could petition for a panel rehearing and possibly a rehearing en banc (full-court review). It could try to appeal the Federal Circuit decision to the Supreme Court by filing a petition for writ of certiorari.

As I mentioned in the section on patents, Oracle would not be precluded from asserting Java patents against Android device makers. I don't have an opinion on whether that is likely to happen. Procedural options are options regardless of probability.

11. Q: Why has this copyright case been appealed to the Federal Circuit, not the Ninth Circuit, and what standard of appellate review will be applied to the key issues?
Oracle's original complaint included patent infringement claims, and the parties agree that the Federal Circuit has appellate jurisdiction, but it will apply Ninth Circuit law. The district court ruling will be afforded little deference on matters of first impression.

Appellate jurisdiction is sometimes disputed between parties. For example, Google is trying to move Apple's appeal of a FRAND determination action out of the Federal Circuit to the Seventh Circuit, while arguing that the Federal Circuit has jurisdiction over its appeal of a Microsoft FRAND case despite previously having appealed a decision in that litigation to the Ninth Circuit. But there is no disagreement on the choice of appellate forum in this Oracle v. Google case.

Under the special circumstances of this case, the Federal Circuit will apply Ninth Circuit law. But the Federal Circuit also has its own body of case law on copyright, and some fundamental issues have been decided by the Supreme Court.

The district judge basically described his copyrightability decision as one that involves matters of first impression, which means that the appeals court will probably afford the lower court limited deference in this context. In my opinion, the district court ruling on copyrightability was simply a departure from established copyrightability principles.

12. Q: Who will argue for Oracle and Google?
A: Google's lead counsel is Robert van Nest, who also represented it in district court. Joshua Rosenkranz, who focuses completely on appellate proceedings and has already defeated Google in the Federal Circuit on Apple's behalf, will present argument for Oracle.

The Wednesday hearing will be a clash of titans not only with respect to the parties but also their attorneys. Both are proven winners with an amazing track record. Oracle's counsel has the home team advantage.

Keker & van Nest's Robert van Nest is a trial lawyer with a long history of landmark successes. His stellar performance on Google's behalf in last year's Android-Java trial has received a lot of recognition, and the file cabinet he brought along to show to the jury is now part of California legal history. That said, he was probably lucky with a jury that, except for the foreman, didn't figure out the issues and had to be overruled by the judge on one item (eight Java test files) because it made a decision that no reasonable jury (that's the legal standard) could possibly have reached.

Orrick Herringon Sutcliffe's Joshua Rosenkranz frequently appears before the Federal Circuit and other appeals courts. Dubbed the "Defibrillator" for his ability to revive cases that appeared to be practically lost after a district court ruling, he has already brought Apple's ITC complaint against Google (its Motorola subsidiary, to be precise) back to life, and based on how a recent hearing went, he's also on the winning track in the "Posner appeal" (same parties), which will likely give Apple the opportunity to assert the famous "Steve Jobs patent" against Google's Motorola in the Northern District of Illinois. Mr. Rosenkranz and his team authored a fascinating opening brief that likened Google's unlicensed use of Java in Android to a fictitious author's (named "Ann Droid") plagiarism of Harry Potter.

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:

Share|