Friday, September 17, 2021
OpenRAN is certain to increase standard-essential patent licensing costs: more SEPs, more SEP holders, more implementers, more injunctions
The stated goal of the O-RAN Alliance (O-RAN = OpenRAN = Open Radio Access Network) is to "enable a more competitive and vibrant RAN supplier ecosystem with faster innovation" by virtue of modularizing mobile network infrastructure through standardized interfaces. If OpenRAN (or "O-RAN") is clearly superior over the current architecture, it's striking that even the most optimistic projections come down to approximately 10% of the global RAN market by 2025.
There are hurdles to be taken and concerns to be addressed. In this post I can't talk about them all. To give just one example of a serious technical question, it is debatable whether a mobile network that runs partially on the cloud ("vRAN" or "virtual RAN") could ever match the reliability and performance of traditional equipment, and whether the optimized use of resources that cloud-based solutions potentially offer outweigh security and other risks. I may very well discuss some of those architectual and practical issues on other occasions.
Today I'm going to focus on what is--for this blog--the obvious starting point of the analysis: standard-essential patent (SEP) licensing and litigation. From that angle, O-RAN has zero upside--literally zero--but comes with a significant downside:
1. Not a single cent will be saved in 5G license fees
O-RAN relates to the infrastructure side. Communication between the network infrastructure and end user devices (such as handsets and connected cars) still relies on the same standards--presently, that means 5G first and foremost.
O-RAN doesn't make 5G cheaper. It has no impact on handsets, and the only way that carriers would pay lower 5G royalties would be if O-RAN delayed the rollout of 5G, which no one wants to happen.
2. Additional patents--partly from additional patentees--will have to be licensed, and they will not be free
Not only will there be more patents to be licensed but definitely more patents and--very likely--more holders of relevant patents.
On top of the standards that those mobile networks already have to implement, their infrastructure will have to implement the O-RAN interfaces. While the "Open" part of the standard's name does stand for a connection with open-source software, participants in the standard-setting process (such as ETSI members) will be entitled to FRAND royalties (and not FRAND-0, to be clear). Some relevant patents may end up belonging to companies that are not bound by a FRAND pledge. I don't even want to get into a doomsday scenario of different major markets in the world potentially going in different directions, which may result in a huge number of patents that are essential to a standard in one region but belong to patent holders who did not participate in the relevant standard-development process.
3. More implementers will have to take licenses
At the moment, the number of relevant implementers in the mobile infrastructure market is small: a few base station makers, and their suppliers, such as chipmakers. That number will go up with O-RAN, as the whole idea is to bring in more players (most of them U.S. based, as this is primarily an initiative by the U.S. government and U.S. carriers, with Apple apparently looking at O-RAN as an opportunity for infrastructure-side services that lock customers even more into the iOS ecosystem).
The more licensees there are, the more costly the licensing process becomes, which in the end increases costs.
4. Virtualization and modularization exacerbate the forum-shopping problem
Should parts of the functionality be moved to the cloud, the holders of certain types of patents may be able to choose between enforcing them where the servers are hosted or in the jurisdiction in which those cloud services are used by a carrier.
Even without virtualization, some forum-opportunities will likely result from the fact that different components are made in different jurisdictions, and that some patents may be infringed directly only by the carrier, but particular component makers may be liable for contributory infringement.
5. The availability of drop-in replacements weighs in favor of granting patent injunctions
Just like "plug & play" (relating to personal computer hardware) was derided as "plug & pray," it's doubtful that carriers will be comfortable replacing a patent-infringing O-RAN component with a rival offering. In some cases, carriers will have had reasons for choosing one particular component over the other options.
But patentees who prevail in infringement litigation will be able to leverage the O-RAN marketing promise against defendants. They'll argue that an injunction does not cause irreparable harm (and won't impact third parties) as a component held to infringe the patent(s)-in-suit could be replaced with another.
6. Today's leading infrastructure makers may step up patent monetization
Should O-RAN adversely impact mobile infrastructure sales by today's market leaders, they may further step up their patent enforcement.
I'm not saying that one should oppose O-RAN just over the foreseeable patent licensing and enforcement issues outlined herein. Patent licensing is sometimes just a cost of doing business. But when weighing off the pros and cons, the licensing and litigation aspects are undoubtedly in the "con" column.
Share with other professionals via LinkedIn:
Friday, April 3, 2020
Today is the 10th anniversary of the launch of FOSS Patents--and here's a Microsoft patent threat from 2004 no one reported before
Ten years ago to the day, the first FOSS Patents blog post went live. (In the table of contents on the right side you can also find an entry for January 2010, but that one was added subsequently--and backdated so the contact form would be listed behind all of the actual content.)
When I talk to readers at courthouses or on other occasions, I realize most people don't even know what the "FOSS" stands for. That means Free and Open Source Software, a "politically and philosophically correct" term that describes both persuasions of the same movement. At the outset, the idea was indeed to focus on patent threats and assertions against open-source programs such as Linux. I always viewed the Open Invention Network (OIN) very skeptically as it appeared to part of the problem to a several times greater extent than it was part of the solution. And I was aware of some threats no one had reported on at the time. In fact, there is one that I hadn't written about in the more than 16 years since it was made, but with so much water under the bridge by now--and with Microsoft being a member in good standing of the open-source community these days--I'm going to reveal it on this occasion:
In early 2004, Microsoft's patent licensing department contacted MySQL AB, the originally Finnish-Swedish and, at that time, heavily Americanized open-sourced database company (whose CEO I was advising at the time). What Linux was in comparison to Windows, MySQL was to Oracle, Microsoft SQL Server, and IBM Db2. The term isn't used much anymore, but back then the "LAMP Stack" meant Linux, the Apache webserver, the MySQL database, and one of the P languages (mostly PHP, with a few people using Perl, or even Python): an open-source technology stack powering more websites than any other comparable configuration. MySQL had risen to popularity alongside Linux. It was a symbiotic relationship. Microsoft, of course, favored Windows + Internet Information Server + SQL Server + Visual Studio (C# or Visual Basic).
What Microsoft--and again, the Microsoft of then is not the Microsoft of now when it comes to these types of issues--told MySQL (a company that had received tens of millions of dollars of venture funding while Microsoft already had roughly 10,000 times greater resources) was that they claimed to hold a patent that covered functionality at the very core of the MySQL database engine. From a software development perspective, a database engine is a relatively monolithic (as opposed to modular) thing. If someone asserted a patent against the basic architecture of your engine, it could mean that you have to almost start all over. You'd lose years.
Microsoft was clear about its demand: a 2% royalty on MySQL's (tiny) sales. Two things were not clear, however: whether Microsoft had an agenda to actually start a patent war against open source and, particularly, the LAMP Stack, so that an initial royalty agreement would not have been an amicable resolution of an IP issue but could have been the beginning of the end for MySQL and LAMP; and Microsoft declined to disclose that mysterious killer patent.
The concern I just outlined--that Microsoft would wage an all-out patent war against open source--was not merely paranoia. A Microsoft exec in charge of corporate strategy at the time had told some Silicon Valley venture investors a year or two before that "if it comes to worst with open source, [they'd] just use some of [their] patents." So what was presented as a shakedown might have been a concealed attempt at a shutdown.
Microsoft was the only company at the time to have an issue with Linux; the rest of the industry viewed Linux as a chance of liberation from Microsoft dominance. When it came to MySQL, however, two other major patent holders--IBM and Oracle--potentially had just the same strategic motivation to attack the successful startup, as those companies were pro-Linux, but faced a disruptive-innovation threat from MySQL. While that would have been a gigantic violation of antitrust law, one of MySQL's founders even feared that Microsoft, IBM and Oracle might have agreed to launch near-simultaneous patent attacks on them. And they had only a very few patents (from a smaller startup they had acquired)--likely of zero retaliatory value.
MySQL didn't accede to Microsoft's demand, and Microsoft never stepped up the pressure or sued. Part of the reason may very well have been (and in my view, most likely has been) that there were two things going on in the EU that Microsoft had to be cautious about. The European Commission going after Microsoft for its conduct in some other conduct; and the EU's legislative bodies (Council and Parliament) were working on a Directive for the Patentability of Computer-Implemented Inventions, i.e., software patents directive. Concerns by the open-source community played an important role in the political debate.
At some point MySQL was seriously considering making Microsoft's patent royalty demand public. We had already prepared a press release, and it was going to be centered around an open letter to EU policy-makers urging them to abolish software patents in Europe (though that wouldn't have solved the problem for MySQL anywhere else, and it actually generated most of its revenues in the U.S. anyway). We didn't escalate the conflict, and ultimately that was better for everyone involved.
Oddly, about five years later Microsoft actually tried to defend MySQL's independence. Oracle was in the process of acquiring Sun Microsystems, which had acquired MySQL the previous year for 1ドル billion. While Sun wanted MySQL's business to grow, there were reasons to assume Oracle simply wanted to control it so as to eliminate a competitive threat. Microsoft and SAP (even though mostly concerned about Java in the beginning) were the two large complainants, and MySQL's founder, Michael "Monty" Widenius, was the third complainant, with help from me. So MySQL's founder and I ended up in an alliance with Redmond about five years after we had thought Microsoft would potentially use patents to destroy it.
If not for that old Microsoft patent threat against MySQL--16 years under wraps--, I might never have gotten involved with patent policy in the first place. And I had it very much in mind when I launched FOSS Patents. At that time, I already knew that Microsoft wasn't necessarily a foe (as the Oracle-Sun merger review showed). In fact, I felt that some FOSS people, maybe because they received funding from the likes of IBM and Oracle, weren't being fair: they turned a blind eye to some other large tech companies' (especially their financial backers') questionable patent dealings and pro-software-patent lobbying, but even when Microsoft had good intentions in specific areas, they looked at whatever Microsoft did or announced like Sherlock Holmes with a magnifier glass and, if all else failed, simply made up concerns that weren't warranted. Part of the FOSS Patents agenda was to focus more on companies whose patent abuse got less attention, but "deserved" more. The first big story here was the second post ever: on an IBM threat against an open-source mainframe emulator.
This blog's focus evolved dynamically. In fact, just about four weeks before I launched FOSS Patents, Apple had filed its first patent infringement complaint against an Android device maker (HTC). Android became the most heavily-attacked piece of open-source software that year as Oracle sued Google (a case that later became only a copyright dispute as Oracle's patents failed in court), Microsoft sued Motorola, Motorola sued Apple (which countersued using largely the same patents as against HTC), and the following year Apple sued Samsung.
Of the roughly 2,300 FOSS Patents posts I've written to date (also, there were a few guests posts), roughly 63% (1,456 posts) went live in the years 2011-2013, the three years in which the "smartphone patent wars" were raging on a very large scale. By 2014 they had already subsided, and in 2014 various disputes came to a partial or complete end.
With those Android companies countersuing, my litigation reporting simply had a mobile focus (and occasionally even gaming consoles). If I had anticipated that, I'd have named the blog "Mobile Patents" or "Phone Patents."
Actually, "FRAND Patents" would have made even more sense. I already took a clear position against injunctions over standard-essential patents in 2010. And a few years later, a Research In Motion/BlackBerry lawyer accused me, after a Mannheim trial, of having "devalued" SEPs and that companies were cutting back on their standardization activities (obviously not true, as we all know now with the benefit of 2020 hindsight).
More recently, this blog has almost been an "automotive" blog, only because car makers are currently the ones that SEP holders like Nokia primarily seek to prey on.
So there's probably no point in ever renaming a blog, much less when it is as well-known as this one. I'm very grateful for having so many loyal readers, and a number of highly important people in the industry as well as in the judiciary, executive and (to a lesser degree) legislative branches of government. I really am.
There's one thing I had envisioned for the 10th anniversary that I haven't found the time for: a redesign. This blog still uses the "Blogspot" platform's original blog layout. Blogspot became Google's "Blogger" service, and undoubtedly supports more fashionable layouts. However, since I have manually entered and edited all the HTML tags here from the outset, it's a bit risky to switch to a newer layout (I ran a test and the result looked awkward)--I or someone I'd pay for it might have to go over 2,000+ posts and make countless manual adjustments. Nevertheless, it may happen later this year--certainly sometime before the potential 20th anniversary :-)
There were times when I was seriously considering discontinuing this blog, or handing it to some other organization, such as an IP-focused publishing company. But in recent years there have been some really exciting developments--and I've found a way to keep blogging while continuing to run an app development company (I'll have a new game to announce this summer).
Some of you encouraged me to keep going--even some who have rather different positions on SEPs or on patent policy in general. Thanks for that, too. I'll keep sharing my honest observations and opinions with all of you for quite some more time!
Share with other professionals via LinkedIn:
Saturday, November 3, 2018
Wall Street sees 20%-25% regulatory risk for IBM's envisioned acquisition of Red Hat
Last Sunday, IBM and Red Hat announced a merger agreement under which "Big Blue" (NYSE:IBM) would pay 34ドル billion, or 190ドル per NYSE:RHT share, to acquire the company that once started as a Linux distributor.
I may very well talk about the strategic ramifications of the proposed transaction some other time, but the focus of this post is exclusively on what the stock market appears to think of the deal.
On Monday (October 29), Bloomberg already reported on what was then a 12% spread, "among the highest for North American deals." The article quoted a portfolio manager who said he didn't want to bet on a deal that may be about a year away from closing, and IBM CEO Ginni Rometty as denying "any regulatory inhibitors," which she obviously had to say.
The time frame certainly affects demand, given that risk arbitrageurs could in the meantime use the money they would spend on RHT shares now to bet on a couple of other mergers, provided that those other deals would close more quickly and happen sequentially. But there's more to it. The spread does indicate that merger-focused investors are far from convinced that the deal will materialize.
On Friday (November 2), RHT closed at 172ドル.24. If the deal went through, those investing now would then rake in a profit of more than 10%. Even if it took a year, a 10%+ gain would be a great deal. The only explanation for why there isn't stronger demand, at a higher price, is skepticism. Since I can't imagine anyone doubts that IBM is a serious buyer, the reason must be concern about the merger review process in the U.S. (DoJ), EU (European Commission, DG COMP), and China (MOFCOM). While China prevented Qualcomm from acquiring NXP, IBM reportedly claims it's not critical for the Red Hat deal. I haven't formed a definitive opinion on it yet, but for now I'll take IBM's word for it.
Without going into detail (yet) on the issues presented by the transaction, we can "reverse-engineer" the stock price in order to get an idea of how likely the deal is--in the eyes of sophisticated Wall Street investors--to go through or fall through. Let's start with the roughest and simplest approach, and then fine-tune it a little bit to take the time value of money into account.
The potential upside based on Friday's closing price is 17ドル.76. Theoretically it's even greater since someone else might try to outbid IBM, but that doesn't appear to be considered too likely by anyone.
The potential downside here would not realistically be a complete loss of the investment. Red Hat is doing too well to go out of business anytime soon. The closing price over which IBM offered a premium of about 60% was 116ドル.68, pretty much at a level with RHT's 52-week low of 115ドル.31 (an intraday price as far as I can see).
If the deal falls through, it's a reasonable assumption that Red Hat's stock price will go back to that level, though it's obviously hard to predict what the market environment would be at that point in time somewhere in the second half of 2019. In order to keep things simple, let's not consider that investors might think they could mitigate their loss by getting out once there's a serious negative sign, such as a powerful Statement of Objections (SO) by the European Commission.
Assuming that the pre-merger-announcement closing price is where the price would fall, the potential per-share loss is 55ドル.56 (172ドル.24 - 116ドル.68).
If the likelihood of closing is estimated to be 76%, and the risk of things falling apart is (consequently) 24%, then there would be an equilibrium (76% x 17ドル.76 is at a level with 24% x 55ドル.56).
Let's fine-tune this by assuming a financing cost of 4ドル.00 per share (roughly the Fed rate, assuming that you have this cost for 12 months). In that case, the potential gain (by placing the right bet on the deal going through vs. doing a far safer investment that would have a 2.5% yield) is 13ドル.76, and the potential loss increases to 59ドル.56. There would then be an equilibrium if the risk of the deal being blocked (or remedies being imposed with the effect of the deal falling through) was estimated at 19% (19% x 59ドル.56 is at a level with 81% x 13ドル.76).
Even in the aftermath of Qualcomm-NXP, that is a fairly skeptical perspective, given that mergers of this kind normally go through.
I've received a couple of independent invitations to meet portfolio managers in New York to discuss the deal, plus various calls and emails. Investors used to follow my coverage of the Google-Motorola process with great interest, and many still remember my vocal opposition to Oracle's acquisition of Sun Microsystems in late 2009 and early 2010. It was funny for me how the numerous Wall Street people I talked to always called the company "JAVA" (based on the stock ticker symbol). Java--the programming language--wasn't an issue at the time; MySQL, the open-source database, was the reason for which the European Commission conducted a Phase II review and issued an SO. It's about open source again, and this time around, Java will be part of the discussion.
As a matter of transparency, Red Hat contributed to my NoSoftwarePatents campaign in late 2004 and early 2005 (two other companies, including one far smaller than Red Hat, were much bigger supporters of the campaign), but there hasn't been any business relationship with Red Hat since. I've never had any relationship with IBM, other than having the greatest respect for the work of its patent department.
Share with other professionals via LinkedIn:
Thursday, April 5, 2018
Microsoft's Shared Innovation Initiative and its evolving approach to intellectual property rights
Microsoft has announced a "new IP strategy for a new era of shared innovation," giving customers ownership of new patents and design rights resulting from their collaboration with Microsoft, with Microsoft merely getting a license to use those technologies for the improvements of certain "platform technologies" such as Azure, Office, and Windows. Microsoft is even willing to support contributions to open source projects at a customer's request.
I haven't done any consulting for Microsoft in more than four years, and even while I was doing some work for them (such as on standard-essential patents), I never received any confidential information about their strategies or the terms of their license agreements. Whatever I know, I know from publicly-accessible court filings, one of which indicated that Samsung at some point paid north of 1ドル billion in Android patent royalties to Microsoft during a 12-month period.
As an anti-software-patent campaigner (2004/2005), I was profoundly worried about Microsoft using its patents against Linux and other free and open source (FOSS) software. A few years later, I realized three things:
In certain contexts (such as the i4i case), Microsoft actually took pro-defendant positions.
While I understand that many people disliked the idea of Microsoft charging patent license fees to Android device makers, there was no exclusionary use of patents. To the extent Microsoft sought injunctive relief, it merely wanted to bring Android OEMs to the negotiating table in order to reach a license agreement. Depending on the specific terms, licensing can also be anticompetitive, but by now we all know that none of this prevented Android from succeeding, and dozens of companies (many of which would have the resources and sophistication to defend themselves in court) chose licensing over litigation.
I considered many free and open source software activists hypocritical because they criticized Microsoft over almost anything it did in connection with open source while giving the rest of the industry a free pass and intentionally turning a blind eye to some other players' clearly abusive conduct. Just like other companies orchestrated antitrust complaints against Microsoft, Microsoft was in some cases proven and in other cases merely suspected to be behind initiatives targeting other large players. But if there were things that deserved to be criticized, who cares? In the information and communications technology sector, lobbying entities and NGOs that raise issues serve an important hygienic function, provided there really is fire and not just smoke.
During the "Smartphone Patent Wars" it happened for the first time that Microsoft faced the threat of injunctive relief as a result of litigation brought by another large corporation: Motorola Mobility. That kind of adversary, which at some point belonged to Google, wasn't just the kind of troll that you can pay to go away (and that usually won't satisfy the eBay standard for patent injunctions). "Googlorola" wanted to gain so much leverage over Microsoft that it would have been forced to cease and desist from all litigation against Android device makers. Even during the early stages of its dispute with Motorola, Microsoft still made an often-cited filing with the Federal Trade Commission in which it advocated, or at an absolute minimum appeared to advocate, injunctions over standard-essential patents (SEPs). But that changed not much later, and by now most major players, except for mostly failed businesses that increasingly rely on patent monetization, agree that SEP injunctions shouldn't be granted. Two years ago, Google joined the Fair Standards Alliance, which promotes SEP licensing on FRAND terms.
I had already done some work for Microsoft when I first took a clear "no SEP injunctions" position on this blog. I knew that Microsoft's standards group wasn't taking the same position at the time, but no one even tried to discourage me from voicing my position on this.
In recent years, Microsoft's IP-related positions and priorities have apparently evolved further.
The emphasis in announcements of patent license agreements between Microsoft and Android device makers appeared to shift to bundling deals: Microsoft was apparently very interested in getting companies to preinstall certain Microsoft Android apps, such as Skype. The derogatory term for this is "bloatware," and no one knows by how much Microsoft lowered those license fees, but analysts speculated that Android device makers saved a ton of money by bundling Microsoft's apps.
Meanwhile, Windows Phone has been discontinued, so Microsoft has surrendered to Apple and Google with respect to mobile operating systems. It still has the Windows desktop and server business, but its growth strategy is centered around apps and services. So far, Wall Street loves that new focus, but it remains to be seen over the years whether Microsoft can fend off competition in markets in which it won't have the benefit of making the underlying operating system. I don't mean to be negative, but the jury is still out on this.
The most surprising and--to me--most disappointing indication of Microsoft now being more interested in apps and services than in its own operating system platforms was when it filed an amicus curiae brief last year with Red Hat and HP, supporting Google against Oracle with respect to "fair use." Parasitic Red Hat and Oracle-obsessed HP had previously sided with Google on copyrightability; Microsoft hadn't. But with respect to "fair use" (which Android's use ofthe Java APIs isn't according to the United States Court of Appeals for the Federal Circuit), Microsoft actually sided with the weak-IP camp.
I don't understand why. Maybe Microsoft would like some more freedom with respect to its own use of the Java APIs (in some enterprise applications and on the Azure cloud); maybe Microsoft is more interested in a constructive relationship with Google (unlike Oracle, Microsoft stopped funding various industry groups accusing Google of abusing its search engine monopoly); maybe Microsoft wanted to curry favor with the open source community this way; or maybe Microsoft is interested in "balance of power" (the historic British take on continental European politics) and is afraid of Apple being or becoming too powerful, so it may not want Android's success to be compromised by the Java copyright situation.
Whatever the reason or combination of reasons may have been, I'd never have expected Microsoft to support Google against Oracle on "fair use." By way of contrast, the Federal Circuit concluded: "There is nothing fair about taking a copyrighted work verbatim and using it for the same purpose and function as the original in a competing platform." The "old" Microsoft--the Windows-centric one--would have been interested in reasonably strong protection of its intellectual property in APIs. The new Microsoft is apparently more interested in access to other companies' APIs.
I interpret yesterday's announcement of the Shared Innovation Innovative as an indication of Microsoft continuing to modify its approach to intellectual property. It's still far from advocating the abolition of software patents, but it appears to be trying hard to be part of the sharing economy in some other ways.
Share with other professionals via LinkedIn:
Wednesday, December 30, 2015
Google switches to open-source license for Java APIs in Android: will this limit Oracle's case to past damages?
I've seen comments on Internet discussion boards according to which the long-running Oracle v. Google copyright infringement dispute has been practically settled, given that Google has just confirmed to VentureBeat that its upcoming release of Android (Android N) will come with Java language libraries that follow "an OpenJDK-based approach." The OpenJDK is licensed by Oracle under the GPLv2 with a so-called Classpath Exception.
It's too early to agree with those who believe it's a virtual settlement (except that damages for past infringement might still have to be determined in court). I do remember that Oracle's lawyers released a statement ahead of the 2012 trial in which they basically said that Google had two options for using Java in Android--a proprietary license or using it on open source terms with the obligation to contribute back to the open source community--but, by simply using Java without either kind of license, Google had committed copyright infringement. That was more than three-and-a-half years ago. Why wouldn't Google have taken this step long before, if such a seemingly simple solution to the legal problem as OpenJDK had existed all along?
There are two possibilities:
It could be that Google is now (that Android has unstoppable momentum) indeed fine with GPL'ing all of Android and just wanted to avoid it earlier on. Android already uses Linux, which is available under only the GPL (no proprietary option there). Now it's also going to use the OpenJDK libraries. So maybe Google doesn't care about applying copyleft--the rule that derivative works incorporating GPL-licensed code must also be published under the GPL (or they must not be published at all)--to Android as a whole. It previously preferred the Apache Software License, which gave Google and its partners more flexibility in terms of throwing closed-source components into the Android mix.
Without knowing how Oracle views this and what Oracle will do, I consider a second possibility no less likely than the first one. It could be that Google still isn't going to put Android as a whole under the GPL. Maybe Google interprets the copyleft rule in the GPL (in this case, in conjunction with the Classpath Exception) in a way that differs from the way Oracle would interpret it. Maybe Google believes it can just replace those Java APIs with something based on the OpenJDK but still doesn't have to put any additional components of Android under the GPL. In that case, Oracle would likely disagree. And that disagreement could then give rise to another lawsuit.
The first possibility is, for now, a possibility. Maybe Oracle will look at Android N (when it's released) and say: this is in compliance with our rules, we just want to get damages for past infringement (including older Android versions that are still out there).
The second possibility, however, would lead to the most significant and dramatic GPL enforcement litigation in history. With the greatest respect for what the likes of Harald Welte and the Software Freedom Conservancy have done on that front, a lawsuit with which Oracle would seek to force Google to release the whole of Android under the GPL would dwarf everything that has ever been done to enforce the GPL.
As a litigation-focused blogger, I can't resist from speculating about what this scenario would mean in procedural terms.
So far, GPL enforcement lawsuits have typically been settled. To the extent that judicial decisions have come down, there is no indication that one can successfully seek what is called specific performance and have a court of law order a GPL infringer to release something under the GPL. It appears that the original right holder can at best obtain an injunction against continuing to distribute the derivative work without making it available on GPL terms.
Let's assume for a moment that Oracle defeats Google's "fair use" defense at next year's trial. It could then seek an injunction against further use of the proprietary Java API declaring code. If Judge Alsup and/or the appeals court agreed, Google would then be barred from continuing to distribute the proprietary Java APIs as part of Android unless it takes a license from Oracle.
But Google would then say: that five-year-old lawsuit is about the proprietary Java APIs, and new Android versions follow what Google now calls its "OpenJDK-based approach."
In that case, Oracle might argue that the injunction still applies, and seek sanctions against Google. So there would be an enforcement dispute.
If Oracle prevailed on the enforcement question, the whole OpenJDK thing wouldn't have helped Google in the end.
However, in order to enforce an injunction arising from the five-year-old lawsuit against Android N, Oracle would have to convince the district court (and/or the appeals court) that this is really an issue that was decided in the original lawsuit. Google, of course, would argue that the copyleft implications of its use of OpenJDK are a completely different matter. I don't want to state a position on this yet, but if the dispute reaches this presently-hypothetical point, I will say what I think (based on the facts that will be on the table at that point, and one of those facts would be the exact wording of the hypothetical injunction Oracle would have won in the meantime).
Without stating a position on a combination of hypothetical events, I think it's not too speculative to say that a not entirely impossible outcome of such an enforcement dispute would be that the court(s) would say: sorry, Google's use of OpenJDK raises one or more new legal questions that must firstly be decided on the merits. In that case, Oracle would have to bring a second complaint against Google, which would be OpenJDK-centric. All of this would take a long time--also including any appeals--to be resolved.
I don't think it's purely coincidental that Google is going down the OpenJDK avenue just in time before Oracle has its next opportunity to obtain an injunction, which will be after the upcoming trial.
If you'd like to be updated on the smartphone patent disputes and other intellectual property matters I cover, please subscribe to my RSS feed (in the right-hand column) and/or follow me on Twitter @FOSSpatents and Google+.
Share with other professionals via LinkedIn:
Saturday, November 7, 2015
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+.
Share with other professionals via LinkedIn:
Tuesday, June 9, 2015
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+.
Share with other professionals via LinkedIn:
Friday, October 24, 2014
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
Kinect-style gesture-based functionality (this exclusion has nothing to do with touchscreen gesture control, as the contract clarifies),
Virtual Reality, and
"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+.
Share with other professionals via LinkedIn:
Sunday, October 19, 2014
The most widespread misconceptions about the Oracle-Google Android-Java copyright dispute
After Google's recent--and expected (this blog was first to report that it was coming)--petition to the Supreme Court of the United States for writ of certiorari (i.e., for a review of the Federal Circuit's decision in Oracle's favor, see my refresher Q&A after the appellate decision), I have seen a couple of articles that described the state of affairs and quoted observers on what all of this meant. In addition, I've seen all sorts of tweets. I don't want to link to them and criticize websites, authors, tweeters, and analysts (some of whom I actually like), but I do see a need to highlight the fundamental flaws in some of the commentary out there. Since the current state of the case--with Oracle being on the winning track--is consistent with what this blog has been saying for years no matter what the mainstream thought and claimed, I feel a certain responsibility to point out some important facts.
These are the most "popular" misconceptions (click on any one of them to jump directly to further detail):
Misconception: this is about control over the Java programming language, which Sun had said was free (or, by extension, any other programming language).
Reality: the commands of the Java programming language are not, and never were, at issue. Google used the "free Java" promise as an equitable defense, which failed in district court and which Google didn't even try to resuscitate on appeal.Misconception: the district judge got it all right because he learned to program Java, thus the appeals court must be wrong.
Reality: not only is the Federal Circuit ruling legally stronger but it is also more accurate in technical terms.
Now the more detailed explanations.
It's not unique to this case but a general problem with litigation reporting that the claims formally brought and taken to trial (and, such as in patent cases against smartphone makers, the products formally accused) can be stated in ways that are not inaccurate in the narrowest sense of the word but don't reflect a plaintiff's strategic priorities.
I've come up with a new analogy: during the 2008 electoral campaign, it would have been numerically correct--but would have missed the point, which is why no one did it in that context--to describe the objective of the Obama campaign as "a senator from Illinois seeking a pay raise from 174,000ドル to 400,000ドル per year." In reality, Barack Obama would have been happy to become president for an annual salary of 1ドル (he was making millions from book royalties anyway). Mischaracterizations of this kind, which would be unthinkable in political journalism, occur on a daily basis in legal journalism.
Here, Oracle itself made very clear at a key juncture in the district court proceedings that its #1, #2, #3, #4 and #5 objective was a copyright injunction. Obviously, either company's--and any other company's--CFO will care about a billion-dollar amount going in or going out. But if the only net effect of this protracted litigation was a billion-dollar payment from Google to Oracle, and maybe some reputational implications for the convicted infringer, none of us (besides those companies' CFOs) would really have to care.
The remedies the statutes allow are just a means to an end. In some ancient cultures you could have asked the judge or king for anything to right a wrong, and the decision-maker had unlimited leeway, including the option of telling Google to make Android Java-compatible. Not so now, where we have statutory law and a rich body of binding case law. The prevailing (or likely-to-prevail) right holder will then sit down with the other party and work out a solution, but needs monetary and, even more so, non-monetary remedies to have leverage.
In my refresher Q&A after the appellate ruling, I already said that this case was not really about a billion dollars.
I've previously criticized that certain amicus briefs (and campaigns to orchestrate support for amicus briefs) overbroadly and insolubly vaguely referred to the "use" of APIs.
The most common use of APIs is simply to write applications for a platform, or applications that communicate with cloud services, where APIs are communications protocols. That's what zillions of programmers do every day. Compared to that most common use of APIs, there's only a very small, almost negligible number of companies and developers that create partial or complete clones of platforms.
No app or cloud developer needs to worry that Oracle's enforcement efforts against Google have anything to do with the most common form in which APIs are used. This is not about Google having written Java apps.
If a company makes the APIs of its platform or cloud service available to third-party developers, it will normally be estopped (precluded because of its own actions) from enforcing API copyrights against those who reasonably rely on the right holder's interest in attracting developers to a platform. Developers would also be able to raise a "fair use" defense. But all of this is very theoretical because, in practice, a platform maker won't suddenly turn around against developers: it will continue to court them.
Misconception: third-party, independent implementations of APIs would become illegal unless the Federal Circuit ruling was reversed.Reality: copyrightability is only the first of several criteria that must be met in order for an independent API implementation to be unlawful. Many roads lead to Rome, i.e., API freedom.
The Oracle v. Google case is a pretty good showcase of the various defenses an alleged copyright infringer can raise. That's why it's all the more misguided that some people look at the legality of third-party API implementations exclusively through the (non-)copyrightability lens.
The Federal Circuit remanded the case to the district court for a new trial on "fair use." That defense was not adjudicated at the first trial. The jury was hung, which meant that the issue needed to be revisited unless the material at issue wouldn't have been copyrightable, which would be dispositive in its own right (and which is what Judge Alsup thought but the Federal Circuit disagrees with). In this particular case, I don't think Google's "fair use" argument has merit, but there could be other cases in which independent implementers of APIs could prevail on the grounds of fair use.
The Federal Circuit also mentioned, in a footnote, the possibility of a compulsory license on FRAND terms. In cases of extreme market power, this is a last--but often effective--resort.
In a case in which a platform maker encourages widespread adoption of an API (and not just of the commands of a programming language), equitable defenses could also tip the scales in a defendant's favor. (Google's equitable defenses in this case failed, and Google didn't even try to revive them on appeal.)
It's unsophisticated at best and intellectually dishonest at worst to limit the question of independent API implementations to copyrightability, which is an extremely coarse filter because it does not enable fact-specific case-by-case determinations.
Misconception: this is about control over the Java programming language, which Sun had said was free (or, by extension, any other programming language).
Reality: the commands of the Java programming language are not, and never were, at issue. Google used the "free Java" promise as an equitable defense, which failed in district court and which Google didn't even try to resuscitate on appeal.
Sun encouraged everyone to implement the Java language. Its commands and keywords and syntax. But even the district court (whose non-copyrightability finding Google's supporters love so much) stated clearly that Google had failed "to prove an overt act by Oracle and/or Sun relaying its intent to abandon rights as to the specific elements asserted here." Relatively speaking, a 2007 blog post by then-Sun-CEO Jonathan Schwartz was Google's best argument, and even that one fell far short of what would have helped Google with respect to the intellectual property rights Oracle actually asserted in court.
The Federal Circuit was aware (as its ruling indicated) that there may be material in 3 of the 37 Java APIs at issue that one could describe as being inextricably linked to the Java language--but only 3 out of 37.
It speaks volumes that Google didn't try to get the appeals court to revive those equitable defenses.
A long time ago, Sun made certain Java material available under the GPL (GNU General Public License), a free and open-source software license. The key characteristic of the GPL is the "copyleft" principle: if you obtain a program under the GPL and modify it, you're not allowed to publish your modified version under a license that would deprive others of the freedoms the GPL had afforded you in the first place. In the Creative Commons universe, this principle is called "share-alike": share on the same or substantially similar terms as the ones you benefited from.
Google never opted for the GPL route. Otherwise it would have had to publish Android as a whole under the GPL. As a result, device makers would have had to publish their proprietary extensions (things like Motoblur, HTC Sense, Samsung TouchWiz etc.) under the GPL as well. This would have made it practically impossible for OEMs to differentiate through proprietary Android extensions. So none of the key players in the Open Handset Alliance would have liked the idea.
With or without the Federal Circuit copyrightability determination, the GPL applies, always has applied, and always will apply, to the open-sourced parts of Java. But that is not a commercial option for Google. For the open-source community it would be, and actually is, an option. After Oracle sued Google, the Free Software Foundation actually reminded people of the fact that Google could have avoided the whole problem by using Java on GPL terms.
API copyrightability makes the GPL's copyleft feature even stronger, but it's pretty strong in any event.
Google mentioned open source a lot in the early stages of this dispute. But it never raised a contract-based (license-based) defense. Not pursuing the equitable defenses on appeal was weak, but never even raising a GPL-based defense was weaker than weak. The smokescreen nevertheless worked with people who don't know how the GPL works and with some who did but intentionally misled the rest.
What Oracle is asserting in this case is a body of 37 Java APIs with a total of approximately 7,000 lines of declaring code. Neither Oracle's theories nor the Federal Circuit ruling suggested that the threshold for copyrightability would be lowered to the point at which the definition of a Math.Max function would have become copyrightable in its own right. The hurdle isn't high, and the Federal Circuit threw out Google's attempts to have items like the nine-line RangeCheck function declared uncopyrightable. But if you want to get a single line of program code protected by copyright, you better present something reasonably expressive and creative.
A week ago I explained, toward the end of a blog post on how Google's argument has become an all-out attack on all software copyright (rather than a surgical strike against API copyrights), that Google misportrays the Federal Circuit's rationale by suggesting that anything that can be written in more than one way would automatically be copyrightable. I also looked at it mathematically. Even if one looked at only 70 (1% of 7,000) of the lines of declaring code at issue and assumed only an average of 3 alternatives per line (way too low), the number of possible combinations would have more than 30 zeros, not even counting possible permutations because different lines could be assigned to different packages, and for any given code there could be many different numbers of packages.
Misconception: the district judge got it all right because he learned to program Java, thus the appeals court must be wrong.
Reality: not only is the Federal Circuit ruling legally stronger but it is also more accurate in technical terms.
I can only shake my head when I read in certain articles that people were sooooooo impressed by the judge saying he learned Java, as he told Oracle's counsel in open court, and that he had programmed, in different languages, something like rangeCheck many times. Sorry, but that's not the way to distinguish between right and wrong decisions. If a judge, or a panel of judges, never programmed one line of code in Java or any other language, but correctly applies the basic rules of U.S. copyright law and correctly interprets the statute (particularly § 102) and the case law (including the Sega and Sony stuff Google's cert petition doesn't even cite to, despite references to multiple decisions by appeals courts, including other decisions by the Ninth Circuit), then that's what matters. And nothing else.
People also forget about the significance of a unanimous decision by a three-judge panel (at the Federal Circuit) as compared to a single judge's opinion.
Judge Alsup was right that programmers perform range checks all the time. Just this year I've written code of that kind on several different occasions. But rangeCheck, which Judge Alsup also deemed copyrightable (a fact some people seem to have forgotten; affirmed by the Federal Circuit, by the way), is not at the heart of this case. The declaring code of the 37 Java APIs is, and the Federal Circuit judges, who never claimed to have learned Java or any other programming language, accurately noted that apart from maybe 3 APIs, those are separate from the Java language, while Judge Alsup conflated language and API issues.
If the measure is whether someone has programming experience, the same people who were behind Judge Alsup's apotheosis after the erroneous 2012 non-copyrightability ruling would actually have had to trust me to a greater extent than a non-programmer paralegal's blog. I've done a lot of programming; it's what I'm doing again (and will go back to right after this post). I wrote 10 computer books, mostly on programming topics, while in high school. One of them was a commented version of the assembly (machine) language code of an entire operating system and language interpreter, of which I can show you a small excerpt (click on the image to enlarge):
So let's please go back to the facts and to what the law says and not make it a question of whom we want to trust, and let's especially not be misled by our enthusiasm for the idea of a judge ruling on a tech case having actual programming knowledge, no matter how much we like the notion.
Checking in one's brain at the wardrobe in exchange for uncompromised allegiance to Judge Alsup (because he said he learned Java) is a major mistake. What's far worse is blind faith in a (no longer active) blog that wanted the world to believe it was an open discussion forum representative of the sentiment of open-source folks while having been convicted of a particularly malicious form of censorship whenever its own users disagreed with the propaganda and party line.
Further above I've explained why Google never had and never even tried to raise an open-source defense. It's unbelievable that a blog claiming to advocate open-source interests suggested that Google was in the clear thanks to Sun's decision to open-source certain Java material.
At this stage, Oracle v. Google is a copyright-only case, but initially various patents were at issue, and that blog totally blew out of proportion the significance of first Office actions formally "rejecting" patent claims. Most of the time, first Office actions mean very little, and if they are issued by an examiner who (as was the case for some examiners based on a sample that academics studied) initially "rejects" 100% of the challenged claims. A first Office action can be reasonably meaningful if it issues, as it happened in connection with an Apple autocomplete patent, about a year after a decision to reexamine. In that case, the examiner didn't routinely "reject" all claims but must have arrived at a reasonably well-considered conclusion. So one must look carefully at non-final USPTO actions so as not to jump to conclusions, as a certain "G" blog did just because it liked this. One of the initially-"rejected" Oracle patents was actually affirmed by the USPTO right after the start of the 2012 trial, but too late to still be presented to the jury.
The archives of that source of confusion and misinformation are certainly not a good place to start one's research (though I think that blog could have made some useful contributions to other recent debates, such as the way this year's Apple v. Samsung trial in California went).
I've taken consistent positions on API copyright in general and Oracle v. Google in particular at different stages, starting more than ten years ago (when I had a debate at a conference with an EFF staff lawyer on interface copyrights in connection with Blizzard v. bnetd) and even shortly after fighting against Oracle's acquisition of Sun. And I'll continue to defend those beliefs going forward. I'm very confident that the Supreme Court will either deny cert or will otherwise affirm the Federal Circuit. The Supreme Court won't get confused the way parts of the general public, the media, and industry observers apparently do.
If you'd like to be updated on the smartphone patent disputes and other intellectual property matters I cover, please subscribe to my RSS feed (in the right-hand column) and/or follow me on Twitter @FOSSpatents and Google+.
Share with other professionals via LinkedIn: