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

I am using a standard release of GCC (such as one provided by the FSF, or with my operating system) to compile GPL-incompatible software. How does this change affect me?

It should not affect you at all. Unless you've configured GCC to output intermediate representation—which is rare—the new exception is designed to ensure that you have no license obligations when you do this, just as the old exceptions were.

Who does this change affect?

Nobody who is currently using GCC should be affected by this change. The only changes in policy are meant to prevent developers from making certain modifications to GCC that will become feasible in the future. The FSF has been working closely with GCC developers to learn more about the many different ways people use GCC today, and ensure that they will all be able to continue those activities under the new exception.

I use GCC in conjunction with proprietary preprocessors and/or source generators to compile my program. Can I still take advantage of the exception?

Yes. The Compilation Process can start with any “code entirely represented in a high-level, non-intermediate language.” This includes code generated by a preprocessor or other proprietary software. As such, the Compilation Process in this case does not involve any proprietary software; it qualifies as Eligible, and the exception is available for this program.

I use GCC in conjunction with proprietary assemblers and/or linkers to compile my program. Can I still take advantage of the exception?

Yes. The Compilation Process ends when the compiler generates Target Code, which includes output that is “suitable for input to an assembler, loader, linker and/or execution phase.” In other words, the Compilation Process in this case is over when you have assembly code or unlinked object files from GCC, and so it does not involve any proprietary software. It qualifies as Eligible, and the exception is thus available for this program.

I use GCC to compile parts of my program, and a proprietary compiler to compile other parts. The pieces are combined afterward, during assembler or linking phases. Can I still take advantage of the exception?

Yes. In this case, each Independent Module is turned into Target Code through an Eligible Compilation Process. Even though different modules will go through different processes, the exception is still available for this program.

I use a proprietary compiler toolchain without any parts of GCC to compile my program, and link it with libstdc++. My program itself does not include any runtime library code the same way that GCC-compiled programs include libgcc. Can I still take advantage of the exception?

Yes. While combining libgcc with GCC-compiled object code is probably the most common way the exception is used, neither the GPL nor the GCC Runtime Library Exception distinguish between static linking, dynamic linking, and other methods for combining code in their conditions. The same permissions are available to you, under the same terms, no matter which method you use.

Note that if you distribute libstdc++ as an independent library, you will need to follow the terms of the GPL when doing so. For example, if you distribute the library itself in object code form, you will need to provide source code to your recipients using one of the methods listed in section 6 of GPLv3. But as long as you are eligible to take advantage of the GCC Runtime Library Exception's permissions for your own program, the GPL's terms do not extend to it.

Why is compiler intermediate representation excluded from the definition of “Target Code”?

When we first considered adding a plugin infrastructure to GCC, we were deeply concerned about the possibility that someone would write a plugin that would merely save GCC's internal, low-level compilation data structures to disk. With that done, other software would be able to optimize or otherwise improve that code without being directly connected to GCC. It may have been difficult for us to argue that those programs should be subject to the GPL's copyleft, so we wanted to discourage these sorts of arrangements.

We do that by excluding such output from the definition of Target Code. Because of this, even if someone writes a plugin that saves this information to disk, any programs that change the structures before GCC writes out Target Code will be involved in the Compilation Process. If that program is proprietary, the exception will not be available to any software compiled with it; the object code that GCC ultimately creates will have to be distributed under the terms of the GPL.

If I write some code in assembly language, can I combine that with other object code compiled normally, and still take advantage of the exception?

Yes, as long as all of the object code was compiled through an Eligible Compilation Process. The process of running hand-written assembly through an assembler is a Compilation Process, since it “transforms code entirely represented in [a] non-intermediate language[] designed for human-written code... into Target Code.”

What libraries does the GCC Runtime Library Exception cover?

The GCC Runtime Library Exception covers any file that has a notice in its license headers stating that the exception applies. This includes libgcc, libstdc++, libfortran, libgomp, libdecnumber, libgcov, and other libraries distributed with GCC.

Will Classpath use this new exception?

Even though Classpath's current exception serves a similar purpose, we are not updating it at this time. Because of recent developments in the free software Java community, the priorities for Classpath's licensing policies are different from other GCC libraries, and we are evaluating it separately.