Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2009/01/27/gcc-exception.html

For the past sixteen months, I participated in a bit of a “mini-GPLv3
process” among folks at the FSF, SFLC, the GNU Compiler Collection
Steering Committee (GCC SC), and the GCC community at large. We’ve been
drafting an important GPLv3 license exception (based on a concept by
David Edelsohn and Eben Moglen, that they invented even before the
GPLv3 process itself started).
Today, that
GCC Runtime Library Exception for GPLv3 went into production.

I keep incessant track of my hours spent on various projects, so I have
hard numbers that show I personally spent 188 hours — a full month
of 40-hour weeks — on this project. I’m sure my colleagues
have spent similar amounts, too. I am proud of this time, and I think
it was absolutely worthwhile. I hope the discussion gives you a flavor
of why FLOSS license exception drafting is both incredibly important and
difficult to get right without the greatest of care and attention to
detail.

Why GPL Exceptions Exist

Before I jump into discussion of this GCC Runtime Library exception,
some background is needed. Exceptions have been a mainstay of copyleft
licensing since the inception of the GNU project, and once you’ve seen
many examples over many years, they become a standard part of FLOSS
licensing. However, for the casual FLOSS developer who doesn’t wish to
be a licensing wonk (down this path lies madness, my friends, run
screaming with your head covered!), exceptions are a rare discovery in a
random source file or two, and they do not command great attention. An
understandable reaction, but from a policy perspective, they are an
essential part of the copyleft system.

From the earliest days of the copyleft, it was understood that copyleft
was a merely a strategy to reach the goal of software freedom. The GPL
is a tool that implements this strategy, but like any tool, it doesn’t
fit every job.

In some sense, the LGPL was the earliest and certainly the most widely
known “GPL exception”. (Indeed, my friend Richard Fontana
came up with the idea to literally make LGPL an exception to
GPLv3, although in the v2 world, LGPLv2 was a fully separate license
from GPLv2.) Discussions on why the LGPL exists are beyond the scope of
this blog post
(although I’ve
written about them before). Generally speaking, though, LGPL is
designed to be a tool when you don’t want the full force of copyleft for
all derivative works. Namely, you want to permit the creation of some
proprietary (or partly proprietary) derivative works because allowing
those derivations makes strategic sense in pursuing the goal of software
freedom.

Aside from the LGPL, the most common GPL exceptions are usually what we
generally categorize as “linking exceptions”. They allow
the modifier to take some GPL’d object code and combine it in some way
with some proprietary code during the compilation process. The simplest
of these exceptions is found when you, for example, write a GPL’d
program in a language with only a proprietary implementation, (e.g.,
VisualBasic) and you want to allow the code to combine with the
VisualBasic runtime libraries. You use your exclusive right as
copyright holder on the new program to grant downstream users,
redistributors and modifiers the right combine with those proprietary
libraries without having those libraries subject to copyleft.

In essence, copyleft exceptions are the scalpels of copyleft. They
allow you to create very carefully constructed carve-outs of permission
when pure copyleft is too blunt an instrument to advance the goal of
software freedom. Many software freedom policy questions require this
fine cutting work to reach the right outcome.

The GCC Exception

The GCC Exception (well, exceptions, really) have
always been a particularly interesting and complex use of a copyleft
exception. Initially, they were pragmatically needed to handle a
technological reality about compilers that interacts in a strange way
with copyright derivative works doctrine. Specifically, when you
compile a program with gcc, parts of GCC itself, called the runtime
library (and before that, crt0), are combined directly with your program
in the output binary. The binary, therefore, is both a derivative work
of your source code and a derivative work of the runtime library. If
GCC were pure GPL, every binary compiled with GCC would need to be
licensed under the terms of GPL.

Of course, when RMS was writing the first GCC, he realized immediately
this licensing implication and created an exception to avoid this.
Versions of that exception has been around and improved since the late
1980s. The task that our team faced in late 2007 was to update that
exception, both to adapt it to the excellent new GPLv3 exceptions
infrastructure (as Fontana did for LGPLv3), and to handle a new policy
question that has been kicking around the GCC world since 2002.

The Plugin Concern

For years, compiler experimentalists and researchers have been
frustrated by GCC. It’s very difficult to add a new optimization to GCC
because you need quite a deep understanding of the codebase to implement
one. Indeed I tried myself, as a graduate student in programming
languages in the mid-1990s, to learn enough about GCC to do this, but
gave up when a few days of study got me nowhere. Advancement of
compiler technology can only happen when optimization experimentation
can happen easily.

To make it easy to try new optimizations out, GCC needs a plugin
architecture. However, the GCC community has resisted this because of
the software freedom implications of such an architecture: if plugins
are easy to write, then it will be easy to write out to disk a version
of GCC’s internal program representation (sometimes called the
intermediate representation, or IR). Then, proprietary programs could
be used to analyze and optimize this IR, and a plugin could be used to
read the file back into GCC.

From a licensing perspective, such an optimizing proprietary program
will usually not be a derivative work of GCC; it merely reads and writes
some file format. It’s analogous to OpenOffice reading and writing
Microsoft Word files, which doesn’t make it a derivative of Word by any
means! The only parts that are covered by GPL are the actual plugins to
GCC to read and write the format, just as OpenOffice’s Word reader and
writer are Free Software, but Microsoft Word is not.

This licensing implication is a disaster for the GCC community. It
would mean the advent of “compilation processes” that were
“mixed”, FaiF and proprietary. The best, most difficult and
most interesting parts of that compilation process — the
optimizations — could be fully proprietary!

This outcome is unacceptable from a software freedom policy
perspective, but difficult to handle in licensing. Eben Moglen, David
Edelsohn, and a few others, however, came up with an innovative idea:
since all binaries are derivative of GCC anyway, set up the exception so
that proprietary binary output from GCC is permitted only when the
entire compilation process involves Free Software. In other words, you
can do these proprietary optimization plugins all you want, but if you
do, you’ll not be able to compile anything but GPL’d software with
them!

The Drafting and the Outcome

As every developer knows, the path from “innovative idea”
to “working implementation” is a long road. It’s just as
true with licensing policy as it is with code. Those 188 hours that
I’ve spent, along with even more hours spent by a cast of dozens, have
been spent making a license exception that implements that idea
accurately without messing up the GCC community or its licensing
structure.

With jubilation today, I link to
the announcement
from the
FSF, the
FAQ and Rationale for the exception and
the final
text of the exception itself. This sixteen-month long cooperation
between the FSF, the SFLC, the GCC SC, and the GCC community has
produced some fine licensing policy that will serve our community well
for years to come. I am honored to have been a part of it, and a bit
relieved that it is complete.