Leading items

GCC, LLVM, and compiler plugins

GCC, the GNU Compiler Collection, is a cornerstone of the GNU project and the larger free-software community that has grown up around it. Recently a debate sprang up on the GCC mailing list over the question of whether GCC ought to deliberately adopt a development approach more like that of rival compiler LLVM. Precisely which aspects of LLVM's approach were desirable for adoption depends on who one asked, but the main argument was that LLVM seems to be attracting more users. The GCC project, however, contends that LLVM's perceived popularity is due largely to its accommodation of proprietary extensions—which is something that GCC supporters consider decidedly contrary to their core objectives.

Few would consider it a stretch to say that GCC has grown to dominate the compiler landscape over the course of its 26-plus years as a project, to the point where its popularity extends beyond free-software circles, and it is even routinely used to compile proprietary code—a scenario that is ripe for bringing interests other than software freedom into development discussions. In recent years, though, newer compiler projects have made names for themselves, LLVM being the most famous at present.

LLVM started off as a research project at the University of Illinois at Urbana–Champaign; befitting the needs of researchers, it has been developed in a modular form that allows easy replacement of individual components: front ends, code generators, optimizers, and so on. It was also released under the University of Illinois Open Source License, which is a permissive, BSD-style license that requires copyright attribution but permits the code to be used in proprietary applications. And indeed there are multiple proprietary compilers and utilities built on top of LLVM—including Apple's Xcode and NVIDIA's CUDA compiler.

For whom the bell clangs

The present debate was touched off by a comment from Dmitry Gutov on the emacs-devel list on January 19. In the midst of a discussion about Emacs's company-mode auto-completion framework (specifically, a minor mode designed to work with the LLVM front end Clang), Gutov said that he had heard Richard Stallman disliked Clang so much that he would oppose importing any code from it into Emacs. That spawned a lengthy thread about Clang/LLVM and GCC's differing approaches to software freedom—in particular, about the merits of copyleft licensing.

The various sides of that debate have all been argued many times in the past, of course, and this incarnation of the topic did not break any real new ground. Stallman's position, in short, is that Emacs and other official GNU applications should not incorporate default features designed to work with non-GNU projects (like LLVM) that do not work with the corresponding GNU project (GCC).

The debate was revived on January 21, however, when Eric S. Raymond contended that the very existence of Clang/LLVM was a response to the GCC project's resistance to broad interoperability. The Clang developers, he said, "want to build IDEs and other tools that share the compiler's code. GCC policy won't let them do that. Ergo, GCC must be kicked aside." Raymond also argued that LLVM bests GCC on several technical measures, a claim that was rapidly met with disagreement and, for the most part, dropped.

But the original point remained the subject of the resulting list thread (and several overlapping threads, some of which were cross-posted to the GCC development list). Essentially, Raymond argued that LLVM's modularity is a strong selling point among users that GCC cannot match. Whatever one thinks of the relative quality of LLVM and GCC, LLVM is clearly a capable enough compiler that GCC should be worried about losing market share (so to speak) to it among users. The solution, Raymond said, was for GCC developers to abandon their monolithic architecture and adopt a modular compiler design like LLVM's.

The mod squad

Modularity, though, is not a simple design question where compilers are concerned. As several in the discussion pointed out, it is actually LLVM's modularity combined with its non-copyleft license that makes it attractive to many proprietary software companies. Apple, NVIDIA, and other downstream LLVM users build their proprietary IDEs on LLVM—at least partly—because they do not want to be bound by the GPL's copyleft requirements. As David Edelsohn said, "The issue for companies is control: which compiler allows them better access / control over the toolchain control point of the ecosystem and which allows them to create a walled garden to improve their margins and their business model."

In essence, asking GCC to be "more like LLVM" is not a matter of modularity alone, but of making it possible to use GCC with proprietary add-ons or extensions. And although (as Joseph Myers pointed out) GCC is more modular than it used to be (with more such refactoring work on the to-do list), GCC's developers have actively resisted allowing it to be modularized in a way that would allow GCC's internal representation of a program to be read and used by proprietary compilation tools or optimizers. Stallman even reiterated this point in the current thread. GCC's present plugin system debuted with GCC 4.5.0 in 2010, but the project was keen to ensure that it does not offer a "black box" API to its internal representation.

