Qualcomm restructures company due to concerns over impact of open source licenses on 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:

Share|

FOSS can implement patented standards

Anti-IP extremists and self-serving hypocrites do the cause of free and open source software a disservice with incorrect claims about the use of patented standards in FOSS projects. They say such patents must be made available by their holders on a royalty-free and, more broadly speaking, generally restriction-free basis in order to be compatible with FOSS licenses, especially the GPL. That's simply not true.

Not only is it untrue, and disingenuous. I also consider it dangerous. Software patents are a fact of life. Their abolition isn't achievable. Since there are countless software patents covering a huge number of technologies and functionalities, FOSS must find ways to deal with patents, and in fact, it already has. In particular, it must continue to find constructive and realistic ways rather than just insist that patent holders waive all rights, which isn't going to work with all right holders.

If such extremism were the only way, Linux and other important free and open source software would sooner or later be unusable in most of the industrialized world, which is increasingly mixed-source.

If the FOSS side and the patent side are both reasonable, the combination of both works without problems. If some FOSS people act unreasonably, they can certainly make their projects largely irreconcilable with patents (such as by using the highly political and unpopular GPLv3). That's self-inflicted damage of a kind that no responsible decision-maker can support. Conversely, if patent holders try to use intellectual property rights to foreclose FOSS-based competition (such as IBM against TurboHercules), that's also a big problem. But if patents are contributed to a standard on fair, reasonable and non-discriminatory (FRAND) terms, everything's fine.

My mobile phone stands as proof

I recently bought a Samsung Galaxy S i9000 smartphone. It's powered by Android, which is based on Linux, the most important piece of software available under the GPL. Samsung is known to pay patent royalties on those devices, just like its major competitors (such as HTC and LG).

I wish they'd all oppose those patents politically, but even if they did and at some point succeeded, we'd still need a solution for today's framework. And that solution is called licensing. More specifically, what's needed is licensing on FRAND terms.

Linux was the first example. Here's the second: most if not all of the applications for my phone are written in the Java programming language. That one is effectively controlled by a single vendor, Oracle (since it acquired Sun, the original cradle of Java). Java is a de facto standard. Oracle provides different pieces of Java software under the GPL. But the Java patent license is among the most restrictive ones in the industry.

The fact that no free software organization or other entity sues Oracle over this (instead, Oracle itself is suing Google in a different Java-related context) shows that patented standards aren't at odds with the GPL.

More on the Java patent license

On Wednesday, the so-called European Committee for Interoperable Systems (ECIS) published a rather aggressive statement on the European Interoperability Framework (EIF), a set of EU procurement guidelines.

Oracle is a member of ECIS, but even more importantly, Thomas Vinje, Oracle's outside counsel for EU antitrust matters, is ECIS' spokesman and lawyer. If I were an EU official or a journalist and if he were telling me about how open source needs royalty-free and generally restriction-free access to patents on standards, I would ask him: "Mr. Vinje, can the Java standard be implemented freely under the GPL by anyone, even if none of Oracle's own GPL'd code is used for this?"

I would point him to reports like this one, according to which Oracle refuses to grant a Java patent license to one of the most important open source foundations.

Should he -- contrary to all the evidence -- answer with Yes, I'd ask him to show me the patent license that would allow this, and as I write these lines, he wouldn't be able to present anything like that. The patent license contained in the Java specifications is very restrictive, even if royalty-free. The GPL generally refers to "conditions" and "obligations" related to patents. It mentions royalties merely as an example of a patent-related condition/obligation.

I can't imagine that Thomas Vinje (again, he's Oracle's outside counsel for EU antitrust matters) would want Java to be excluded from use by European governments under the terms of the EIF. So other patent holders should have the same flexibility to reserve certain rights, as long as they do so on a FRAND basis.

A look at different FOSS licenses

Different FOSS licenses address the subject of patents in different ways. It's important to make the dinstiction between rules governing the patents belonging to a contributor to (or distributor of) a FOSS project and rules concerning patents licensed from third parties. FOSS licenses take different approaches to those scenarios. For the most part, licensing patents from third parties doesn't represent any problem.

GPLv2

GPLv2 doesn't contain an explicit patent grant. There's only an implicit one. I've explained the limitations of that implicit patent license in this posting. Basically, if someone publishes software under GPLv2, such as Oracle with some of its Java software, everyone using that software without modifications is pretty safe from patent infringement assertions. But once the code is altered, it's better not to rely on the implicit license.

The foregoing relates to patents held by someone who publishes code under the GPLv2. The other scenario addressed by the GPLv2 is the one that really matters in connection with patented standards: the distribution of GPL'd code by someone who obtains a patent license from a third party.

The GPLv2's preamble claims that a patent must be licensed for everyone's free use on GPL terms or not at all. Nevertheless, in 2006 Novell announced a partnership with Microsoft, with one of its effects being "that customers deploying technologies from Novell and Microsoft no longer have to fear about possible lawsuits or potential patent infringement from either company."

There was some criticism by free software extremists, and there were also questions by some very reasonable people, but four years later, no one has made a legal claim that this constituted a violation of GPLv2. The language in the GPLv2 doesn't disallow all ways in which one can satisfy the requirements of a patent holder.

