FOSS Patents

These days, when companies announce a restructuring (or the exploration of "strategic alternatives") with respect to their patent portfolios, it usually means that someone hopes to sell out or to ratchet up monetization. Today, Qualcomm announced a restructuring that is simply a precautionary measure. Qualcomm keeps almost all of its patents in the existing parent company but spins off research and development. Qualcomm forms "a new wholly owned subsidiary, Qualcomm Technologies, Inc. (QTI), which, along with its subsidiaries, will operate substantially all of Qualcomm’s research and development activities, as well as product and services businesses, including its semiconductor business, QCT". This is because "the company expects that QTI and its subsidiaries' product and services businesses will increase their work with open source software in the future and this restructuring will, among other things, help ensure that QTI and its subsidiaries’ activities do not result in the licensing of any of Qualcomm Incorporated's patents, including its 3G and 4G patents".

What does this mean? Qualcomm knows that its patents are the crown jewels of the company and is concerned that it could lose its ability to enforce some of those crown jewels against third parties just because of the patent-related pitfalls involved with open source licensing. This would adversely affect Qualcomm's licensing business and its shareholder value.

Open source licensing is a tricky thing. At first sight, many people are led to believe that such licenses as the GPL, the Apache license or the various BSD-style licenses are straightforward and have no significant downside. But those who contribute to open source projects or redistribute software under open source licenses may indeed restrict their ability to enforce patent rights against others. Open source licenses are primarily copyright licenses, but some contain clauses on patents and even those that don't mention patents at all can be construed to constitute a grant of an implicit patent license. Open source software is free, and for a company like Qualcomm it would be devastasting if some of its patents could be used on a royalty-free and largely or entirely restriction-free basis just by incorporating certain open source code with which Qualcomm is involved (as a contributor and/or redistributor) into third-party products.

BSD-style licenses are very short and usually don't mention patents explicitly. The GPLv2 (the license under which Linux, MySQL and many other open source programs are published, though it's less popular now than it used to be) makes some references to patents but lacks clarity in this area. That's why the GPLv3 was primarily created in order to make up for the GPLv2's patent-related shortcomings, but GPLv3 is ideologically-charged and much less popular. The Apache Software License also makes explicit reference to patents but is more palatable to commercial players than GPLv3. Still, the philosophy behind open source licenses is usually hostile to patents.

For a large organization like Qualcomm, it's very difficult to manage the use of open source licenses on a company-wide basis. If you have an engineer somewhere who isn't aware of the legal issues involved but contributes some code to an open source project, or incorporates open source software into some Qualcomm technology, the impact on Qualcomm's patents could be far-reaching -- and the company might not know it until it sues someone over a patent and suddenly faces a license-related defense. It's impossible to have a lawyer look over every engineer's shoulder all the time. Qualcomm was apparently aware of these risks and opted for a new corporate structure under which it can counter any license-based defense by pointing to the fact that a subsidiary cannot license out its parent company's patents.

The effort of restructuring a company of Qualcomm's size is very significant. The fact that Qualcomm undertook this effort shows how protective its management is of its patents and how profound its concern over the implications of open source licenses must have been.

The organizations behind certain popular open source licenses, such as the Free Software Foundation (GPL) or the Apache Software Foundation, will probably look closely at what Qualcomm is doing and discuss internally whether Qualcomm's restructring is a blueprint for all those who seek to circumvent the patent clauses of open source licenses in a way that runs counter to the spirit of those licenses or, even worse, renders the patent clauses of those licenses ineffectual. There will probably be some lively debate on certain internal (or even public) mailing lists.

And many other companies that make use of and/or contribute to open source software will also think about whether their corporate structure poses a risk to the enforceability of their patent rights.

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

Follow @FOSSpatents

Share with other professionals via LinkedIn:

On Sunday (April 22, 2012) afternoon, Oracle filed a "motion seeking a clarifying instruction [...] regarding Apache Harmony". Its lawyers see a "substantial risk of juror confusion and prejudice to Oracle" resulting from a combination of arguments that Google makes with respect to the Apache Harmony project on the one hand and the Apache license on the other hand:

• "Google has repeatedly argued to the jury that Apache Harmony had used Sun’s Java APIs and that 'Sun said fine.'"

• "Google has also repeatedly argued, and elicited evidence, that it took the 37 accused APIs from Harmony."

• "Further, Google repeatedly refers to its distribution of Android under an 'Apache license,' which does not actually mean any license from Sun to Apache or Apache to Google, but instead confusingly refers to the standard Apache terms that Google imposes on Android licensees."

Oracle's lawyers don't want the jurors to think, as a result of the above, that Apache had rights to the Java technology that it gave to Google. That would mean that Google is indirectly licensed, but when the Apache Foundation resigned from the JCP Executive Committee in protest, it actually stated on the organization's official blog that the "Java specifications are proprietary technology that must be licensed directly from the spec lead under whatever terms the spec lead chooses."

In this regard, Oracle is also uncomfortable with Google's selective quoting from this May 2007 article by eWEEK's Chris Preimesberger. Google refers to a quote from then-Sun CEO Jonathan Schwartz ("there is no reason that Apache cannot ship Harmony today") and portrayed it to the jury as "an excerpt from a press release where Mr. Schwartz said you can ship as long as you don't call it Java". However, an eWEEK article is not a Sun press release -- otherwise eWEEK would belong to Oracle at this stage. Oracle points out that the very next sentence after the quote says: "That is technically true but Apache officials said that to do so with the TCK [Technology Compatibility Kit] restrictions in place would actually go against the Apache Software license."

Oracle wants a clear distinction to be made between

1. "Apache's use of Sun's Java specifications for Harmony;

2. Google's use of code from Apache Harmony; and

3. Google distribution of Android under the Apache license."

In particular, Oracle stresses that the license under which Apache distributes Harmony and Google distributes Android is irelevant to the question of whether Google has a license to Oracle's API specifications.

Oracle therefore proposes that the following text be read to the jury:

"You have heard testimony regarding a project called Apache Harmony, and you have also heard testimony regarding an Apache license. These are two separate issues, and I will provide some clarification on those two issues now.

Harmony was a project by the Apache Software Foundation to develop an independent implementation of Sun's Java specification. The parties do not dispute that the Apache Software Foundation used Sun's Java specifications for Harmony. There is also no dispute that the Apache Software Foundation sought a TCK license from Sun for Harmony, but Sun refused to grant one.

There has been evidence that Google used code from Harmony for Android. Because Sun never granted the Apache Software Foundation a TCK license for Harmony, you may not find that Google's use of Harmony conveyed to Google any rights to use Sun's Java specifications, or provides Google with any defense to copyright infringement, if you find that such infringement occurred.

You have also heard about the 'Apache license.' The Apache license is a type of open source license that Google chose for its distribution of Android. It is not a license under which Sun made Java intellectual property rights available. Google's distribution of Android under an Apache-type license is separate from the issue of Apache Harmony. The fact that Google distributes Android under an Apache license has nothing to do with Google's use of code from Harmony, and also does not provide Google with any defense to copyright infringement, if you find that such infringement occurred."

Google opposes this. In Google's words, Oracle "asks the Court to do the job of Oracle's lawyers" and "to make factual findings about Apache-related issues and impose them on the jury, rather than allowing the parties to present evidence and then argue the significance of that evidence to the jury, as should be done", and "to blunt the impact of the undisputed facts that Sun was aware of the Apache Software Foundation’s use and distribution of the same Java API packages at issue here for over five years, Sun was aware of the use of Harmony packages in Android, and Sun never asserted that Apache infringed its intellectual property".

Google says that Oracle has not sued Apache to this day. I don't think it's a good idea for a self-proclaimed good citizen of the open source community to tell Oracle that it's a mistake to refrain, for now, from suing the Apache Foundation.

According to the response brief, some of Google's witnesses including but not limited to Eric Schmidt and Andy Rubin "will testify about Google's use of the Harmony API packages and class libraries, and the fact that Sun not only sat by while Apache distributed Harmony but even welcomed Google into the Java community after Google announced its use of Harmony intellectual property in Android". Google also expects that Jonathan Schwartz will testify in ways that will be useful to Google.

