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:
I'm a strong supporter of the FSF, but I agree with Danny. This has
gone on far too long. Releasing gcc 4.4.0 with the same licensing as
gcc 4.3.0 will do no significant harm. The FSF is acting
inappropriately in restricting us in this way.
In response to Berlin's criticism of their response, SC member David
Edelsohn noted that there were things going
on behind the scenes:
Why do you think that the SC has not pushed back? Not all diplomacy
is best done in public. This is frustrating for all of us.
But a lack of communication from the SC to the greater GCC community is
part of the problem, according to Berlin:
Okay then, as the leadership body of the GCC community, part of your
responsibility is keeping your constituents (the rest of us!) informed
of the status of things troubling them.
I don't believe saying "we have given the FSF a deadline to meet in
the near future" would at all endanger any diplomacy, and i'd love to
see a counter argument that says otherwise.
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:
I don't understand this. Why does the SC have little power in this
matter? Surely you could decide to ship GCC 4.4 with the old license,
as the official GCC maintainer? But you *choose* not to use this
power (perhaps for good reasons, but I'm unconvinced).
Others believe that the FSF should be in complete control. Richard Kenner outlines how he sees the relationship:
The matters to which we defer to the FSF are any matters that they *ask*
us to! They own the code. If RMS, for some reason, decides that he doesn't
like the phrasing of a comment somewhere, we have to either convince RMS
he's wrong or change the comment.
As a practical matter, the FSF *delegates* most of their responsibilities
to the maintainer of the package, but they can undo that delegation as to
any matter any time they want.
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:
FWIW, I don't think we're anywhere near the same kind of tipping point
we faced a dozen years ago. I believe both sides learned lessons along
the way and I actually see evidence of that in the simple fact that
we've got a license and blessing to go forward with a plugin framework.
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:
While agreeing that the FSF is the legal owner of the code, I personally
consider the implementation language to be a technical detail which the
FSF has no special control over. We can consider their input, but we
need not follow it. This is distinct from licensing issues, where we
had to either move to GPLv3 or fork into an independent project.
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
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.
to post comments)