Showing posts with label FSF. Show all posts
Showing posts with label FSF. Show all posts

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, December 9, 2014

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

Share with other professionals via LinkedIn:


Thursday, May 10, 2012

EFF and FSF comments on partial jury verdict raise total non-issues

After the partial verdict finding Google to infringe 37 Java APIs (while not taking a position on Google's "fair use" defense), two of the world's most prominent software advocacy groups, the Electronic Frontier Foundation (EFF) and the Free Software Foundation (FSF), issued statements on intellectual property questions relating to APIs (application programming interfaces).

Looking beyond this particular issue, I agree with those organizations in some areas and disagree in others. Generally speaking, I'm a lot closer to their positions on software patents than those on copyright. I respect the great work that both of them do in certain contexts. I'm not going to do a complete rebuttal of all parts of their Java API statements that I disagree with, but I'd like to highlight some specific examples with respect to which they simply cry wolf by pointing to potential problems that were resolved years ago.

The EFF uses Samba as an example as if there had never been an EU antitrust case over the relevant protocols

Here's the fifth paragraph of the EFF's statement dated May 7, 2012:

"Take, for example, a free and open source project like Samba, which runs the shared folders and network drives in millions of organizations. If Samba could be held to have infringed the Microsoft's copyright in its SMB protocol and API, with which it inter-operates, it could find itself on the hook for astronomical damages or facing an injunction requiring that it stop providing its API and related services, leaving users to fend for themselves."

There's no need to worry about interoperability between Microsoft's Windows server products and Samba. The European Commission's Directorate-General for Competition (DG COMP) and the Court of First Instance of the EU determined that Microsoft had a dominant position in the relevant product market and, therefore, an obligation to grant a license to all of the intellectual property (a term that includes copyright as well as patents and other types of rights) required for interoperability purposes.

It's absolutely wrong that the Samba team "could find itself on the hook for astronomical damages or facing an injunction". This never happened and it never will, as a result of the EU-Microsoft case.

The EFF doesn't mention this important fact, but this actually shows that interoperability can be achieved in many ways -- in this case, antitrust law came into play -- and doesn't depend on anti-IP policies.

Denying copyrightability of complex creations that satisfy the originality requirement only because further down the road intellectual property might impede interoperability throws out the baby with the bathwater. The right approach is to address copyrightability based on the merits of what was created, and to deal with interoperability at a subsequent stage with other tools including but not limited to competition law. There are many benefits to the approach I favor. One of them is that any kind of interoperability privilege should benefit only those who truly create compatible, interoperable software -- not those who, like Google in this case, purposely create incompatible, non-interoperable platforms.

The EFF's focus on copyrightability is akin to thinking that because all you have is a hammer, everything is a nail.

The FSF promotes Google's interests instead of the GPL and is ungrateful for Oracle's (Sun's) support of the GPL

The FSF published a statement that includes the following quote attributable to its executive director, John Sullivan:

"Were it grounded in reality, Oracle's claim that copyright law gives them proprietary control over any software that uses a particular functional API would be terrible for free software and programmers everywhere. It is an unethical and greedy interpretation created with the express purpose of subjugating as many computer users as possible, and is particularly bad in this context because it comes at a time when the sun has barely set on the free software community's celebration of Java as a language newly suitable for use in the free world. Fortunately, the claim is not yet reality, and we hope Judge Alsup will keep it that way."

I am puzzled by this statement for two reasons:

  1. Usually the FSF promotes the GPL, the license that it claims is designed to ensure the freedom of computer users and software developers. But Sun has published, and Oracle continues to make available, core Java technologies under the GPL. It was Google's choice not to use that GPL-based Java code -- and the reason why Google decided not to use it is because it wants to deny users the freedoms the FSF normally advocates. Not only does Google eschew the GPL in connection with Android because it wants to provide software under other licenses but it also wanted to be able to tell device makers that they could build (as all of the major players did) proprietary, closed-source Android extensions for the purpose of differentiation. If Google agreed with the FSF as much as the FSF supports Google here, Google would have taken Java code on a GPL basis, and there would be absolutely no threat to "free software and programmers everywhere".

    The FSF statement is nonsensical for that reason. It's also utterly ungrateful for the fact that Oracle/Sun support the free software community. Even if the FSF had a point about the risks of API copyrightability (which in my view it doesn't, but let's assume it does only for the sake of the argument), this would be a non-concern to the GPL community. The FSF takes a seemingly principled position that is actually absurd considering that the issue it raises only affects those who distribute Java on non-GPL terms.

  2. If any kind of conduct at issue in this dispute is "unethical and greedy", it's the fact that Google, after negotiating a license for Java and concluding it didn't like the terms, simply hijacked Java for financial gain and commercial, strategic purposes. The "father of Java", James Gosling, clarified that "Google totally slimed Sun".

    The fact that Google actually would have had access to Java on free-of-charge terms under the FSF's own GPL but instead wanted to use it under other licenses makes Google's behavior even more unethical.

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, September 25, 2010

Does the S in FSF stand for "spamming"?

The Free Software Foundation appears to be turning, slowly but surely, into the Free Spamming Foundation.

Recently I criticized the FSF's belated statement on Oracle's patent infringement suit against Google for a host of reasons. Mostly, I felt that it was misleading pro-GPL propaganda. Note that I vigorously defended MySQL's GPL-based business model and "copyleft" in connection with Oracle's acquisition of Sun. But I reject overstatements of the GPL's (especially the GPLv2's) ability to deal with patent attacks. In addition to that, I criticized the FSF's call to spam Oracle CEO Larry Ellison's email account.

Now I just saw that spamming indeed appears to be a cornerstone of the FSF's strategy concerning patents. Its newest target: the United States Patent and Trademark Office (USPTO).

Under the headline "Encourage the USPTO to stop issuing software patents; deadline September 27", the FSF issued an urgent call on the community to answer a request for comments by the USPTO concerning the interpretation of the Supreme Court's Bilski ruling. For the future evaluation of patent applications, the USPTO wants to write up new guidelines reflective of the Bilski decision.

The Bilski case was (or could have been) a very important one

The Bilski case was an important one indeed, and I reported on it from several angles. In an immediate reaction, I described it as a major disappointment for the NoSoftwarePatents cause; I listed the top ten Bilski losers, among them the FOSS movement; I explained that doing away with software patents on the grounds of them being too abstract is a losing strategy; I also commented on IBM's outrageously cynical submission spitting in the face of the FOSS movement and on Google's position, which definitely didn't speak out against the patentability of software.

So I don't deny that the conclusions the USPTO is now going to draw from the Bilski ruling are an important step. However, spamming the USPTO, whose only job it is to apply the law (not to make it), is an ill-conceived and counterproductive approach. It's like protesting against foot soldiers. It won't do away with a single software patent. It won't reverse the defeat that the Bilski decision was for the abolitionist movement. But it will for sure reflect very unfavorably on the FOSS movement as a whole.

What the USPTO wants is well-crafted professional input

Even though consultations such as this one are open to the general public, patent law is a complex subject requiring a vast amount of knowledge, so what the USPTO really hopes to receive is input from professionals. Let me quote from its request for comments:

The Office is especially interested in receiving comments regarding the scope and extent of the holding in Bilski.

In other words, this is about legal interpretation. The Supreme Court took a position on some aspects of substantive patent law (the rules for what is and what isn't patentable), though not on as many as a lot of people hoped. Now it's about drawing the right conclusions from it.

You can't outvote the law

This isn't going to be a "democratic" decision-making process. It's not a vote on a TV show. If the FSF mobilized a million people to call for the abolition of software patents, it still wouldn't change the basis on which the USPTO has to operate, which is the law as it stands and as the courts, especially the highest one of them in the US, interpret it. Spam doesn't contribute anything of substance. It's just an annoyance and a distraction.

It would be perfectly appropriate for the FSF to make a substantive submission to the USPTO, or to encourage FOSS-friendly patent professionals to do so. But instead of arguing the real issue, the FSF just provides copy-and-paste paragraphs and general guidance and asks the community to tell the USPTO -- among other things -- how software patents "take freedom away from all computer users". Software freedom is a vision I like, but it's not a legal concept. It's not in the Constitution, it's not in the Supreme Court's Bilski decision, and it won't play a role in the USPTO's new guidelines.

An email campaign like that is a nuisance (to put it diplomatically). The USPTO doesn't make the law; it doesn't have the authority to interpret it like a court; it simply has to operate within the given framework. The FSF tries to put some blame on the USPTO but doesn't understand that US patent law was indeed designed to evolve expansively as new technologies are invented and adopted. Restrictions require democratic decisions, and the USPTO isn't a democratic decision-making body. Those decisions are the prerogative of Congress.

The FSF apparently knows that it can't persuade Congress of its anti-IP agenda. So it firstly rested its hopes on the Supreme Court (which made it pretty clear in the Bilski decision that if you want to exclude anything from patent-eligibility, you have to talk to the lawmakers, not to the judges) and now tries to pressure the patent office.

Email campaigns can be legit -- but not in this case

Let me point out that there are indeed situations in which it makes sense to mobilize citizens for email campaigns. In particular, if lawmakers are in the process of forming opinions and preparing decisions, it's perfectly in line with democratic concepts to let citizens voice their wishes, hopes, fears, concerns, doubts, whatever. Our directly elected representatives should listen to us.

Of course, it also depends on how, when and on what scale such campaigns are conducted. There are many circumstances that one must consider. Wherever such a campaign is inappropriate, it backfires. It gives the impression that the ones conducting it have lost on the basis of reason and resort to desperate and defiant spam tactics.

In a case like this request for comments by the USPTO, the only appropriate (and the only productive) input will have to be presented professionally, and there's no strength in numbers.

If you'd like to be updated on patent issues affecting free software and open source, please subscribe to my RSS feed (in the right-hand column) and/or follow me on Twitter @FOSSpatents.

Monday, September 13, 2010

FSF statement on Oracle vs. Google is a shame: misleads, puts GPL above freedom, spares IBM

The Free Software Foundation needed about one month after the announcement of Oracle's patent infringement suit against Google to issue this statement.

One month was apparently needed to come up with a statement that despite a few good points calls into question whether the FSF truly cares about the values it claims to advocate. The statement is designed to mislead people with propaganda; it demonstrates concern only for the GPL, not for the cause of software freedom; and it's disconcerting that the FSF turns a blind eye to what IBM (one of its sources of funding) does.

I commented on the FSF statement last week. You can find me quoted by ZDNet's Linux and open source blog and by V3.co.uk. I also posted comments to LinuxWeeklyNews (LWN.net).

Given the importance of not only the Oracle-Google case but also the more fundamental concerns I have about the FSF's statement, I decided to publish this analysis.

Before I go into detail, let me stress that I don't doubt the integrity of Richard Stallman (RMS). He's a true visionary and he's absolutely dedicated to his cause. I have seen him campaign against software patents, and he's the last person in the entire IT universe I'd ever suspect of being in whatever company's pocket. However, I fear he may sometimes rely on people who aren't equally true to those values, and when it comes to the funding of his organization and (even more so) of affiliated entities, Richard may have the attitude of certain Roman emperors.

1. Where I agree: appropriate criticism of Google

The FSF rightly notes that Google "still has not taken any clear position or action against software patents." I also wrote about that fact last month when I analyzed Google's amicus curiae brief in re Bilski & Warsaw v. Kappos.

I share the FSF's view that Google apparently wanted "to make proprietary software development easier on Android." I previously mentioned the "proprietary, closed-source strategies of certain vendors of Android-based phones" and linked to an external article entitled "The Sad State of Open Source in Android tablets".

2. Dangerous and misleading: GPLv2 touted as "strong defense" against patents

This is a passage of the FSF statement that I condemn as dangerous propaganda that's so misleading it's actually dishonest:

And [Google] could have avoided all this by building Android on top of IcedTea, a GPL-covered Java implementation based on Sun's original code, instead of an independent implementation under the Apache License. The GPL is designed to protect everyone's freedom — from each individual user up to the largest corporations — and it could've provided a strong defense against Oracle's attacks. It's sad to see that Google apparently shunned those protections [...]

Watch particularly the middle sentence. On its own, the claim that the GPL is designed to protect software freedom is acceptable as a mission statement. What's wrong is to give a vast majority of all recipients the impression that the GPL can be a "strong defense" against patent attacks. The FSF has every right to promote the GPL, but not by questionable means.

While the FSF doesn't claim so literally, that almost sounds like the GPL is to software developers what the cross and the wooden stake were to Buffy the Vampire Slayer – the lead character of the popular TV series who never left home without them. No version of the GPL can deter patent aggression by any third party who isn't bound to GPL terms itself. Not in any way. Sure, the FSF didn't say the GPL is a magic wand, but the passage I quoted reflects a desire to lead some people to think so.

At the most, the GPL can make things harder for a patent holder who published software under the GPL, provided that (i) the relevant program code reads on the patents asserted and that (ii) the alleged infringer uses that GPL'd software.

The limitations of an implicit patent license

The FSF argues Google should have used IcedTea. IcedTea was derived from Oracle/Sun's OpenJDK, so it's a fork of program code available under the GPLv2.

The GPLv2, however, only has an implicit (implied) patent license. It doesn't say explicitly "I, the patent holder, grant you, the licensee, a perpetual, worldwide, irrevocable license...". There are references to patents in GPLv2 but those are more like an encouragement not to publish patent-encumbered software under the GPL than an actual license grant.

Even when a software license doesn't contain an explicit patent license, it would obviously be unfair if a patent holder could make software available to many people as a trap only to later sue them all for patent infringement. Under US law, the legal theories according to which an "infringer" can argue that he was granted an implied patent license are called legal estoppel, equitable estoppel, conduct, and acquiescence. Other legal systems have similar theories in place.

So it comes down to a general fairness principle, which is easily applied if someone uses unmodified software published by the patent holder: in this case, the original OpenJDK code. But it's complicated and risky once we're talking about forks (derived versions), such as IcedTea or let alone whatever Google would have had to do to turn IcedTea into what its Dalvik virtual machine is for Android.

The FSF would like people to think that the GPLv2's implied patent license extends to forks. The problem is that if programmers rely on this assumption (which is just the FSF's position and absolutely unsupported by case law), they may have to pay the price.

There is indeed serious doubt about the extent to which the exercise of "freedom 3" (the right to distribute modified versions of a free program) is safe if there are patents in play. Dan Ravicher, a lawyer affiliated with the FSF, was honest enough to point out six years ago that this is a "gray area". Last month I already explained that the European Commission also voiced serious doubt about the scope of an implied GPLv2 patent license in its decision on Oracle's acquisition of MySQL as part of Sun. The Commission, too, was concerned about the extent to which forks would be covered.

Promoting the GPL and the FSF's power rather than "freedom 3" and the truth

That's why I really object to the FSF's claim that the GPLv2 "could've provided a strong defense": the GPLv2's ability to protect against patent attacks is reversely proportional to the extent software developers exercise the said "freedom 3" (redistribution of derived works). If you don't modify any patent-encumbered GPL'd code, you're presumably protected; if you make changes to the existing code base, you enter a dangerous gray area (in which IcedTea probably already is, even though the GPL apparently tries to reassure IcedTea users that they're safe); and once you add completely new code on top, it's pretty certain that the GPL can't do anything for you if that code infringes any patents.

The GPL shows that defending software freedom and telling people the whole truth are at best secondary objectives. What the FSF really wants is promote the GPL, spur its adoption and thereby expand its influence. That is, regrettably, the way I interpret that part of the FSF's statement.

One could argue that the FSF only said "could've" (provided a strong defense). But "could've" isn't "might have". The way many people will reasonably interpret it is that if Google had opted for IcedTea under the GPL, it would have been safe (or if it opted for it now, it might be safe in the future). But there's far too serious doubt about that assumption, as I just explained. So it's dishonest to suggest that there could have been a "strong defense."

On the contrary, if Sun had published its OpenJDK under the Apache license 2.0, and if Google had used such code on those terms, there would be a much stronger protection because that license contains an explicit patent grant.

3. Email to Larry Ellison: the wrong approach

The FSF's call on people to send email to Oracle founder and CEO Larry Ellison to protest against software patents is inappropriate. Those are spam tactics. There are email addresses to which it's legitimate to send messages, such as to members of parliaments because they are the elected representatives of citizens and should take direct input from their electorate. It's also OK to send messages to email addresses that are set up for the receipt of input from large numbers of people. But an orchestrated email campaign shouldn't target someone's personal address.

I fought against Oracle's acquisition of Sun, and believe me, that company is a really tough opponent. Still I believe one can deal with controversy in a more civilized way than what the FSF proposes.

I don't think even a million messages would change Oracle's stance on this. But every such email will discredit the FOSS movement in the eyes of serious people.

4. The FSF conspicuously spares IBM

Considering how hard the FSF tries to pressure Oracle and (rightly) criticizes Google for its position on freedom and patents, it doesn't sit well with me that IBM, one of the primary financiers of the FSF and some of its affiliated entities, gets away with much worse behavior.

IBM's patent threats against Hercules, a mainframe emulator that is available under a license recognized by the FSF as a free software license and by the OSI as an open source license, are actually much worse. Those threats became known five months ago, and there's been deafening silence on the part of many free software entities, to the extent that I conclude they are only selectively free.

One can argue that IBM has not (at least not yet) gone to court. However, litigation is always just the last resort for any patent holder. Whether a patent holder has strategic objectives or just wants to make money (like a "patent troll"), everyone prefers to get their way without having to go to court. Most of the damage that patents do is actually done outside the courts.

In IBM's case, there's a clear case of exclusionary strategic use: Big Blue uses those patents to draw a line in the sand and maintain its hugely lucrative mainframe monopoly, keep customers locked in with respect to mainframe legacy workloads, and to expand and extend that lock-in to enterprise cloud computing.

By contrast, there's no indication so far that Oracle wouldn't be willing to negotiate a license deal with Google.

But this isn't just about Oracle as compared to IBM. The FSF's criticism of Google, which I support, would also apply to IBM.

It's true that Google's Bilski brief didn't speak out against the patentability of software; it was basically just a request for slightly higher quality standards. But IBM's Bilski brief was much worse, claiming that software patents liberated programmers and were key to the rise of FOSS. The FSF should have taken Big Blue to task over this. Such unbelievable cynicism would actually have been more of a reason for a pressure campaign against a company than Oracle's dispute with Google, about which there are so many unknowns for now.

Finally, the FSF criticizes Google for having built Dalvik on top of (a part of) "an independent [Java] implementation under the Apache License". What the FSF means is a project named Harmony, which Google decided to fork. I said before that Google probably did this to facilitate closed-source Android products. But you know which company actually started Harmony and isn't mentioned by the FSF? IBM.

On the Harmony project's contributor page, about every second person (ten out of two dozen) is an IBM employee, about half of them from China and half of them from the UK. Plus, IBM is known to fund the Apache Foundation in general.

That doesn't excuse Google in any way. But IBM started this and the fact that it isn't even mentioned raises questions about the FSF's independence from Armonk.

If you'd like to be updated on patent issues affecting free software and open source, please subscribe to my RSS feed (in the right-hand column) and/or follow me on Twitter @FOSSpatents.