Still, it has never been possible to fully prevent others from hacking together their own plugins, which in turn has led to some unusual licensing moves by the project. Early on, the GCC team made the decision that GCC should be able to compile proprietary code (a choice which was certainly not a given, since that could be construed as "promoting" proprietary software). The question came up due to the different nature of compilers when compared to "regular" programs. Certainly nothing in the GPL itself prevents using GPL-licensed software to work on proprietary software.

But GCC adds its own runtime library to the object code that it produces, which creates the first dilemma. Strictly speaking, this linking of the GCC runtime library would make any program compiled by GCC a derivative of GCC, which in turn means it would inherit GCC's GPL license. The solution to that problem was the GCC Runtime Library Exception, which explicitly exempts this situation and allows GCC-compiled programs to be released under whatever license the program authors would otherwise choose.

In 2009, the GCC project released an updated version of the exception designed to specifically address the second problem—what to do about proprietary GCC plugins. The exception discourages them by explicitly allowing user to distribute a GCC-generated binary under a proprietary license only if no proprietary plugins were used to compile the binary.

Thus, the GCC Runtime Library Exception leverages the GPL to discourage the use of GCC in conjunction with proprietary add-ons. But there are not that many GCC plugins to begin with, since (as Ian Lance Taylor explained), the plugin interface "simply exposes GCC internals, and as such is not stable across releases". Others have argued that the unstable interface acts like an effective deterrent to those attempting to maintain out-of-tree patch sets as well, though it has the unfortunate side effect of making it difficult to write free GCC plugins, too.

Fight club

Whatever one thinks about the peculiar requirements that the runtime library exception sets up, it is undeniable that the GCC team is not interested in supporting the permissive approach taken by LLVM. Stallman made this point when he replied that allowing non-free plugins "would be throwing in the towel. If that enables GCC to 'win', the victory would be hollow, because it would not be a victory for what really matters: users' freedom."

Then again, there is considerable disagreement over what "winning" really means for GCC, and even over whether LLVM and other compilers are in a competition with GCC. Raymond and others pushing for a more LLVM-like approach argue that LLVM will attract more users than GCC. That is certainly a simple metric, but to many it is not a relevant one. Jonathan Wakely commented that Raymond thinks he is "helping us win a war with Clang. But there is no war. There's room for two high-quality open source compilers. They will distinguish themselves in different ways, one of which is licensing."

Perhaps the more extreme viewpoint would be that GCC faces an existential threat from LLVM. Along those lines was Daniel Colascione's comment that "Free software is great, but if nobody uses it, the entire enterprise is futile, sad, and ultimately irrelevant." To that, Stallman responded, "Free software is equally futile, sad, and irrelevant if everyone uses it...as a base for nonfree software."

Ultimately, all parties to the debate said that they are interested in seeing the number of GCC users increase. The root of the "competition" disagreement tended to come down to whether the GCC team's plugin policy amounts a barrier to attracting new users. Helmut Eller called it a "policy of introducing artificial technical hurdles to prevent some nonfree programs" and caused collateral damage. David Kastrup replied that "the whole point of the GPL is to introduce an 'artificial hurdle' preventing turning code into proprietary programs", and, significantly, it is a hurdle that works, as the absence on proprietary compilers built on top of GCC demonstrates.

There will likely always be people for whom the proprietary derivatives of a permissively-licensed program like LLVM are a problem, and there will be others who do not care about them, so long as free software exists, too. Similarly, to some people, if LLVM attracts more users than GCC, it must reveal that GCC is flawed, while to others the relative numbers are meaningless.

On the more concrete questions, however, the answers are considerably less nebulous. Stallman and the GCC team have made their position clear about adopting a lax attitude toward proprietary plugins in GCC: it is a non-starter. Whether that stance amounts to a fundamental flaw in GCC itself depends on the individual—but do not expect GCC to change its tune simply because LLVM has attracted its own crowd of users.

Comments (60 posted)

An update on Rockstar v. Google

In October 2013, Rockstar, a non-practicing patent-holding entity (or "patent troll"), launched multiple lawsuits against Android OEMs and Google alleging multiple counts of patent infringement. Over the last month, sparks have been flying in the fight between Rockstar and Google. We looked at the patents back in November. Now Google has responded with a motion for declaratory judgment. Google seeks — among other things — a declaration that it does not infringe the patents Rockstar is asserting against it.

Request to change venues

Google's motion is particularly interesting because of those "other things". Rockstar brought its lawsuits in the US District Court for the Eastern District of Texas (or E.D. Tex.). However, in its motion, Google asked to move the lawsuit to a different jurisdiction: the US District Court for the Northern District of California (or N.D. Cal.).

