Weekly Edition
Return to the Front page
| |||||||||||||
The new GCC runtime library exemption
As described in Plugging into
GCC last October, the runtime library code used by the GCC compiler (which
implements much of the basic functionality that individual languages need
for most programs) has long carried
a license exemption allowing it to be combined with proprietary software.
In response to the introduction of version 3 of the GPL and the desire
to add a plugin infrastructure to GCC, the FSF has now
announced that
the licensing of the GCC runtime code has changed. The FSF wishes to
modernize this bit of licensing code while, simultaneously, using it as a
defense against the distribution of proprietary GCC plugins.
Section 7 of GPLv3 explicitly allows copyright holders to exempt recipients of the software from specific terms of the license. Interestingly, people who redistribute the software have the option of removing those added permissions. The new GCC runtime library license is GPLv3, but with an additional permission as described in Section 7. That permission reads:
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.
Anybody who distributes a program which uses the GCC runtime, and which is not licensed under GPLv3, will depend on this exemption, so it is good to understand what it says. In short, it allows the runtime to be combined with code under any license as long as that code has been built with an "Eligible Compilation Process." The license defines a "Compilation Process" as the series of steps which transforms high-level code into target code. It does not include anything which happens before the high-level code hits the compiler. So preprocessors and code generation systems are explicitly not a part of the compilation process. As for what makes an "Eligible Compilation Process," the license reads:
A Compilation Process is "Eligible" if it is done using GCC, alone
or with other GPL-compatible software, or if it is done without
using any work based on GCC. For example, using non-GPL-compatible
Software to optimize the GCC intermediate representation would not
qualify as an Eligible Compilation Process.
This is where the license bites users of proprietary GCC plugins. Since those plugins are not GPL-compatible, they render the compilation process "ineligible" and the resulting code cannot be distributed in combination with the GCC runtime libraries. This approach has some interesting implications:
The explanatory material released with the license change includes this text:
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.
With this change, though, the FSF is doing exactly that: using its "small libraries" to control how the to-be-developed GCC plugin mechanism will be used. It will be interesting to see how well this works; if a vendor is truly determined to become a purveyor of proprietary GCC modules, the implementation of some replacement "small libraries" might not appear to be much of an obstacle. In that sense, this licensing truly could backfire: it could result in the distribution of binaries built with both proprietary GCC modules and a proprietary runtime library. But, then, that depends on the existence of vendors wanting to distribute proprietary compiler plugins in the first place. It is not entirely clear that such vendors exist at this point. So it may well end up that the runtime exemption will not bring about any changes noticeable by users or developers, most of whom never thought about the runtime exemption in its previous form either. (Log in to post comments)
The new GCC runtime library exemption Posted Jan 27, 2009 19:17 UTC (Tue) by daney (subscriber, #24551) [Link]
IANAL, but it seems that LLVM with a GCC front-end would not be allowed to use any of the of the so licensed runtime libraries unless it (LLVM) were GPLv3 compatible.
The new GCC runtime library exemption Posted Jan 27, 2009 19:45 UTC (Tue) by jhubbard (guest, #5513) [Link]
The LLVM license seems to be compatible with the GPL (ask a lawyer) for those areas where it isn't GPL already.
The new GCC runtime library exemption Posted Jan 27, 2009 21:05 UTC (Tue) by bkoz (guest, #4027) [Link]
FYI, GPL-compatible licenses are listed here:
From this list, it looks like LLVM's "University of Illinois/NCSA Open Source License" is GPL-compatible.
Thus, my (brief) reading of this is that LLVM as a GCC-plugin would be legal.
The new GCC runtime library exemption Posted Jan 27, 2009 22:05 UTC (Tue) by gmaxwell (subscriber, #30048) [Link] But there are modified versions of LLVM which are not.For example, Adobe Alchemy is a hacked up binary-only copy of LLVM which targets the Flash virtual machine. It also includes its own binary-only intermediate format optimizer pass. Alchemy lets you take C code and run it in Flash. (my own interest in it is using it to create flash decoders for unencumbered formats— So that a website's decision to use Ogg/Theora doesn't limit them to just Firefox, Opera, Safari, and Java capable clients) When I first tried Alchemy I thought they had used GCC directly, since it uses GCC as a front end (using alchemy is exactly like using GCC to cross compile). I was hopeful that it meant Adobe was releasing their Flash VM targeting code, since this would be VERY HELPFUL for projects like haXe and Gnash. Unfortunately the backend is all proprietary, and the Alchemy license professes to forbid all forms of reverse engineering (too bad, because it outputs many undocumented FlashVM opcodes).
The new GCC runtime library exemption Posted Jan 27, 2009 22:33 UTC (Tue) by JoeBuck (subscriber, #2330) [Link] Right, and it's precisely the intent of the new language to encourage plugins that are free software and discourage those that aren't. Sufficiently determined developers can find ways around the new language, but it helps the FSF feel better about allowing GCC to officially have a plugin architecture.
The new GCC runtime library exemption Posted Jan 28, 2009 1:23 UTC (Wed) by Ze (guest, #54182) [Link]
>>But there are modified versions of LLVM which are not.
The LLVM cfront front end will take care of that (and I'll be really happy when c++ support matures for it.
>>I was hopeful that it meant Adobe was releasing their Flash VM targeting code, since this would be VERY HELPFUL for projects like haXe and Gnash. Unfortunately the backend is all proprietary, and the Alchemy license professes to forbid all forms of reverse engineering (too bad, because it outputs many undocumented FlashVM opcodes).
Person A is complying with the license , whilst person B doesn't have too :)
The new GCC runtime library exemption Posted Jan 28, 2009 3:42 UTC (Wed) by jamesh (guest, #1159) [Link]
If the compiler is generating flash bytecode, presumably it is not directly linking the result to the GCC runtime library. So this sounds like another case that this license change will not affect – good for Adobe, not so good for the FSF.
That is assuming that the lawyers don't decide that running said flash code on a flash player linked to the GCC runtime library is covered ...
The new GCC runtime library exemption Posted Jan 28, 2009 4:27 UTC (Wed) by dlang (✭ supporter ✭, #313) [Link]
the lawyers can decide that, but they need to get the judges to agree.
frankly, getting anyone to say that taking valid, standard to International standards C++ code and having a compiler convert it to an executable makes that source derived from the binary (and affected in _any_ way by the compilers license) should be a long shot.
It's the other way around Posted Jan 28, 2009 10:10 UTC (Wed) by khim (subscriber, #9252) [Link] frankly, getting anyone to say that taking valid, standard to International standards C++ code and having a compiler convert it to an executable makes that source derived from the binary (and affected in _any_ way by the compilers license) should be a long shot. Source is unaffected, the binary is. You can continue to sell source under any license after said compilation - not so fo the binary. There were a lot of precedents where runtime package (needed to run the compiled code) required separate license (often on per-seat basis).
It's the other way around Posted Jan 28, 2009 22:14 UTC (Wed) by dlang (✭ supporter ✭, #313) [Link]
it is common for the source to include third-party libraries that have per-seat licenses.
but for the compiler to mandate a library that has such a license?
or for a compiler to require per-seat licensing of the binaries that it produces???
even in the cases of proprietary compilers, you could make your source code link against a free library and not worry that using a particular compiler 'tainted' the resulting binary so that you couldn't use it without the approval of the compiler company.
Is it REALLY so strange? Posted Jan 28, 2009 23:47 UTC (Wed) by khim (subscriber, #9252) [Link] If you'll go back decade or so you'll find many, many, MANY packages which required separate developer license and license for redistribution. You'll find countless offers like In addition to dBASE IV version 1.1, Ashton-Tate offers a version 1.1 developer's edition with a royalty-free unlimited RunTime distribution license, the template language source code, two extra LAN keys, and additional applications distribution tools and utilities (emphasis mine). dBASE IV can produce binaries - but you have no right to redistribute them while dBASE IV developer's edition (for extra cost, of course) gives you such a license. Now - I'm not saying such requirements are great, but they certainly are not uncommon. If you want to say "oh, it's Ok for xBase, but strange for C/C++" then I'll agree: it is stange. Most C/C++ compilers don't include such limitations. But... what's the difference between xBase and C/C++? I mean: from legal viewpoint? After all world is now accustomed to copyleft concept - and it was strange and unusual 20 years ago...
Is it REALLY so strange? Posted Jan 29, 2009 0:07 UTC (Thu) by dlang (✭ supporter ✭, #313) [Link]
for DBASE by understanding was that the 'binary' just embedded the entire DBASE interpreter in the resulting binary.
that's not how a compiler is supposed to work.
Is it REALLY so strange? Posted Jan 29, 2009 0:57 UTC (Thu) by nix (subscriber, #2304) [Link]
Hah. It was more extreme even than that, IIRC. The Clipper 'compiler' at
least worked by compiling the program to bytecode and then simply appending the bytecode to a 180Kb-or-so interpreter-and-database-engine. (Despite that, the linker was astonishingly slow. I have no clue what it was doing: given that it was linking the same binary every time, I'm not even sure why they *needed* a linker.)
Crystal Clear? Posted Jan 28, 2009 13:30 UTC (Wed) by sylware (guest, #35259) [Link]
They should combine what they wrote in the modified GPLv3 with crystal clear terms like:
"GCC plugins, including their dependencies requiered for maximum functionality and performance, shall all be GPL".
Crystal Clear? Posted Jan 28, 2009 14:09 UTC (Wed) by ikm (subscriber, #493) [Link]
I think I've brought this up before here: http://lwn.net/Articles/301633/
Crystal Clear? Posted Jan 28, 2009 16:50 UTC (Wed) by JoeBuck (subscriber, #2330) [Link] The reason why it wasn't done that way is that you could then write a GPL plugin that would convert from GCC internal format to a different format and dump to a file, and another one to do the inverse direction: read the file dump back into GCC. Then your proprietary optimizations would work on the alternative representation in the dump file, and not be derivative works of any GPL code at all.The alternative chosen does not forbid the above, it just says that if you do it that way, you lose the exception that lets you link proprietary code to the language support libraries. A determined developer could just write his/her own, or use older GCC libraries.
The new GCC runtime library exemption Posted Jan 29, 2009 15:27 UTC (Thu) by anton (guest, #25547) [Link] Since those plugins are not GPL-compatible, they render the compilation process "ineligible" and the resulting code cannot be distributed in combination with the GCC runtime libraries.The way I understand what you wrote in the article, the exception goes away with the ineligible compilation process, but GPLv3 remains. So the resulting code can be distributed under the terms of GPLv3 in combination with the GCC run-time libraries. And free software that happes to have been run through a proprietary optimizing module is allowed, if it's license is GPLv3 compatible (the binary is distributed under the combination of these licenses). The effect is that proprietary plugins cannot be used to compile proprietary software, but they can be used to compile free software.
The new GCC runtime library exemption Posted Jan 29, 2009 17:52 UTC (Thu) by JoeBuck (subscriber, #2330) [Link] Not even that: those using proprietary plugins just need runtime libraries that don't have the new language; they could use the code from old GCC releases, for example. But they'd then have to fork all the language support libraries, which for C++ at least would be a huge task going forward (especially as the C++ word transitions to c++0x).
C++0x -- flogging a dead cat? Posted Jan 30, 2009 2:35 UTC (Fri) by xoddam (subscriber, #2322) [Link]
Speaking of C++0x, time has run out for Stroustrup's Schroedinger's cat 'x', the box opens this year. Either 'x' will collapse to a concrete 9 (in which case we should be referring to C++09already), or the standard won't be issued in 0x at all.
C++0x -- flogging a dead cat? Posted Jan 30, 2009 2:50 UTC (Fri) by dlang (✭ supporter ✭, #313) [Link]
the expectation is that it will not be ratified this year (there are too many steps left in the process)
C++0x -- flogging a dead cat? Posted Jan 30, 2009 4:36 UTC (Fri) by bronson (subscriber, #4806) [Link]
No problem. If it comes out next year, just read it as a roman numeral.
But if it comes out in 2011, I guess they'd have to call it C++0xi.
C++0x -- flogging a dead cat? Posted Jan 30, 2009 5:53 UTC (Fri) by pflugstad (subscriber, #224) [Link]
Bah - not roman - hex! C++0xA of course!
Pete
PS: can't believe I'm the only one that saw that... or maybe
C++0x -- flogging a dead cat? Posted Jan 30, 2009 12:36 UTC (Fri) by xoddam (subscriber, #2322) [Link]
Of course it's hex! I stand corrected. Obvious when you think about it.
C++0x -- flogging a dead cat? Posted Jan 30, 2009 15:48 UTC (Fri) by anton (guest, #25547) [Link] It was probably in 1989 when I read a comment that Fortran 8x would have to use hex digits if it needed any longer. However, the released version was not called Fortran 8A, but Fortran 90.
The new GCC runtime library exemption Posted Feb 5, 2009 8:56 UTC (Thu) by trasz (guest, #45786) [Link]
Yet another reason to switch to some more free compiler. Apple, we're waiting :-)
|
|||||||||||||