Meanwhile, such companies as Amazon.com, Salesforce.com and TomTom have agreed to pay royalties for using patents that (according to my interpretation of the announcements) included patents that read on Linux. No one has formally accused those companies of GPLv2 violations either. I gave more examples further above (where I contemplated my Android-based Samsung smartphone). And I could talk about Red Hat's payments of patent royalties (which I may write about in more detail some other time).

GPLv3

When free software radicals saw how pragmatically some major open source distributors dealt with patent licensing, they chose the path of defiance: the GPLv3, as mentioned further above. While they were drafting that one, they saw the Microsoft-Novell partnership. Not only was that partnership possible under GPLv2: even the first drafts of GPLv3 wouldn't have disallowed it. Here's what Richard Stallman said in 2006:

It turns out that perhaps it’s a good thing that Microsoft did this now, because we discovered that the text we had written for GPL version 3 would not have blocked this, but it’s not too late and we’re going to make sure that when GPL version 3 really comes out it will block such deals. We were already concerned about possibilities like this [...]

So if the inventor of the GPL admits that even the early drafts of GPLv3 didn't block inbound patent licensing (even though this was the single biggest reason for which the FSF started the GPLv3 process in the first place), how can anyone reasonably claim that it isn't possible with GPLv2?

GPLv3 ultimately became very restrictive, but as a result, it's a big-time failure. No major open source project (such as Linux) has embraced it. So when I say "GPL", I usually mean the GPLv2 because that's the only version of the GPL that's relevant in the real world.

Apache Software License 2.0

The Apache Software License 2.0 (ASL) contains, in its Article 3, an explicit patent license. It has an interesting defense mechanism where someone instigating litigation over an alleged patent infringement automatically becomes exposed to possible counterclaims by other patent holders who contributed to the same ASL'd project. The patent grant itself is limited to the patents someone may hold on their contributions to a project and the license contains no restrictions or prohibitions (like the GPLv3) on the terms of a third party patent license. Therefore, someone can implement a standard patented by other parties and work out a license with them without having to take care of the entire ecosystem. That's reasonable.

BSD licenses

There's a very popular family of FOSS licenses called the Berkeley Software Distribution (BSD) licenses. Those are rather short and simple. They don't even mention the word "patent". As a result, there's no problem with implementing patented standards. If someone publishing software on such terms holds any patents that read on their code, there's an implicit license grant. If someone licenses patents from third parties, there's nothing in a standard BSD license that would prevent the implementation of such a standard.

European Union Public License v1.1

The European Union Public License v1.1 (EUPL) was published in 2007 and should be a logical choice for European governmental bodies (at the EU level as well as in the Member States) for publishing software on FOSS terms. The idea of governments sharing their development efforts on FOSS terms is a great one: if taxpayers fund development in one place, taxpayers in another shouldn't have to pay again (except for specific adaptations that may be needed).

The EUPL contains an explicit patent license as far as the patents of someone publishing code under it are concerned. It doesn't contain any clause that would prohibit the implementation of patented standards if those patents are held by third parties.

In its FAQ on the EUPL, the European Open Source Observatory and Repository (OSOR) states that "when public administrations are using or distributing their own specific software under the EUPL, the risk from legal action related to patent infringement, while not zero, is very low." This relates to a scenario where a patent holder would claim an infringement. The EUPL per se doesn't prohibit the use of third-party patents.

MXM license

It is even possible to define an open source license that limits its scope only to the copyright aspects of the program code distributed under it without explicitly or implicitly restraining code contributors or distributors from enforcing their patent-based rights.

For a working group of the MPEG multimedia audio/video codec consortium, Carlo Piana, an Italian FOSS lawyer who also advises the Free Software Foundation Europe and counts Oracle among his recent clients, designed a license that was based on the Mozilla Public License (Mozilla is the foundation behind Firefox and other free software) but with a carve-out for patents. The new license was called the MXM license.

In this blog posting, Carlo explained his motivation. He pointed out that his actions shouldn't be confused for an FSFE effort. He knew this was going to be controversial in open source circles where software patents are a red flag. His justification nevertheless stresses that (in other words) political opposition to software patents is one thing and trying to find a way for patent holders to publish and distribute open source software is another. That distinction between ideology and pragmatism is key.

The MXM license goes way beyond what's needed to implement standards patented by third parties. Compared to what it does, licensing patents from third parties is child's play.

Summary of different licenses with a view to custom software developed by/for governments

For governmental bodies seeking to develop (or to have subcontractors develop) custom software on open source terms, there's no shortage of appropriate licenses that can handle patented standards.

Apart from the GPLv3, which is inherently incompatible with patented standards because it was purposely designed that way, almost any other FOSS license will work. Such licenses as the European Union Public License and the wildely popular Apache license and BSD licenses don't create any problems for those who implement third-party patents.

Even the GPLv2 is, contrary to what some people claim, not incompatible with the notion of third-party patents. Numerous companies using and distributing software under the GPLv2 have made arrangements with patent holders, including that they have accepted to pay royalties, and to date I'm not aware of any of them having experienced any problem because of that.

This is actually good news for FOSS. If it couldn't deal with such patents, it would be strategically lost.

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.

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.