Google is taking advantage of federal procedural rules that allow parties to many types of legal disputes to bring a motion for declaratory judgment before any US court if there is an "actual controversy within its jurisdiction". This means Google has to convince the N.D. Cal judges reviewing its motion that Rockstar has been active in asserting its patents in the area N.D. Cal has jurisdiction over: namely, northern California. Google points to Rockstar's business activities as justification for a change of venue:

Google also claims that Apple, a Rockstar shareholder, coordinates with Rockstar from Cupertino, which is in the district.

Google has moved for declaratory judgment in N.D. Cal likely because E.D. Tex. is notorious for being plaintiff-friendly in patent infringement cases. In 2006, 88% of plaintiffs bringing patent lawsuits in E.D. Tex. won. Of the 25 highest damage awards given from February 1, 2005 to December 31, 2013 for patent infringement, twelve were from E.D. Tex, including the highest award of over $1.6 billion.

Even if Google's desire for declaratory judgment that it did not infringe is dismissed by the N.D. Cal., its judges may rule that it is nonetheless appropriate to transfer the case to its jurisdiction. Should Google succeed in having the lawsuit transferred to the other jurisdiction, that alone would significantly increase its chances of success in this litigation and reduce its chances of having to pay a high damage award should it lose. Google's desire to transfer jurisdictions can be explained through this statistical calculation; a familiar approach to solving problems for the advertising and search engine giant.

Other complaints

The motion is also interesting for two other reasons. Google implies that Rockstar is acting as a proxy for its organizers and shareholders; most notably, Apple: "Rockstar's shareholders direct and participate in Rockstar's licensing and enforcement efforts against companies in California. [...]Apple [...] is a large shareholder in closely-held Rockstar, and maintains a seat on Rookstar's board of directors. Rockstar's CEO has publicly stated that Rockstar maintains regular contact with its shareholders." (Paragraph 8). Being a proxy is not a bad thing (legally) on its face, but this argument is a way for Google to claim that it's really fighting Apple, so the dispute should be settled on Apple's turf — in California.

Google also complains about the lawsuits against the Android OEMs, which it is not party to: "Rockstar intends the Android OEM Actions to harm Google's Android platform and disrupt Google's relationships with the Android OEM Defendants. This is an open secret [...]." (Paragraph 23) Google is, of course, affected by any OEMs who feel threatened by patent assertions on their use of Android. Most of the remainder of the motion is a wholesale denial of any infringement on Google's part of the asserted patents.

On December 31, Rockstar amended its complaint against Samsung to add Google as a defendant to the lawsuit in E.D. Tex. This is an interesting response to Google's motion; instead of addressing it directly, it fires the patents aimed at Samsung against Google as well, giving Google another set of patents it has to defend itself against. It's a procedural change to the lawsuit against Samsung solely meant to keep patent litigation against Google in the lucrative E.D. Tex. jurisdiction even if Google succeeds at getting the search patent infringement claims transferred to N.D. Cal.

While Google has not caved in on the jurisdictional issue with Rockstar's search patent infringement claims, it has decided to fight in E.D. Tex. while it awaits a decision from N.D. Cal. On January 10, Google formally responded in full to Rockstar's original complaint against it. In the 88-page response, "Google admits that venue is proper in the Eastern District of Texas for purposes of this particular action but not convenient or in the interests of justice" (Paragraph 10); that is, it is still hoping that N.D. Cal. will accept a transfer of the lawsuit.

After denying that it infringes, Google asserts a variety of different defenses, which would be generally claimed in this situation: that the patents are invalid for non-patentability, lack of novelty, obviousness, and because of written deficiencies in the patent text; that there are limitations on how much in damages Google would have to pay out; prosecution history estoppel; estoppel; and unclean hands. Prosecution history estoppel means that Google is alleging that Rockstar's search patents were the result of a revision and narrowing of rejected patent applications by the Patent and Trademark Office; if this is true, it means that Rockstar can only assert a narrow, and therefore weaker, interpretation of the patents against Google. The plain "estoppel" claim implies that Rockstar had behaved in such a way as to cause Google to believe it would not sue for infringement of the relevant patents.

The most interesting defense, though, is the last one: a claim of inequitable conduct on the part of the original inventors, the original patent attorneys, and anyone else who failed to make certain disclosures that they were required to to the United States Patent and Trademark Office (USPTO). Google alleges that the inventors were aware of prior art that made the search patents ineligible for patentability, and deliberately decided not to disclose them to the USPTO so they would be awarded the patents.