The problem with Google's argument is that Oracle's and previously Sun's decision not to sue Apache for the time being doesn't constitute a grant of a license. Other companies in the industry also treat the infringement of intellectual property rights by certain open source projects with benign neglect as long as they don't see any negative commercial impact. It's the prerogative of right holders to decide whom to sue and when.

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

Follow @FOSSpatents

Share with other professionals via LinkedIn:

Last week, Google's hopes of settling Oracle's Java patent suit on sweet terms were dealt important blows on two fronts.

One part of the bad news for Google is that a Federal Circuit ruling indicates software patents still can't be invalidated categorically on the grounds of "abstract" subject matter, a defense Google's answer to Oracle's amended complaint emphasized rather aggressively.

The other key development is the Apache Software Foundation's divorce from the Oracle-led Java Community Process (the Java standard-setting process). It's time to forget about possible concessions by Oracle to the open source community from which Google could indirectly benefit (since its Dalvik virtual machine is derived from a part of Apache's Harmony project).

Before I go into more detail on those latest developments, I'd like to reiterate an observation I already shared last month: unlike the other defendants in major smartphone patent cases, Google still hasn't countersued Oracle for infringement. Meanwhile, four months have passed since Oracle's lawsuit. Other defendants struck back within about two months, in some cases within one month. It's ever less likely that Google will do so. I guess it just can't.

All of this doesn't bode too well for Google and its Android mobile operating system.

101 isn't Google's lucky number

The number 101 connects Google and Oracle in two different ways. From the Googleplex in Mountain View, the fastest route to Oracle (Redwood Shores) is to take Highway 101 North. But § 101 of US patent law (35 U.S.C.) isn't the fast track to the invalidation of Oracle's Java patents that Google would like it to be, or that it would like the open source community to believe that it is.

I pointed out in a previous post that I couldn't see much of a point in Google's "abstract subject matter" defense (which it redundantly repeated), other than pandering to impressionable parts of the open source community who may be led to believe Google fights against software patents in general.

There are a few notorious disinformers out there who portray the US Supreme Court's Bilski opinion as the (potential or actual) beginning of the end for software patents. Contrary to what those propagandists claim (I doubt they even believe it themselves), that ruling (handed in June 2010) didn't do anything to turn US software patents into an endangered species. It was a decision in favor of continuity and a patent system that expands as technology evolves.

Google makes an unambiguous reference to the "abstract [...] subject matter" part of Bilski but there's no particular reason to assume that Oracle's Java patents would be non-statutory on that basis, or that such a defense would be stronger post-Bilski than it used to be pre-Bilski.

To me, the fact that Bilski didn't move the goalposts was immediately clear. I've spent a lot of time discussing substantive patent law with politicians and experts, so I can tell when a position on patent-eligible subject matter is liberal (such as Bilski) or restrictive. Steven J. Vaughan-Nichols, a markedly open-source-friendly journalist, viewed its impact essentially the same way. Bradley Kuhn, a leading free software activist, stated on this blog that "[p]ost-Bilski, it's become obvious that software patents can only be ended with legislative change." That's similar to what I had written in another follow-up to Bilski.

But anyone who believed those dreamers and disinformers instead of the more realistic and honest assessments I just mentioned would now have to grant me that I was right. The first ruling on a § 101 defense against software patents by the Federal Circuit (that's the instance right below the Supreme Court) since Bilski undoubtedly proves that software technologies continue to be patentable in the US subject to the same criteria as before.

CAFC decision on RCT v. Microsoft interprets Bilski

The United States Court of Appeals for the Federal Circuit (CAFC) heard an appeal in Research Corporation Technologies [RCT] vs. Microsoft, a case related to digital image halftoning (a set of techniques for improving display and print quality). Last Wednesday (08 December 2010), the CAFC announced its decision, a part of which disagreed with a district court's finding that "the asserted claims of [two of RCT's] patents were invalid under 35 U.S.C. § 101".

I haven't formed an opinion as to those particular patents. When I read the ruling, I was just interested in what principles it establishes for the patent-eligibility of software in general.

The CAFC points out that inventions are patent-eligigble unless expressly excluded from patentability by Congress:

Therefore, the Supreme Court has "more than once cautioned that courts ‘should not read into the patent laws limitations and conditions which the legislature has not expressed.’" Diehr, 450 U.S. at 182 (quoting Chakrabarty, 447 U.S. at 308). The Supreme Court has articulated only three exceptions to the Patent Act’s broad patent-eligibility principles: “laws of nature, physical phenomena, and abstract ideas.” Chakrabarty, 447 U.S. at 309.

The first part of that was also cited in the Bilski opinion, and what I quoted from Brad Kuhn is exactly what it means: if you want to do away with software patents, talk to politicians, not to judges. Of the three exceptions stated in the second part of the above quote, the first two are irrelevant to software patent issues and only the last one -- "abstract ideas" -- might play a role in a case like RCT v. Microsoft, or Oracle v. Google for that matter.

The CAFC then notes that the Supreme Court threw out its more restrictive approach to the Bilski patent application:

Indeed, the Supreme Court re-cently emphasized this statutory framework and faulted this court’s “machine or transformation” test for eligibility as nonstatutory. Bilski, 130 S. Ct. at 3227.

Therefore, the CAFC "perceives nothing abstract in the subject matter of the processes claimed in the [relevant] patents" and states that "[t]he invention presents functional and palpable applications in the field of computer technology."

That's the difference between patenting a mathematical algorithm and patenting a way to apply such an algorithm. Those who claim that software is mathematics and therefore too abstract to be patented don't take into consideration that such patents may be infringed by software that implements certain algorithms, but that is intellectually different from monopolizing mathematics per se:

These algorithms and formulas, even though admittedly a significant part of the claimed combination, do not bring this invention even close to abstractness that would override the statutory categories and context. The Supreme Court has already made abundantly clear that inventions incorporating and relying upon even "a well known mathematical equation" do not lose eligibility because "several steps of the process [use that] mathematical equation." Diehr, 450 U.S. at 185.

Again, I can't comment on those RCT patents, but I have looked at the patents Oracle asserts against Google and in my opinion, those Java patents aren't any more abstract than RCT's patents or, for example, all of the Google patents I've seen so far. Digital imaging is an operation performed by a computer processor on data stored in memory, possibly a storage device. Those Java patents involve the same hardware components except that they don't make explicit reference to output devices. However, one could also implement digital halftoning in Java, which shows that there isn't an obvious way to draw a line in the sand between RCT's and Oracle's patents.

In its attempt to take down Oracle's Java patents, Google will have to look for other arguments (such as prior art) than the subject matter defense it stressed so prominently in its recent court filing.

Apache's divorce from Oracle's Java Community Process is final

Probably knowing that it's very unlikely to do away with all Oracle patents and to prove that it doesn't infringe the valid ones, Google has strongly played the open source Java card in its public reaction to Oracle's patent infringement suit as well as the answers it filed with the court. Google would like the court to conclude that Oracle's open source commitments related to Java allow Google to use those patents anyway.

I can't see a convincing theory for that, but what's obvious is that Google hopes to put pressure on Oracle via the open source community.

Even if that wouldn't ever change the legal facts concerning what Google has done so far, Google may hope that under enough public pressure Oracle would be more likely to let Google carry on with its Dalvik virtual machine. I said before (at the end of this post) that I believe Google is barking up the wrong tree by trying to pressure Oracle on that basis. Oracle's support for open source and "open standards" ends where its business interests begin. That impression was just affirmed three weeks ago when I listened to Oracle's VP for Standards Strategy and Architecture, Don Deutsch, at a standardization conference.

Google might have hoped that Oracle would grant a Java license to the Apache Software Foundation's Harmony project. Since Google's Dalvik virtual machine is derived from a part of the Harmony code, Google would have been, potentially, an indirect beneficiary of such a license. This was like the reverse concept of having a carpet pulled off from under one's feet. Google hoped to have a missing carpet inserted under its feet and gain a legal advantage at least with a view to the future. But as I expected, Oracle stands firm.

On Thursday (09 December 2010) the ASF announced its resignation from the JCP Executive Committee -- the steering body of the Java standards-setting process. Over a disagreement as to whether Oracle had legal obligations to grant a certain Java-related license to the Harmony project, the ASF wanted to (at least temporarily) block all further progress concerning Java. But only Apache, Google and an individual member named Tim Peierls voted that way, while eWEEK reported that six members voted unconditionally in favor of Oracle's proposal (HP, Ericsson, Fujitsu, VMware, Intel, and Oracle itself) and six other members (SAP, IBM, Eclipse, Red Hat, Credit Suisse, Werner Keil) disliked licensing restrictions but voted for Oracle.

I read a rumor on the Internet that Red Hat was actively discouraging other members from a vote that would amount to "shilling for Google". A statement Red Hat gave to internetnews.com certainly indicates the Linux distributor's allegiance to Oracle. That's not suprising since IBM supports Oracle, and Red Hat follows IBM on pretty much every occasion.

The Apache Software Foundation risks getting sued

After Apache and Google lost the vote, TheRegister already expected the ASF's resignation. Oracle didn't seem to be surprised either. Its call on the ASF to "reconsider its position" doesn't mean that Oracle holds out rosy prospects to Apache and Google: it just shows that Oracle believes that the ASF will sooner or later have to yield and live with the fact that Oracle wants to retain some control over the licensing of Java and, particularly, Java-related patents. It's not an offer to hold peace talks and work out a compromise. It means that the ASF can have peace only on Oracle's terms.

If Apache doesn't accept Oracle's terms, I wouldn't rule out the possibility of Oracle suing the ASF over its Harmony project at some point. Doing so would merely be consistent with Oracle's infringement suit against Google. Right now, Oracle puts on a friendly face, seemingly extending an olive branch. But who knows for how long. At some point Oracle may conclude that the ASF will continue its collision course forever unless Oracle asserts its rights.

These circumstances limit the options Google would have should it be found to infringe Oracle's patents. The indirect Apache road to salvation appears to be blocked for the foreseeable future. Replacing Dalvik with another infringing technology wouldn't make sense either. However, most (if not all) Android applications have been written in Java, and Google must find a way forward for its third-party app developers. It can't just tell them that all of their applications can no longer be legally executed on Android and that they'd have to rewrite them with a completely different development system.

The GPL avenue wouldn't work either. While Google could theoretically take Oracle's GPL'd Java code (OpenJDK and/or parts of phoneME) and build some new GPL'd software capable of executing existing Android apps, it has clearly been Google's approach so far to eschew the GPL and its "copyleft" principle according to which anything derived from or incorporating GPL'd code must be GPL'd as well.

If Google had to do that, it might help its app developers temporarily but at the expense of creating major complications for the business strategies of its key partners among device makers. Those strategies are centered around closed-source, proprietary extensions to Android, which effectively make the platform "open in name only".

This is Google's dilemma: it has to work out things with Oracle in a way that Android app developers and Android device makers can live with. If Oracle's legal position is indeed very strong, if Oracle's intentions are about control as opposed to just money and if Google continues to be unable to countersue for infringement of any of its own patents, then there may be no solution that averts devastating damage to the Android ecosystem.

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.

Share with other professionals via LinkedIn:

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.

Later today, the Supreme Court of the United States (SCOTUS) will most probably publish its long-awaited opinion in re Bilski, a decision that appears to relate to a business method patent but could also become the first landmark SCOTUS ruling on software patents in a long time.

A fellow activist recently pointed me to an outrageous document: In an effort to dissuade the SCOTUS from imposing restrictions on software patentability, IBM tells the court the blatant lie that software patents have made open source popular.

Even worse, IBM describes software patents as a liberating factor, making mockery of the whole software freedom movement founded and spearheaded by Richard Stallman. RMS has always opposed software patents. He travels the world to fight them (a speech he gave at a demonstration in Munich last year is on YouTube: part 1, part 2). But IBM shamelessly claims that it took software patents to liberate software developers and make Stallman's idea fly.

In a footnote on page 25 of its amicus curiae brief (submission to the court) in the Bilski case, IBM makes the following claim that is not only the exact opposite of the truth but also shows the ruthless and cynical enemy of open source that IBM is in the patent context:

"Patent protection has promoted the free sharing of source code on a patentee’s terms---which has fueled the explosive growth of open source software development."

I read this again and again, and I find it nothing short of appalling. This is absolutely in contradiction to the GPL, the Apache Software License and the spirit and the letter of other FOSS licenses.

The worst lie ever in the software patent debate

The absurd assertion that patents -- the most fundamental threat to software freedom -- promote "the free sharing of source code" and therefore open-source development is the most preposterous argument in favor of software patents that I've ever heard. And I've heard many, including many stupid ones, in countless debates in which I participated over the years. But this one is in a class of its own, in a negative sense.

Let me speak from my experience as a participant in so many public debates on software patents as well as private conversations with politicians and their advisers.

Those who advocate software patents will say a lot of things that are factually wrong just to get their way. During the legislative process concerning the EU software patent directive, the strategy of the pro-patent camp was to flatly deny that the law was about software patents. They claimed they just needed the law to make computer-controlled devices such as automatic transmission systems or new generations of washing machines work. The NoSoftwarePatents campaign, which I founded and managed until 2005, called this "the mother of all lies."

Another lie was to claim that the proposal would have restricted the European Patent Office in its practice of granting software patents. OpenForum Europe, a lobby organization whose biggest and most influential member is IBM, was among those spreading that message, falsely claiming to represent the open source community.

Many debates never got to the point of whether or not software should be patentable because it took so long to dismantle those lies about the legal meaning of the proposal that there usually wasn't any time left for the fundamental question of what's best to incentivize innovation.

The lesser evil: denying negative impact

When we had the chance to discuss the heart of the issue, we also saw many claims that FOSS could prosper under a software patent regime. Those claims were meant to alleviate concerns of FOSS-friendly politicians, almost all of whom opposed software patents. As part of that political strategy, IBM made its original "open source patent pledge" in January 2005. They wanted to lull politicians as well as the FOSS community into a false sense of security. This was in their interest with a view to the European process, so the timing wasn't a coincidence. Of course, their interests concerning the open source community go beyond Europe.

This ZDNet article, published on the day of the announcement of the pledge, quotes me as calling IBM's 500-patent pledge an act of hypocrisy because they were actively lobbying for software patents in Europe. I was fighting their lawyers and lobbyists all the time, and I told the ZDNet reporter who then called up politicians to double-check.

Mark MacGann, then the chief executive and lobbyist of a big IT industry association (with IBM among its members), is quoted in that article with his spin, calling IBM's pledge "a strong example of the compatibility of computer-implemented invention (CII) patents with the OSS development model." I haven't talked to him in several years, but next time I see him, I'll ask him what he thinks of IBM's betrayal of the pledge.

Still, it's the lesser evil if someone just denies that there's a negative impact and grossly overstates the benefit of pledges. What IBM does in its Bilski brief is much worse: IBM attributes the rise of free and open source software to the liberating effect of software patents, which is not just wrong but turns the facts upside down.

Right or wrong, it serves their purposes. I can only hope that the judges figured it out.

IBM probably tells the same story around the globe

IBM recently also lobbied for software patents in New Zealand, where the abolition of software patents was a political possibility but it seems that a trend reversal has occurred, with IBM and Microsoft advocating software patents. I don't know what exactly they said. New Zealand is antipodal to where I live, and I don't have any contacts there. Presumably, IBM will have made pretty much the same points as in its Bilski brief.

I don't deny companies their right to push for software patents, just like I have the right to oppose them. That's democracy, but there's a right way and a wrong way to make the case. Mockery of freedom is simply unacceptable.

I don't know how IBM discusses software freedom internally. I guess it's similar to the attitude of CNN reporter Rick Sanchez:

"What, what the hell does that mean, freedom? The biggest tent is freedom? Freedom?! I mean you gotta do better than that."

Whatever freedom may mean, Messrs. Sanchez and Sutor, software patents aren't part of it.

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.