GCC debates project governance

When we last looked in on GCC, the 4.4 release branch was held up by licensing issues, specifically the exemption that would allow GCC plugins. Since that time, things have progressed—there is now a 4.4 release branch—but the license issue has not yet been completely resolved, though a new revision is available. But, since the license change is not needed for the 4.4 release, some GCC hackers are unhappy about the manner in which the release was held up. It has led to questions about the roles of the Free Software Foundation (FSF) and the GCC steering committee (SC) have in controlling GCC development.

Holding up a release for licensing concerns is seen by many as a reasonable request that the FSF might make. That organization is very concerned about licenses, in general, and they certainly think it is important to get the license right before releasing any code under the license. It is the concerns expressed by GCC developers about the wording of the runtime library exception that led to the license review. But Richard Stallman, acting for the FSF, did not ask that the release be delayed—at least directly—he asked that no release branch be created. The net effect on the release process is the same (i.e. no release), but the impact on development of new features destined for GCC 4.5 is a large part of what irked the GCC developers.

The other piece of the puzzle is that the issue is essentially moot: there is no plugin API in GCC 4.4 that would require the runtime library exemption changes. Stallman is adamant that proprietary GCC plugins be outlawed before such an API gets added. But, since the API isn't present (yet), the license changes aren't needed yet either. So, while it makes sense to take whatever time is required to get the license right, many seem very puzzled as to why that would need to hold up the release and new development.

There has never been a clear explanation of why the release branch needed to be delayed, at least publicly. Either Stallman relented—perhaps due to completing the license rewording—or the SC eventually decided to override his request because the release branch was created on March 27. But there was clear discontent in the ranks that the SC could, evidently, be pushed around so easily by the FSF. This led to questions about the role of the SC, how much control over "technical" decisions the FSF has, and, in general, how the project is governed. As Daniel Berlin put it: "Where is the pushback by the SC onto the FSF?"

Berlin's complaint was that it has taken the FSF too long to resolve the issue, to the point where it is now (and has been for a bit) seriously impacting GCC development. Because the license change is not required for this release, there is no good reason to delay it. Ian Taylor was fairly blunt:

In response to Berlin's criticism of their response, SC member David Edelsohn noted that there were things going on behind the scenes:

But a lack of communication from the SC to the greater GCC community is part of the problem, according to Berlin:

The discussion then turned to the role that the FSF plays in GCC development. SC member Joe Buck points out that the FSF holds the cards: "The problem in this instance is that the SC has little power; it's the FSF that's holding things up and I don't know more than you do." But that doesn't sit well with some. Steven Bosscher asks:

Others believe that the FSF should be in complete control. Richard Kenner outlines how he sees the relationship:

Berlin would like to see the governance structure for GCC more clearly spelled out. The SC web page seems to indicate that its role is to prevent the project from being controlled by any party. But whether the SC is supposed to prevent the FSF from controlling its own project was disputed. Ultimately, the developers do have some power as Buck states: "There are checks on FSF control in the sense that the project can be forked and developers can leave."

That kind of talk inevitably leads some to mention the egcs/GCC split, and subsequent join, as an example of the power that the development community has. No one has said they are seriously considering a fork, but the GPL certainly allows such things if the FSF's hand gets too heavy. Jeff Law doesn't see it coming to that:

Clearly some developers are chafing under what they see as unnecessary interference in technical issues from Stallman. But as Buck points out, Stallman does not dictate technical details to GCC. Various decisions (bugtracker, version control, etc.) have gone against his express wishes. In addition, contrary to Stallman's aversion to C++, Taylor has used that language for the gold linker, and currently has a branch that implements some of GCC in C++. He sees things this way:

This discussion will hopefully lead to a clearer picture of the governing structure of GCC. With luck, it may also make Stallman and the FSF more cognizant of the perception that they are meddling in technical issues to the detriment of their relationship with at least some in the community. No one in the rather long thread could come up with any sensible reason that the release branch should have been held up. At best, that means that Stallman didn't communicate the why, which leads many to a sense that he is being rather arbitrary.

In the meantime, though, GCC is preparing for the 4.4 release. Release manager Mark Mitchell created the release branch, Bosscher is rounding up folks to update the 4.4 changes page, and work is proceeding towards a release. That also allows the changes for 4.5 to be added to the trunk, which puts that release back on track.

With GCC 4.5 there will likely be a new plugin API for which the license change is needed. On April 1, Edelsohn announced that the revised runtime library exception had been released. It explicitly allows for Java byte code to be used as input into GCC, making a "compilation process" using that input eligible for the runtime library exception. One of the other concerns, regarding independent modules, will be addressed in the FAQ, though it has not been at the time of this writing.

Assuming the new exception passes muster on the gcc-devel list, and no problems are found that would require adjustments, it will presumably end up in the 4.4 release. While that should conclude this particular issue, the overarching governance questions will remain.