Weekly Edition
Return to the Front page
| |||||||||||||
Plugging into GCC
Almost one year ago, LWN examined
the GCC plugin mechanism - or, more exactly, the lack of such a
mechanism. Despite the increasing level of interest in adding
special-purpose modules to the GCC compiler, GCC has no API which allows
this addition to be done. So developers working on GCC extensions are
faced with the daunting prospect of patching their code directly into the
compiler. This situation looked unlikely to change; the Free Software
Foundation's fears that a plugin mechanism would be used by proprietary
extensions was just too strong. One year later, though, things look a
little different; there may be a plugin-capable GCC available in the
(relatively) near future.
There are a lot of good reasons for wanting to add plugins to the GCC compiler. The implementation of better optimization techniques is an obvious example, but there is more than that. The EDoc++ project has put together a static analysis tool which performs checking of exception handling in C++ code - and generates documentation while it's at it. Mozilla uses its Dehydra tool to find potential problems in the browser's code base. The LLVM compiler can be thought of as a sort of GCC plugin, currently. The Middle End Lisp Translator project is working on a Lisp-like language which, in turn, can be used within plugins for static analysis and code transformations. The list goes on; just about any project working on the processing of programs can benefit from hooking into the GCC platform. The concern that has long been expressed by the FSF (which owns the copyrights on GCC) is that a general plugin mechanism would make it possible for companies to traffic in binary-only GCC modules. Rather than contribute a new analysis or optimization tool - or a new language - to the community, companies might have an incentive to distribute their work separately under a restrictive license. That runs very much counter to what the FSF is trying to accomplish, so opposition from that direction is not particularly surprising. But the pressure for some sort of plugin API is not going away, so the GCC developers have been thinking about ways to make it possible without upsetting Richard Stallman. One alternative which has been discussed is to require plugins to be written in a high-level scripting language - Python or Perl, perhaps. Then plugins would, for all practical purposes, have to be distributed in source form. Even if they carried a hostile license, it would be possible to study them and learn how they actually work. Another possibility is to take a page from the Linux kernel's book and keep the plugin API unstable. If the API changed with every GCC release, GCC would become a moving target which would be much harder for proprietary vendors to keep up with. An unstable API may be the way things go in any case - there may be no other way to allow GCC itself to continue to progress quickly - but experience with the kernel shows that an unstable API is not, by itself, enough to scare off a determined proprietary software vendor. It might reduce the number of proprietary GCC modules, but it would not eliminate them. Alternatively, one could require plugin modules to declare their license to the GCC core, which could then reject plugins that lack a suitable license. Again, experience with the kernel suggests that there are limits to how far one can get with this approach. Proprietary plugin vendors could distribute a version of GCC with the license check patched out - or just have their plugin lie about its license. Yet another possibility is to not worry about the problem at all; it is not clear that the world is full of vendors waiting for an opportunity to abuse a GCC plugin API. As GCC developer Ian Lance Taylor puts it:
The FSF doesn't want plugins because they are concerned that people
will start distributing proprietary plugins to gcc. I personally
think this is a fear from twenty years ago which shows a lack of
understanding of today's compiler market, but, that said, the FSF
wants to cover themselves for the future as well.
Someday, perhaps, the FSF will feel sufficiently confident to allow unrestricted plugin access to GCC, but that does not appear to be in the cards at this time. What does appear to be happening, though, is an attempt to enable plugins by way of some licensing trickery. The GCC suite is covered by the GPL, a fact which does not, in itself, affect the licensing of any program which is compiled by GCC. But GCC is more than just the compiler; it also includes a runtime library needed to make most GCC-compiled programs actually run. Linking to the runtime library could cause the resulting program to be a derived product of that library; since the runtime library is licensed under the GPL, that could be a concern for anybody compiling non-GPL-licensed code. To address that concern, the runtime code has long carried an exception to the GPL:
As a special exception, you may use this file as part of a free
software library without restriction. Specifically, if other files
instantiate templates or use macros or inline functions from this
file, or you compile this file and link it with other files to
produce an executable, this file does not by itself cause the
resulting executable to be covered by the GNU General Public
License. This exception does not however invalidate any other
reasons why the executable file might be covered by the GNU General
Public License.
That is the language which enables the distribution of proprietary software built with GCC. The plan, said to be under consideration currently, is to change the wording of that exemption; essentially, it would no longer apply to code compiled with the use of proprietary GCC plugins. The new license is not finalized, but Mr. Taylor guesses it will look something like this:
[I]f you modify gcc by adding GPL-incompatible software used to
generate code, it is likely that you will not be granted any
exception to the GPL when using the runtime library. In other
words, if you 1) add an optimization pass to gcc using the
(hypothetical) plugin architecture, and 2) that optimization pass
is not licensed under a GPL-compatible license, and 3) you generate
object code using that optimization pass, and 4) you link that
generated object code with the gcc runtime library (e.g., libgcc or
libstdc++-v3), then you will not be permitted to distribute the
resulting executable except under the terms of the GPL.
The actual wording of the new runtime license has been a long time in coming; the FSF's lawyers want to get it right so that it discourages undesired conduct while staying out of the way for everybody else. It also does not appear to be the FSF's highest priority at the moment. So nobody really knows when it might become official - though there have been notes to the list suggesting that it could happen in the near future. What we do seem to know is that it will happen, sooner or later, and the addition of a plugin mechanism to GCC will become possible. So the developers are starting to think about how the API will work. There are a couple of existing GCC plugin frameworks already, and plenty of thoughts on how they could be improved; see, for example, this discussion for an idea of what is being talked about. But the details are likely to be of interest mostly to GCC hackers, while the end result will be beneficial to a much wider community of developers and users. (Log in to post comments)
Plugging into GCC Posted Oct 2, 2008 23:50 UTC (Thu) by faramir (subscriber, #2327) [Link]
Let me get this straight. It will be okay to provide proprietary GCC plugins, but most things actually compiled with it will have to be distributed under the GPL.
What are the chances that Novell would pay someone $$ for a proprietary GCC plugin, if the resulting SUSE binaries were 10% faster then the binaries other people could generate from the same source code?
Seems to me that this proposed solution could have the worst possible effect. i.e. Making it harder for people to regenerate binaries from source code. A variant of tivoization for all GPLed software.
Plugging into GCC Posted Oct 3, 2008 0:38 UTC (Fri) by gmaxwell (subscriber, #30048) [Link]
Novell could already just use a wholly proprietary compiler such as icc, or they could take the current GCC and enhance it with private changes (perhaps which they have bought from someone else) which they do not distribute.
So, your bad scenario is already completely possible. The idea, as I understand it, behind the run-time licensing change it to poison the prospects of a commercial marketplace for proprietary plugins.
I'll be more inclined to believe that such a requirement is not necessary when there no longer exists a market for expensive vendor specific compilers for various embedded systems (TI c64x DSPs, for example).
Vendors who are currently raking in additional development fees licensing compilers would have a much easier time if they just had to build and sell a proprietary backend for GCC... so the incentive to not bother with that particular business model would be substantially reduced with an unrestricted plugin model for GCC.
build tools form part of "corresponding source code" Posted Jan 30, 2009 2:21 UTC (Fri) by xoddam (subscriber, #2322) [Link]
I believe (but IANAL) that in this scenario any required nonstandard build tool, to wit the GCC plugin, are considered to be part and parcel of the source code that corresponds to the supplied binaries. This is just the same as requiring preprocessors and build scripts to be distributed alongside the source.
The normal compiler and "system libraries" are exempt in normal circumstances thanks to this language (GPL v2, section 3): "as a special exception, the source code distributed need not include anything that is normally distributed (in either source or binary form) with the major components (compiler, kernel, and so on) of the operating system on which the executable runs".
As far as I can tell, there is nothing magic about a non-standard compiler (or compiler plugin) that exempts it from this requirement.
Of course that doesn't mean that the compiler itself *is* part of the source -- just that it's impossible to fulfil the requirement to distribute source without it, if the compiler is unusual.
Plugging into GCC Posted Oct 3, 2008 4:52 UTC (Fri) by wblew (subscriber, #39088) [Link]
Talk about insecurity. The reason that free software succeeds is because it innovates faster. The proprietary kernel modules exist to drive hardware whose specifications are secret.
However, by their nature, computer languages are *not* secret. They are well specified, or they fail in the marketplace.
I fail to see how the kernel situation is analogous to that of a GCC plugin architecture. I am in agreement with Ian Taylor, if GCC fails to innovate, then it deserves to fail.
Plugging into GCC Posted Oct 11, 2008 15:33 UTC (Sat) by jlokier (guest, #52227) [Link]
Computer languages are not secret (although there have been licensing restrictions on implementing some of them), but optimisation and transformation algorithms in a proprietary plugin can be secret.
Any actual statements from the FSF? Posted Oct 3, 2008 4:55 UTC (Fri) by stevenj (guest, #421) [Link] Just wondering — does anyone have pointers to direct statements from the FSF on this issue? It seems a bit odd to have LWN write two articles on gcc plugins centering around the supposed FSF opposition to them, but every description of the FSF position in both articles is hearsay.Google doesn't turn up anything obvious. To quote LWN's previous article, Some participants stated that Richard Stallman has blocked any sort of GCC plugin mechanism for just this reason - though it should be noted that Mr. Stallman has not contributed directly to this discussion (emphasis added). Can we get it straight from the horse's mouth, please?
It's not so simple Posted Oct 3, 2008 5:49 UTC (Fri) by khim (subscriber, #9252) [Link] RMS exist in somewhat different world - where time between program releases is STILL measured in years and mail can be safely answered month after it's sent. I'm pretty sure eventually we'll see something "straight from the horse's mouth" - but probably not so soon.
Time scales Posted Oct 4, 2008 3:18 UTC (Sat) by tnoo (subscriber, #20427) [Link]
Your feeling about the response time scales might be true for political statements.
As a developer of Emacs RMS is incredibly responsive, following up on bug reports
Any actual statements from the FSF? Posted Oct 3, 2008 11:30 UTC (Fri) by patrick_g (subscriber, #44470) [Link] >>> Can we get it straight from the horse's mouth, please?Sure. Try this mail from RMS : http://gcc.gnu.org/ml/gcc/2000-01/msg00572.html
Any actual statements from the FSF? Posted Oct 3, 2008 14:22 UTC (Fri) by rsidd (subscriber, #2582) [Link]
Did you check the date on that mail?
Any actual statements from the FSF? Posted Oct 3, 2008 14:24 UTC (Fri) by seyman (subscriber, #1172) [Link]
The ability to change his mind has never been RMS's defining personality trait.
Any actual statements from the FSF? Posted Oct 3, 2008 14:41 UTC (Fri) by rsidd (subscriber, #2582) [Link]
That's a content-free statement.
What is true is that RMS's agenda and ideology have not changed significantly since the 1980s. However, everything he does is to promote his cause of free software. If he believes that in certain circumstances a "weaker" licence is more suitable for that cause -- eg, LGPL for glibc, BSD for ogg vorbis -- he says so openly (google for statements in both cases). The circumstances with GCC in the 1980s were not the same as in 2000, and are not the same today. If a convincing argument were made that (a) GCC would compete better with proprietary compilers if a plugin mechanism were available, and (b) the plugin mechanism would be unlikely to suffer misuse, either because it is not in the interest of plugin writers or because the licence was carefully worded -- I believe he would not object.
Yes, but it does not mean they NEVER change Posted Oct 3, 2008 17:41 UTC (Fri) by khim (subscriber, #9252) [Link] For example GCC 4.3 uses ECJ for Java compiler (instead of GCC's own frontend). It was not an easy sell, but in the end RMS agreed.
Plugging into GCC Posted Oct 3, 2008 9:48 UTC (Fri) by jamesh (guest, #1159) [Link]
I wonder how this would deter groups who want to use GCC for things like static analysis? If you aren't aiming to generate executables, does the exception on libgcc really matter?
Plugging into GCC Posted Oct 3, 2008 9:56 UTC (Fri) by dgm (subscriber, #49227) [Link] What about the classic and (in)famous login backdoor perpetrated by Ken Thomson? I envision security
Plugging into GCC Posted Oct 3, 2008 17:48 UTC (Fri) by smitty_one_each (subscriber, #28989) [Link]
What is the point of fearing that which is effectively beyond control?
Plugging into GCC Posted Oct 6, 2008 18:03 UTC (Mon) by AJWM (guest, #15888) [Link]
Fear is useful in motivating one (or a group) to evaluate whether the thing really is beyond one's (their) control, and may prompt imaginative solutions. Fear (not panic) helps focus the attention.
Sure, if it is determined that the thing is beyond control, fear serves no further purpose.
Plugging into GCC Posted Oct 10, 2008 6:34 UTC (Fri) by stuart2048 (subscriber, #6241) [Link]
Does anyone know what his special login/password was?
Plugging into GCC Posted Oct 3, 2008 9:58 UTC (Fri) by ikm (subscriber, #493) [Link]
What I don't get is why just not add an explicit clause to the license specifically prohibiting non-GPL plugins? While linux kernel doesn't have any clear policy regarding binary modules since the opinions on the matter are split, here seems to be an unanimous opinion, so why not just put it into the compiler's license text?
Plugging into GCC Posted Oct 3, 2008 10:53 UTC (Fri) by Jonno (subscriber, #49613) [Link]
Becouse if the plugin is not a derived work of gcc the gcc license
agreement don't limit what you do with the plugin.
Exactly what is a derived work differ from juristiction to juristiction,
Of course, what is a "trivial" header file will also vary from juristiction
Plugging into GCC Posted Oct 3, 2008 11:27 UTC (Fri) by ikm (subscriber, #493) [Link]
> Because if the plugin is not a derived work of gcc the gcc license agreement don't limit what you do with the plugin.
So change the gcc license to limit it. Add a text to license saying that if you do make plugins for gcc, they are always considered derivative works and must be licensed under GPL. Or something like that that is, just add an additional clause to the license text. Why not?
Plugging into GCC Posted Oct 3, 2008 12:12 UTC (Fri) by RobSeace (subscriber, #4435) [Link]
Because, you can't change the law just by declaring something is so... The point is, that under law they would simply have no legal power to prevent them from doing it, regardless of what they said in their license text, unless the work was legally considered a derived work... And, that's a determination completely in the hands of copyright law and judges' takes on what that means... One can't just override copyright law and make up new rules in one's license...
GPLv3 anti-DRM clause Posted Oct 3, 2008 14:29 UTC (Fri) by cortana (subscriber, #24596) [Link]
Clause 3 of the GPL version 3:
"No covered work shall be deemed part of an effective technological measure under any applicable law fulfilling obligations under article 11 of the WIPO copyright treaty adopted on 20 December 1996, or similar laws prohibiting or restricting circumvention of such measures."
Can the GPL just declare that this is the case and have it be so? When I first read this clause, it occured to me that it is presumably up to a court to decide what is and is not an effective technological measure.
GPLv3 anti-DRM clause Posted Oct 3, 2008 14:46 UTC (Fri) by RobSeace (subscriber, #4435) [Link]
I'm not sure about that, but at least it's a much more reasonable position to take than declaring, "Everything that *I* say is a derived work is a derived work, regardless of what the law really says!"...
In that case, it sounds more like a declaration by the copyright holders (who chose to use that license) that they do not intend any DRM-like restrictions within the code to be considered illegal to circumvent... Of course, the intent is to restrict future third-parties who modify the code to ADD such restrictions, but the point is the same, because those third-parties, by choosing to modify and distribute a GPLv3 work, chose to accept the terms of that license, and so are bound by its restrictions...
In the case being discussed, the whole point was that a work may not actually BE a derived work, and therefore wouldn't come under the terms of the GPL in the first place, so no amount of additional restrictions added to the license would ever accomplish anything...
GPLv3 anti-DRM clause Posted Oct 3, 2008 18:06 UTC (Fri) by drag (subscriber, #31333) [Link]
> I'm not sure about that, but at least it's a much more reasonable position to take than declaring, "Everything that *I* say is a derived work is a derived work, regardless of what the law really says!"...
Yes! Absolutely.
'Derived Work' is a very specific legal term that is codified in the USA's copyright law. It's not up to a copyright holder, or licensee, to define the scope of 'derived work'. The definition of 'derived work' is set out in copyright law and in the judgements handed down by the nation's court system.
So if the GPLvX tries to say that 'linking' a program to GPL'd licensed code causes the program that links to be 'derived work' and a judge disagrees with that interpretation of the copyright law.. then guess what? You can legally link against a GPL program and there isn't anything that the copyright holders, lawyers, programmers, or anybody else can do about it. If it's beyond the scope of copyright then it's something that you simply can't write a license to prevent.
GPLv3 anti-DRM clause Posted Oct 3, 2008 20:29 UTC (Fri) by ikm (subscriber, #493) [Link]
> If it's beyond the scope of copyright then it's something that you simply can't write a license to prevent.
Could you use an EULA instead to combat this? :)
GPLv3 anti-DRM clause Posted Oct 3, 2008 21:05 UTC (Fri) by drag (subscriber, #31333) [Link]
I have no idea.
But think about what your asking.. Your asking to make a license that is _more_ restrictive then what is possible under copyright law. Is that approach really something you want to do when making 'Free' software?
----------------------------
The GCC folks probably really really need to reevaluate their entire attitude towards preventing proprietary plugins and back-ends/front-ends.
What is happening, it seems to me, that they are going to such lengths to fight a phantom menace that they are hurting real progress. That in a effort to combat a proprietary threat that, so far, has not existed, that they are doing REAL and immediate damage to the Free software folks that depend on their software and want to extend it to improve the state of the art.
Why not do everything you can to facilitate and create the best, most flexible, and most beneficial compiler you can and IF proprietary software becomes a problem THEN do something to try to deal with?
I am not saying that they should abandon all hope and embrace proprietary extensions.. I am saying that if people can prove a real benefit to extending the GCC framework in a way that would benefit Free software then they should do it.
GPLv3 anti-DRM clause Posted Oct 3, 2008 22:17 UTC (Fri) by ikm (subscriber, #493) [Link]
> Is that approach really something you want to do when making 'Free' software?
No in fact, I think that 'trust your users more' is a kind of better approach. But the FSF seems to know better and in doing so they sometimes start to feel like some kind of Free Software's Microsoft way(tm)(r).
Phantom menace? Threat that, so far, has not existed? Sorry - you are DEAD wrong. Posted Oct 4, 2008 7:25 UTC (Sat) by khim (subscriber, #9252) [Link] Aha. So NOW we are at stage where we are ignoring history if it does not suit us, right? Menace was clearly not phantom and threat was quite real - and you can read about this story here. These two sentences pretty much invalidate all your affectations: Why do we have a free C++ compiler? Only because the GNU GPL said it had to be free. That's pretty big accomplishment of all these "draconian restrictions" if you ask me. Of course that was then and we are talking about now, but... those who cannot remember the past are condemned to repeat it so we can not ignore the past and do everything you can to facilitate and create the best, most flexible, and most beneficial compiler you can and IF proprietary software becomes a problem THEN do something to try to deal with. Because the proprietary software WAS and IS the threat. Quite real and tangible. Yes, some companies like to play nice with free software (IBM, Google, etc)... as long as free software benefits them. Once that's not the case... all bets are off. Now, does it mean GCC should not implement plugins system? Of course not: it's usable for free software too. But do that and pretend that "proprietary threat" does not exist... it's just folly.
Phantom menace? Threat that, so far, has not existed? Sorry - you are DEAD wrong. Posted Oct 4, 2008 8:41 UTC (Sat) by drag (subscriber, #31333) [Link]
The license worked then... so it won't work now?
Look; There is a reason why people pored work into LLVM instead of improving GCC.
If you want people to use a GPL license and create open source software, making it impossible to do the work they need to get done is a shitty way of accomplishing that goal.
Have you actually READ the article? Posted Oct 4, 2008 10:16 UTC (Sat) by khim (subscriber, #9252) [Link] The license worked then... so it won't work now? Argh. WHY the license worked then? Apple and MCC specifically asked "can we distribute our front-ends as proprietary plugin to GCC" and RMS said "no" - after that GCC got C++ and ObjectiveC. And this worked because there were no simple way to write proprietary plugin and claim it's "independent work" (you were and still are pretty much forced to use large chunks of GCC code to interact with backend). Look; There is a reason why people pored work into LLVM instead of improving GCC.Yes and there are reason why Unix went nowhere while Linux took it's place. BSD went from being "something far beyond Linux" to "roughly equal, sometimes better, but often much worse". Yes, Apache/BSD licenses attract more developers and they do more work which is then wasted when companies go out of business. NetBSD tale should teach us something. The question today is: is GPLv3 (which makes it impossible for proprietary vendors to ship GCC with proprietary extensions - they can only ship extensions without appropriate copy of GCC) enough to prevent balcanization of GCC or not? If you want people to use a GPL license and create open source software, making it impossible to do the work they need to get done is a shitty way of accomplishing that goal.The question is, of course, not so simple. It's more like: do people want to create free software or do they want to create proprietary software, how many of the second camp can be pressured to first camp and how many of guys from first camp will go away in frustration if plugins will not be implemented? Answers to these questions are not easily obtainable - we can only guess...
Have you actually READ the article? Posted Oct 4, 2008 11:37 UTC (Sat) by Frej (subscriber, #4165) [Link]
Yes and there are reason why Unix went nowhere while Linux took it's place. BSD went from being "something far beyond Linux" to "roughly equal, sometimes better, but often much worse". Yes, Apache/BSD licenses attract more developers and they do more work which is then wasted when companies go out of business. NetBSD tale should teach us something. <snip>
That's true, there is no life time guarantee that someday you will be on your own using llvm when rest went closed. But in reality llvm+clang looks like a great piece of software (just avoiding the platform buzzword...) that can support existing C and C++ code...For now it just appears to be better software. Integrating clang with stuff like anjuta or emacs would finally bring actual code editors instead of text editors. ... ok just rambling now; sorry ;)
Have you actually READ the article? Posted Oct 19, 2008 1:55 UTC (Sun) by robert_s (subscriber, #42402) [Link]
"But in reality llvm+clang looks like a great piece of software (just avoiding the platform buzzword...) that can support existing C and C++ code...For now it just appears to be better software."
'For now' it doesn't support c++.
Have you actually READ the article? Posted Feb 5, 2009 14:22 UTC (Thu) by trasz (guest, #45786) [Link]
> Argh. WHY the license worked then?
It didn't. Marketing worked.
GPLv3 anti-DRM clause Posted Oct 5, 2008 6:07 UTC (Sun) by rickmoen (subscriber, #6943) [Link] "drag" wrote:'Derived Work' is a very specific legal term that is codified in the USA's copyright law. I'll admit that this is a minor faux pas, and feel bad about seeming to pick on you specifically, but I've noticed that computerists perpetuate any number of characteristic errors about law through merely quoting each other and not bothering to learn about actual law. In this case, I'm referring to your phrase 'derived work'. The actual phrase used in (at minimum) US and Canadian copyright law, which can be found in section 101 of United State Code title 17 (the Copyright Act) is 'derivative work'. Rick Moen
GPLv3 anti-DRM clause Posted Oct 6, 2008 18:11 UTC (Mon) by AJWM (guest, #15888) [Link]
The power of that clause lies in just who is doing the deeming.
If the distributor of the work deems it part of an effective technological measure (ETM), then that distributor is in violation of Clause 3 of GPL 3 and subject to copyright penalties for distributing the work. If the distributor doesn't deem it to be part of an ETM, then why would a court find otherwise?
Plugging into GCC Posted Oct 3, 2008 12:20 UTC (Fri) by madscientist (subscriber, #16861) [Link]
I don't understand what you're saying. Copyright is a legal concept, and it has legal foundations. You can't just make them up! If a work is not derived from another work (in the legal, not technical, sense) then you can't just declare that it is and have it be true. If a plugin is not a derived work then no amount of text in the GPL will apply to that plugin.
Plugging into GCC Posted Oct 3, 2008 20:12 UTC (Fri) by ikm (subscriber, #493) [Link]
Ok, I understand the plugin has to be a derivative work, which is something that is determined solely by the law. And here comes the question: does linking with a library constitute a derivative work or not? Does LGPL actually have any legal power? I'm asking because I don't really perceive much difference between a program using a library or a plugin which heavily relies on the host program's internals.
LGPL was never at risk Posted Oct 3, 2008 20:31 UTC (Fri) by khim (subscriber, #9252) [Link] Copyright starts with books. Think about this situation: Alice hates Bob (they had disagreements in the past) and so grants everyone permission to publish her poems ONLY if Bob's poems are not included in the book. Is it reasonable? May be, may be not. But it's Alice's sole discretion if she want to relax these requirements or not. That's the situation LGPL talks about: if you want to publish my poems you MUST make sure they are not mashed up with your poem to such a degree that it's impossible to separate them. Now plugins is different story altogether: Bob is not sitting idle and he creates book which is intended to complement Alice's creations (commentary or "my view on our differences"). This book DOES NOT include Alice's work at all - just a few small snippets here and there (allowed by fair use). Can the Alice say anything at all? Probably not: her work is not under the cover - why she must have any power over that creation? Or in other words: nVidia is a nasty company - but it DOES NOT violate copyright when it distributes nVidia binary drivers. These drivers don't include code from Linux and so are clearly not a derived work. Canonical, on the other hand, clearly LOST it's right to distribute Linux kernel when it included these same drivers on CD - if you view just letter of GPL. Of course kernel developers clearly tolerate such transgressions (GPL Violations won many battles over GPL non-compliance but not once they tried to force this issue) and this will be considered by court if the developers will decide to sue Canonical...
LGPL was never at risk Posted Oct 3, 2008 22:10 UTC (Fri) by ikm (subscriber, #493) [Link]
So the idea basically is like this: as long as you download library by yourself in order to run some particular program which doesn't incorporate it despite the fact that it requires it, it's you who infringes, not the author of that program? And what if the installer goes to the internet to download it for the user then who's to blame? Copyright law is sure creepy :)
No - you got it backwards! Posted Oct 4, 2008 7:00 UTC (Sat) by khim (subscriber, #9252) [Link] If you distribute the library AND the program - you need permissions from authors of both library and program. Very clear-cut case. Nothing is murky here. That's where GPL and LGPL are playing. But. If you want to do what you are describing (distribute the program without library and/or make installer download the library from third-party web site)... be ready to pay lawers and/or the court: the story starts to get murky and minor details can decide an outcome (see the next comment from jordanb for real-world case). For example if program can use both libedit and readline or "go without" (in which case there will be no high-level editing capabilities in your program) court can conclude that it's not a derived work of readline, but if it's unusable without readline the outcome can be different. Law is squishy as PJ likes to repeat: court looks not only on the letter of the law but on the spirit too and they try to decipher intentions of both law and authors so the end result can be uncertain. That's why nVidia drivers are probably clear: the same binary can be used in Windows so they are not related to Linux in any way and glue code is completely free so can not infringe anything by definition.
No - you got it backwards! Posted Oct 4, 2008 9:03 UTC (Sat) by drag (subscriber, #31333) [Link]
> If you distribute the library AND the program - you need permissions from authors of both library and program. Very clear-cut case. Nothing is murky here. That's where GPL and LGPL are playing.
Don't forget that the GPL specifically allows non-GPL-compatible programs to be shipped as part of a distribution.
From the GPLv2 license:
So, due to the language of the GPL, how programs are distributed are immaterial. (and, of course, the GPL only kicks in if the software is distributed) If the program is not considered legally 'derived work' then shipping it together or seperate doesn't matter. If it is considered 'derived work' then it doesn't matter either, it's still going to be covered under the GPL irregardless of how they are shipped.
:)
IANAL
Sorry, but no dice. Posted Oct 4, 2008 9:48 UTC (Sat) by khim (subscriber, #9252) [Link] Don't forget that the GPL specifically allows non-GPL-compatible programs to be shipped as part of a distribution. Not all non-GPL-compatible programs! Only totally unrelated ones! Your idea may be will work with linux kernel, but it does not work with GCC. You mixed the licenses. GPLv3 already addressed this loophole. It does not refer to derived works at all. What it does refer to is this: A compilation of a covered work with other separate and independent works, which are not by their nature extensions of the covered work, and which are not combined with it such as to form a larger program, in or on a volume of a storage or distribution medium, is called an aggregate if the compilation and its resulting copyright are not used to limit the access or legal rights of the compilation's users beyond what the individual works permit. Inclusion of a covered work in an aggregate does not cause this License to apply to the other parts of the aggregate. Plugins are by their very nature are "extensions on the covered work" and so it does not matter if they are derived works or not - you can not distribute them with GCC. The discussion in question is centered on separate distribution since distribution as bundle is already forbidden. So, due to the language of the GPL, how programs are distributed are immaterial. Sorry, it does matter. Big way. If the program is not considered legally 'derived work' then shipping it together or seperate doesn't matter. Nope. If the program is extension (and plugin is an extension) and if it's distributed on the same medium as GCC - it must be distributed under terms of the GPL. Because the whole medium is 'derived work' and so must comply with GCC. You can put somthing totally unrelated on this medium (Flash player or Adobe Reader, for example), but you can not put the plugin there. If the plugin is distributed separately - then and only then the question about "derived work" arises...
Sorry, but no dice. Posted Oct 6, 2008 3:44 UTC (Mon) by vonbrand (subscriber, #4458) [Link] This "aggregation" clause of GPLv3 (as much of the verbosity of the licenses) is just (re)stating what the relevant laws (and even common sense) tells you. True, but irrelevant. If they stated the exact opposite, the legal effect would be precisely the same: The license just can't override the law.
Very much no so. Posted Oct 6, 2008 6:54 UTC (Mon) by khim (subscriber, #9252) [Link] The license just can't override the law. Oh so very true. But what the law says about redistribution? Right: you can't do that. Wait till the end of author, then 70 more years - and only then you can. Or you can ask author for the permission. And as judge said: "If a publisher wants to publish a book of an author that wants his book only to be published in a green envelope, then that might seem odd to you, but still you will have to do it as long as you want to publish the book and have no other agreement in place." Sorry, but aggregation clause is very much not the restatement of relevant laws (may it's restatement of common sense, but this is irrelevant here). GPL had this clause from the very first version because someone noted that without it such programs can not be included in program collections (like once popular SimTel) since it'll mean all programs in said collection must be distributed under GPL if just one program uses GPL. Thus "aggregation clause" was added to limit "viral reach" of GPL. GPLv3 just fixed small problem there and made proprietary plugins illegal again, that's all.
LGPL was never at risk Posted Oct 4, 2008 4:30 UTC (Sat) by jordanb (guest, #45668) [Link]
Extend your example a bit and the issue gets murky though. Consider /The Wind Done Gone/[1] which was a retelling of the Gone With the Wind story from the eyes of a slave. It had no text from the original work in it, and even avoided using the character names, but it had the same plot and was unquestionably "inspired" by Mitchell's book.
The estate of Mrs. Mitchell got an injunction from the courts against its sell, eventually leading to a settlement.
So the point is that a work need not directly incorporate another work to be considered derivative and infringing. And there is a small contingent of Linux developers who are rattling the cage to go after NVidia with the argument that the NVidia drivers are inspired by and therefore infringing on Linux, although it doesn't look like anything is going to come of it.
What this all means with regards to GCC and the FSF.. I can't say, except that these issues are a lot more complicated than people tend to admit, and that these legal discussions on websites like this are pretty close to the three blind mice trying to come to terms with the elephant. We don't have the expertise -- and we've not done the research -- to have informed opinions on this matter. And that's as true of Corbet as it is of us posters.
That's different point from mine Posted Oct 4, 2008 7:07 UTC (Sat) by khim (subscriber, #9252) [Link] My point was that if you directly incorporate another work then the result is, of course, derived work - no further investigation is needed. Licenses are in play at this point. And that's true that sometimes work can be considered "derived work" even if it does not incorporate pieces of original work. But this is VERY gray area. Note that the case you mentioned was settled - because it's border-line case and both sides decided that it's safer to settle then to try to go all the way to supreme court.
Plugging into GCC Posted Oct 3, 2008 21:42 UTC (Fri) by palapa (subscriber, #612) [Link]
Couldn't the compiler require the plugin to be linked to a GPL'd library? For the API, for instance. That would make the plugin a derived work and force it to be GPL licensed.
Any such library can be reimplemented Posted Oct 4, 2008 7:11 UTC (Sat) by khim (subscriber, #9252) [Link] ...and published under Apache2 license. Of course then the question will be raised is the said library is derived work of original library or not - but that's very gray area and court cases can go on for years...
Plugging into GCC Posted Oct 3, 2008 15:37 UTC (Fri) by bronson (subscriber, #4806) [Link]
> Another possibility is to take a page from the Linux kernel's book and keep the plugin API unstable.
This would only work if the ultimate intent for plugin writers is to upstream their plugins and have the GCC devs eventually take over maintenance.
If the GCC devs are up for this, I think it sounds like a phenomenal idea!
Plugging into GCC Posted Oct 3, 2008 20:26 UTC (Fri) by ikm (subscriber, #493) [Link]
Exactly! Unless a plugin is incorporated upstream, it doesn't matter whether it is GPLed or proprietary the authors would have to routinely update for each new version, and the users would have to update to these versions each time they update to a newer gcc.
And given the conservative approach of the FSF, I'd doubt many plugins would end up upstream. Well, maybe it's just me.
Anyway, the idea of breaking the API solely for the sake of doing so feels ill-intended and just plain wrong. Maybe sometimes it's better to just relax, let go and assume that the world is not really *that* hostile? :)
Plugging into GCC Posted Oct 4, 2008 8:44 UTC (Sat) by drag (subscriber, #31333) [Link]
If people wanted to make a proprietary plugin to GCC then they would of already done so.
The GCC suite is free software last time I checked, so modifying the GCC source code to communicate with a proprietary hunk of software is something that they can already certainly do. Just as long as they release the GCC portion of the patch under the GPL there is nothing stopping them from having it work with something closed source.
The question is all about the cost Posted Oct 5, 2008 7:50 UTC (Sun) by khim (subscriber, #9252) [Link] Not so simple. One company should introduce (and support) such modified version of GCC and another unrelated company can then produce proprietary plugin (if they will be related court can declare both the part of the cartel created to circumvent the GCC). And this makes the whole scheme totally unrealistic: second company is doing it's business on the basis of code produced by someone who has NO obligations to that company AND is not supported upstream... Very flacky foundations. And GCC developers will not tolerate such abuse: where kernel developers are in unenvious situation where they can punish abusers only at the expense of users (there are no way to use nVidia cards except by using binary module) GCC works just fine without any such proprietary blobs... Sorry but to distribute proprietary plugin to GCC today is not hard. It's very hard... FSF will like to keep it this way - what's so strange about this?
Plugging into GCC Posted Oct 3, 2008 21:33 UTC (Fri) by flewellyn (subscriber, #5047) [Link]
I don't see what the big deal is; just have the "plugin API" require that the plugin module be linked to the GCC binary. Then the "linking" clause of the GPL takes hold. Easy enough.
Plugging into GCC Posted Oct 4, 2008 2:49 UTC (Sat) by i3839 (guest, #31386) [Link]
That won't work, for multiple reasons...
"linking clause" only works one way, so isn't relevant for the distribution of the binary plugin, only the GPL lib it's linked to (or if you prefer: "The whole work"). And it's easy to bypass.
Plugging into GCC Posted Oct 4, 2008 8:52 UTC (Sat) by drag (subscriber, #31333) [Link]
The 'linking clause' is very suspect anyways.
It's quite possible (although unlikely and unusual, unless the author is very careful) to have a piece of software that links with another and not be 'derived work' and therefore be quite out of bounds of any restriction any copyright-based license can impose, whether or not the language of the license allows it or not.
Remember that 'derived work' is defined in copyright law and in judge's opinions and not in any license.
Plugging into GCC Posted Oct 4, 2008 21:44 UTC (Sat) by chromatic (guest, #26207) [Link]
The question may depend on whether the distribution is in source form or binary form. The source code may not be a derivative work, while a binary may be. (This question is most interesting when considering NVIDIA's binary blob kernel module.)
Have you actually looked on what nVidia REALLY distributes? Posted Oct 5, 2008 7:39 UTC (Sun) by khim (subscriber, #9252) [Link] This question is most interesting when considering NVIDIA's binary blob kernel module This is real-world proof of successfull circunvention: nVidia is clearly in the clear here. No one ever said otherwise. Why? Simple: they distribute this "binary blob" as two parts: big closed-source driver and "public domain" glue code. The driver itself is not in violation of copyrights: it's not a derived work since the same blob can be used, for example, in Windows driver. Nothing Linux-specific there. Glue code is probably a derivative work of the Linux kernel, but... it's distributed without ANY restrictions and so is GPL-compliant. The real toxic thing is actual loadable kernel module - but nVidia does not distribute that (Canonical does), so nVidia is in the clear... The tiny amount of doubt remains: are binary blob and glue code really separate works? Court will decide but since both were created by nVidia problems in the interface (which can lead to derivativennes) are easy to fix...
Have you actually looked on what nVidia REALLY distributes? Posted Oct 5, 2008 12:34 UTC (Sun) by paulj (subscriber, #341) [Link]
it's not a derived work since the same blob can be used, for example, in Windows driver. Nothing Linux-specific there. What's the evidence for this btw? I know it's the generally accepted view, but what evidence is there for it, besides NVidias' confidence in being able to distribute this driver and the circumstantial evidence of some "looks like Windows programming style" symbol names? Is there any real independent evidence for this belief, or is being taken on trust?
No evidence. And it's probably not even true :-) Posted Oct 5, 2008 12:44 UTC (Sun) by khim (subscriber, #9252) [Link] Actually I think this blob differs slightly from what they ship in Windows driver. And I'm pretty sure even nVidia does not have Windows driver which uses this blob - but apparently they believe they can create such driver if court demands this. Realistically I do not expect deception here: if you have driver for Windows it's much easier to introduce glue code which will take it more-or-less unmodified then it's to create Linux-native driver. Think NDISwrapper. Linux developers will NEVER accept such driver in mainline - but this is not an issue for nVidia... Thus I'm pretty sure nVidia's blob IS what they have used for Windows driver - plus few small modifications here and there. Probably not enough to qualify as derivative of Linux kernel. And since the only reliable way to know (via court) is quite expensive... nobody bothers to actually check. Basically it all boils down the following three-step thought process:
Common misconception Posted Oct 5, 2008 6:57 UTC (Sun) by gmaxwell (subscriber, #30048) [Link]
There is a common belief that a software license is unable extend requirements related to derivatives past some boundary because of some externally imposed definition of derivative. In cases where this reasoning is invoked it is usually wrong.
When a copyleft license says "Thou shall not froboz this package with software under a different license" it doesn't much matter that US law may not consider frobozing to be an action which causes the target to be a derivative work: Your ability to receive the rights granted by the license was conditional on following the rules and without those rights you're not able to do much involving that package.
This does potentially leave open the door for vendors of proprietary code intended to be linked into free software, but whom don't actually distribute the free software themselves. Unless it can be shown that the free software's license was required (i.e. if the module were a derivative work) only downstream distributors (or, potentially, users) who need the rights granted by the free license be in violation.
But in the context of copyleft licenses and linking-like activities the person doing the linking-like activity will almost always be distributing the copyleft license covered software. In these cases the license is pretty much free to define its own linking requirements and have them be completely enforceable, since their distribution of the covered software would be a copyright infringement without the rights granted by the license.
The flow chart is:
The misunderstanding comes from skipping straight to (2) without first considering (1).
It's not misconceptions - it's just omitted step Posted Oct 5, 2008 7:28 UTC (Sun) by khim (subscriber, #9252) [Link] The misunderstanding comes from skipping straight to (2) without first considering (1). May be some people (like drag above) have this misconception, but people actually involved (RMS and FSF) surely don't. They see nVidia, they see Broadcom and ask "how can we prevent THIS?" and "should we actually try to prevent THIS?". And yes - this IS about case where plugins developer does not distribute GCC itself... Sorry, but you are coming from wrong side. You are cosidring what is
convenient (of course distribution of proprietary plugin with GCC is more
convinient then distribution without GCC) and then think about
copyrights. The makers of proprietary plugins come from different side: Think about Microsoft/Novell deal: how proud Microsoft was when their lawers found the loophole which allowed them to sign a deal which was supposed to be prevented by GPL! It's security - you should always think about the "weak part"...
It's not misconceptions - it's just omitted step Posted Oct 6, 2008 1:59 UTC (Mon) by gmaxwell (subscriber, #30048) [Link]
I guess I should have named names: I was speaking of some of the upthread posters (and similar comments on past threads), and *not* the FSF. Obviously the FSF knows what they are doing here (see my post way up at the top).
It's not misconceptions - it's just omitted step Posted Oct 9, 2008 4:24 UTC (Thu) by lysse (guest, #3190) [Link] Can everyone who is not an experienced copyright lawyer please refrain from jumping up and down and loudly insisting that they know what the legal position is? You might have an opinion about what the legal position should be; that's fine - but to claim any more than that without the appropriate expertise overreaches.
Experienced copyright lawyer? Who's that? Why he's infallible? Posted Oct 9, 2008 7:49 UTC (Thu) by khim (subscriber, #9252) [Link] The fact is: "experienced copyright lawyers" often are wrong when they discuss copyright licenses too. They just prepend every sentence with "this is my opinion, if you want legal advice I'll need more detail" so their mistakes are overlooked. The only entity which can know the legal position is Supreme Court (by definition) - and then the relevant position will be true only in one country. And it'll be entirely too silly to just go in dark because we can not get supreme courts opinions on the GCC plugins matter. To even approach something resembling legal position you need understanding of both copyright and technology (think SCO: do you think they prepared their insane legal theories without help of copyright lawers?) - and such people are rare and not all of them have lawers degree. Thankfully one of them is working on the case and I hope soon we'll get something "official"...
Experienced copyright lawyer? Who's that? Why he's infallible? Posted Oct 9, 2008 13:38 UTC (Thu) by lysse (guest, #3190) [Link]
> The fact is: "experienced copyright lawyers" often are wrong
> when they discuss copyright licenses too.
But cluefulness is not binary, and they have rather more than you do.
Common misconception Posted Oct 9, 2008 20:15 UTC (Thu) by vonbrand (subscriber, #4458) [Link] What the copyright laws control is a narrow set of actions. I.e., distributing, or distributing derivative works. If "frobozing" doesn't involve those actions, the law is silent.
Common misconception Posted Oct 9, 2008 20:42 UTC (Thu) by gmaxwell (subscriber, #30048) [Link]
Although in the posed hypothetical, and in many practical cases, we're considering someone who both frobozzes and reproduces the covered work. Since the latter is a reserved right we must look to see if a license existed, and presuming the offered license was conditional on non-frobozification we would conclude that someone who frobozzes has no such license and can not legally practice any of the rights reserved to the copyright holder. Perhaps they have no interest in those activities, but that is not usually the case.
People who spread the belief that if frobozzing is not an aspect of copyright law that a copyright license can't be conditional on it are spreading misinformation.
Plugging into GCC Posted Oct 6, 2008 16:50 UTC (Mon) by iabervon (subscriber, #722) [Link]
I'm a bit surprised that nobody's patched in a plugin API in the past year. It is unquestionably legal for somebody to fork GCC and add support for a plugin architecture of their own design. And plugins would be derived from the plugin architecture, and need to be compatible with the license given for it, not for GCC in general. It wouldn't matter too much whether the fork would become the official version, since it would be the version of choice for people doing compiler research. It would also have a reasonable chance of overtaking the official fork if it was an easier environment for useful optimizations than the GCC mainline, like egcs overtook the main branch a while ago.
The core point of free software is that users can work together to work around a software provider who refuses to make the software serve the needs of the users. This applies even if the provider is the FSF and the provider's motivation is supporting the larger free software agenda.
Plugging into GCC Posted Oct 6, 2008 17:50 UTC (Mon) by droundy (subscriber, #4559) [Link]
I imagine the issue is that of ongoing support. If the main gcc developers don't work on the patched plugin-gcc, it's quickly going to fall behind on features. And any sort of plugin interface seems likely to be extremely invasive, so porting the plugin patches over to newer gcc's most likely wouldn't be feasible in the long term.
Plugging into GCC Posted Oct 6, 2008 18:16 UTC (Mon) by iabervon (subscriber, #722) [Link]
For a lot of things, falling behind on features would be okay for plugin users, because they're often doing things where new features don't matter. (A lot of new features apply only to code generation, so plugins that don't generate code don't care; likewise new language front ends and support code for them aren't important for plugins designed for use with a particular language.)
Furthermore, I remember a lot of main gcc developers being more pragmatic than RMS, so it's likely that, if the plugin architecture used were more suitable for the features they want to write than the mainline code is, they'd actually work on the plugin fork instead (or first, and cross-port their finished feature). I remember hearing that one reason the new register allocator was a huge feature was that it required reorganizing a lot of code that was kept not abstracted in part to avoid making it easy to have plugins.
Plugging into GCC Posted Oct 6, 2008 20:42 UTC (Mon) by nix (subscriber, #2304) [Link]
In practice, GCC has enough weird quirks, even now, that the only way a
fork of GCC is going to take over from GCC itself is if it attracts a lot of the GCC developers (like egcs did). And if it does that, is it really a fork?
Plugging into GCC Posted Oct 6, 2008 23:36 UTC (Mon) by iabervon (subscriber, #722) [Link]
Well, it would be a fork in that it wouldn't necessarily follow the FSF's intentions for direction. For example, a version that supported plugins written to an API that isn't derived from gcc and is BSD-licensed (and could be supported by icc, etc) could become the de facto current branch on technical merit (if it eliminated a lot of the weird quirks from what a significant class of developers had to deal with), despite the fact that this result is exactly what the FSF wants to avoid.
|
|||||||||||||