GCC Runtime Library Exception Rationale and FAQ

Introduction

On June 29th, 2007 the Free Software Foundation released GPLv3. It was immediately adopted by fifteen GNU projects, and more made the switch in the following months. Most of the GCC codebase migrated to the new license in the 4.2.2 release, and now we are preparing to finish that process.

The licenses for some libraries that accompany GCC have not been changed yet. These libraries are automatically used by the object code that GCC produces. Because of that, if these libraries were simply distributed only under the terms of the GPL, all the object code that GCC produces would have to be distributed under the same terms. However, the FSF decided long ago to allow developers to use GCC's libraries to compile any program, regardless of its license. Developing nonfree software is not good for society, and we have no obligation to make it easier. We decided to permit this because forbidding it seemed likely to backfire, and because using small libraries to limit the use of GCC seemed like the tail wagging the dog.

Therefore, these libraries have always had license exceptions that allow people to distribute the object code GCC produces under any license. We are now moving these libraries to GPLv3 and updating their exceptions. Our fundamental policy has not changed; the new license is meant to permit all the uses of GCC that were permitted before. However, we have decided to use this opportunity to update the exception to accomplish three goals:

Take advantage of GPLv3's new provisions. GPLv3 features a number of new terms which benefit all software. These include section 7, which establishes a framework for providing license exceptions. In order for GCC to get the most benefit from GPLv3, we need to update the exception to take these new terms into account, and work within the parameters of section 7.

Lay the groundwork for a plugin infrastructure in GCC. For a while now, the GCC developers have considered adding a plugin framework to the compiler. This would make it easier for others to contribute to the project, and accelerate the development of new compilation techniques for GCC. However, there have also been concerns that unscrupulous developers could write plugins that called out to proprietary software to transform the compiled code—effectively creating proprietary extensions to GCC and defeating the purpose of the GPL. The updated exception prevents such abuse, enabling the GCC team to look forward to plugin developments.

Make exceptions throughout the GCC code base consistent. Over the years, as new files were added to GCC that needed to carry this license exception, we reviewed and updated the language to help clarify it and address new concerns. As a result, there are now many different exception texts in GCC that provide the same basic permissions. Now all of those files will be able to use the single new exception text that we've prepared, making it easier to perform legal reviews on the code.

As with GPLv3, we worked hard to listen to various users' concerns while we drafted this, and address them appropriately. All told, we have spent more than a year on this process. The Free Software Foundation and the GCC Steering Committee would like to thank Richard Fontana, Bradley Kuhn, and Karen Sandler at the Software Freedom Law Center for all their hard work and assistance with the exception. The changes here will strengthen the GCC community, and we look forward to the compiler developments it will enable.

Because GCC is such a crucial part of developers' lives, we're expecting lots of questions about these changes, and we want to make sure that they're addressed. Below we've addressed specific concerns that we expect users will have. If you have questions about the new exception that aren't mentioned here, please feel free to contact us at <licensing@fsf.org>.

How the Exception Works

The permission you need—to convey the object code from these GCC libraries under your own project's license—is primarily contained in section 1:

You have permission to propagate a work of Target Code formed by combining the Runtime Library with Independent Modules, even if such propagation would otherwise violate the terms of GPLv3, provided that all Target Code was generated by Eligible Compilation Processes. You may then convey such a combination under terms of your choice, consistent with the licensing of the Independent Modules.

This section uses many defined terms, and their specific meanings are integral to how the exception works. This section looks at how these terms relate to common scenarios.

When you write your software, it consists of a set of source code files. Each file is an “Independent Module,” as long as it doesn't contain any source from the GCC libraries.

When you compile those source code files, they usually go through a series of steps: source code generation, preprocessing, compilation to low-level code, assembling, and linking. Not all projects follow all these steps, depending on what language you're using and how it's written, but they'll always go in this order, and everyone using GCC will go through the process of compiling high-level code into some low-level language such as assembly code or Java bytecode. This phase is when GCC combines or links your own code with code from the GCC libraries. We call it the “Compilation Process.” The output you get from it is called “Target Code,” as long as that output is not used as compiler intermediate representation, or to create such an intermediate representation.

In order to take advantage of this permission, the Compilation Process that you use to create Target Code has to be “Eligible,” which means that it does not involve both GCC and GPL-incompatible software. It's important to remember that the Compilation Process starts when you feed any high-level code to GCC, and ends as soon as it generates anything that can be considered Target Code. Because of that, as long as GCC isn't writing out intermediate representation, your Compilation Process can still be Eligible even if you use GCC in conjunction with GPL-incompatible assemblers, linkers, or high-level source generators: those programs aren't involved in the Compilation Process as it's defined here. The only place you can't use GPL-incompatible software with GCC is when it's performing the core compilation work.

So, if you use GCC, with or without GPL-compatible enhancements, that would be an Eligible Compilation Process. If you only use GPL-incompatible compiler tools, that would be an Eligible Compilation Process as well. (It's not uncommon for people who build software for GNU/Linux to link against the GCC libraries even if they're using a different compiler.) However, if you used GCC in conjunction with GPL-incompatible software during the process of transforming high-level code to low-level code, that would not be an Eligible Compilation Process. This would happen if, for example, you used GCC with a proprietary plugin.

As long as you use an Eligible Compilation Process, then you have permission to take the Target Code that GCC generates and propagate it “under terms of your choice.”

If you did use GPL-incompatible software in conjunction with GCC during the Compilation Process, you would not be able to take advantage of this permission. Since all of the object code that GCC generates is derived from these GPLed libraries, that means you would be required to follow the terms of the GPL when propagating any of that object code. You could not use GCC to develop your own GPL-incompatible software.

Frequently Asked Questions