Google also alleges that the inventors and prosecuting attorneys lied about the workings of other relevant prior art, namely, the Open Text search engine. Google claims that, had the USPTO been properly informed about Open Text, the patents would not have issued. Since this was inequitable conduct, the patents cannot be enforced. For example, with regards to the '969 Patent:

Much more to come

These activities are the latest in what will very likely be long, drawn-out litigation in the plaintiff-friendly Eastern District of Texas. Indeed, the detail of Google's January 10 response indicates that Rockstar has taken on a huge fight. However, should Rockstar be successful at trial or at getting a substantial and/or confidential settlement, it might send shocks through the IT industry, leading lawyers for other companies to be more amenable to paying Rockstar for patent licenses. Rockstar may be making some progress as Huawei appears to have already settled with the company, as there is a joint motion to dismiss Rockstar's lawsuit against Huawei. That kind of outcome seems unlikely for Google, at least, so stay tuned for lots more battles and skirmishes in this legal war.

Comments (7 posted)

This week in "As the Technical Committee Turns"

On January 25, Bdale Garbee, the chair of the Debian Technical Committee, called for votes on a proposal to resolve the debate. In a surprising plot turn, the item to be voted on was not the extensive, detailed ballot that had been developed over several preceding episodes. Instead, as if the whole thing had been a dream, Bdale put forward a simple ballot picking a default init system, but only for the upcoming "jessie" release, and only for the Linux-based version of Debian at that. As the trailing credits began to roll, committee member Russ Allbery cast his vote, listing systemd as his first choice.

Bdale was seemingly hoping to make some progress in the discussion by answering something smaller than the original question. Had the vote gone as intended, that may well have been the result. There would have been plenty of details yet to be worked out by the committee, but there would have at least been some understanding of the general direction in which things were going.

Unfortunately, the next day's episode began with an impassioned outburst from Ian Jackson, who described himself as "really quite upset by this". Ian was unhappy that the ballot had been developed without any input from the rest of the committee. He pointed out that the ballot lacked language allowing the result to be overturned by a simple majority on a general resolution, but he clearly had other problems with it as well. Raising the emotional temperature, he voted for "further discussion," followed by sysvinit as the highest preference — and systemd as the lowest, below OpenRC. Bdale agreed that the general resolution language should have been present, but added that he wasn't sure how to end the vote at this time; this episode's cliffhanger ending had the entire committee wondering if a ballot that nobody wanted anymore would have to run to its conclusion anyway.

The tension was resolved the next morning, when several committee members had voted for "further discussion," and Debian project secretary agreed that the outcome was not in doubt. So that particular vote concluded with nothing changed, and nothing resolved.

According to the trailers for upcoming episodes, another ballot can be expected in the near future, but there may well be a surprising plot turn or two before that comes to pass. Ian has a proposal of his own that mandates support for sysvinit and prohibits any package from depending on a specific init implementation. It would, in other words, mandate something very close to the status quo, setting up the viewership for a rather tiresome series of reruns.

An alternative might be a form of Bdale's ballot with the general resolution text tacked on. No such ballot has been proposed, though, and Bdale has been relatively quiet since the end of the first vote. The possibility of him popping out of the woodwork with a new ballot after the commercial break cannot be entirely discounted, but it appears that, for now, the next scene is a close-up shot of Ian at center stage as he works on a slightly different approach.

As Ian now sees it, there are two fundamental questions to be answered beyond that of which system should be the default:

• Does Debian want to support multiple init systems indefinitely, or should the project eventually settle on one of them?

• Is it permissible for packages to depend on a specific init system?

With regard to the first question, it seems reasonably clear that the committee is not interested in trying to set the direction of the Debian project for many years into the future. If some new init system comes along that is far better than anything we have now, the project should have the flexibility to switch to it — and, besides, there need to be some open questions to provide drama for the next season.

Speaking of open questions: nothing has been posted to suggest that the basic 4:4 split of the committee between systemd and upstart has changed. So a ballot on the default init system still runs a high risk of coming down to a tie, which may or may not be resolved by the chair's casting vote. Making it easier to overrule the committee's decision via general resolution may well have the result of making a general resolution more likely to happen. So there is a good chance that this particular soap opera has a number of convoluted episodes yet to run. Cue the sappy music, sit back, and enjoy.

Comments (170 posted)