LWN: Comments on "Plugging into GCC"

Have you actually READ the article?

trasz — Thu, 05 Feb 2009 14:22:25 +0000

> Argh. WHY the license worked then?

It didn't. Marketing worked.

build tools form part of "corresponding source code"

xoddam — Fri, 30 Jan 2009 02:21:27 +0000

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.

Have you actually READ the article?

robert_s — Sun, 19 Oct 2008 01:55:05 +0000

"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++.

Plugging into GCC

jlokier — Sat, 11 Oct 2008 15:33:09 +0000

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.

Plugging into GCC

stuart2048 — Fri, 10 Oct 2008 06:34:00 +0000

Does anyone know what his special login/password was?

Common misconception

gmaxwell — Thu, 09 Oct 2008 20:42:13 +0000

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.

Common misconception

vonbrand — Thu, 09 Oct 2008 20:15:35 +0000

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.

Experienced copyright lawyer? Who's that? Why he's infallible?

lysse — Thu, 09 Oct 2008 13:38:08 +0000

> 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.

Experienced copyright lawyer? Who's that? Why he's infallible?

khim — Thu, 09 Oct 2008 07:49:34 +0000

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"...

It's not misconceptions - it's just omitted step

lysse — Thu, 09 Oct 2008 04:24:26 +0000

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.

Plugging into GCC

iabervon — Mon, 06 Oct 2008 23:36:33 +0000

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.

Plugging into GCC

nix — Mon, 06 Oct 2008 20:42:40 +0000

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

iabervon — Mon, 06 Oct 2008 18:16:52 +0000

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.

GPLv3 anti-DRM clause

AJWM — Mon, 06 Oct 2008 18:11:13 +0000

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

AJWM — Mon, 06 Oct 2008 18:03:08 +0000

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

droundy — Mon, 06 Oct 2008 17:50:53 +0000

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

iabervon — Mon, 06 Oct 2008 16:50:14 +0000

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.

Very much no so.

khim — Mon, 06 Oct 2008 06:54:02 +0000

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.

Sorry, but no dice.

vonbrand — Mon, 06 Oct 2008 03:44:10 +0000

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.

It's not misconceptions - it's just omitted step

gmaxwell — Mon, 06 Oct 2008 01:59:44 +0000

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).

No evidence. And it's probably not even true :-)

khim — Sun, 05 Oct 2008 12:44:01 +0000

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:
1. It's easier to keep this blob as separate non-derivative work (then you can ship the same code for Windows and Linux and save on Q&A).
2. They are legally required to keep it in non-derivative state.
3. If it's both easier and required - then why nVidia will do it in any other way?

Have you actually looked on what nVidia REALLY distributes?

paulj — Sun, 05 Oct 2008 12:34:09 +0000

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?

The question is all about the cost

khim — Sun, 05 Oct 2008 07:50:36 +0000

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?

Have you actually looked on what nVidia REALLY distributes?

khim — Sun, 05 Oct 2008 07:39:57 +0000

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...

It's not misconceptions - it's just omitted step

khim — Sun, 05 Oct 2008 07:28:48 +0000

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:
1) We want to distribute our "cool technology" as proprietary plugin to GCC
2) Can we bundle them and distribute GCC and our cool technology together?
3) No? Well - too bad, we need chapter in documentation about downloading process...

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"...

Common misconception

gmaxwell — Sun, 05 Oct 2008 06:57:56 +0000

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:
1) Did you distribute, modify, publicly perform, or otherwise execute a reserved right with the the covered work:
Yes) You must do whatever the license requires. Stop.
No) Continue on to (2)
2) Would a court consider what you distributed to be a derivative work?
Yes) You must do whatever the license requires and you should have answered Yes to the above, creating a derivative is a reserved right. Idiot. Stop.
No) Do whatever you want. Stop.

The misunderstanding comes from skipping straight to (2) without first considering (1).

GPLv3 anti-DRM clause

rickmoen — Sun, 05 Oct 2008 06:07:22 +0000

"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
rick@linuxmafia.com

Plugging into GCC

chromatic — Sat, 04 Oct 2008 21:44:25 +0000

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 READ the article?

Frej — Sat, 04 Oct 2008 11:37:59 +0000

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?

khim — Sat, 04 Oct 2008 10:16:51 +0000

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...

Sorry, but no dice.

khim — Sat, 04 Oct 2008 09:48:13 +0000

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...

No - you got it backwards!

drag — Sat, 04 Oct 2008 09:03:41 +0000

> 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:
> In addition, mere aggregation of another work not based on the Program with the Program (or with a work based on the Program) on a volume of a storage or distribution medium does not bring the other work under the scope of this 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

Plugging into GCC

drag — Sat, 04 Oct 2008 08:52:10 +0000

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

drag — Sat, 04 Oct 2008 08:44:42 +0000

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.

Phantom menace? Threat that, so far, has not existed? Sorry - you are DEAD wrong.

drag — Sat, 04 Oct 2008 08:41:54 +0000

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.

Phantom menace? Threat that, so far, has not existed? Sorry - you are DEAD wrong.

khim — Sat, 04 Oct 2008 07:25:56 +0000

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.

Any such library can be reimplemented

khim — Sat, 04 Oct 2008 07:11:22 +0000

...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...

That's different point from mine

khim — Sat, 04 Oct 2008 07:07:58 +0000

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.

No - you got it backwards!

khim — Sat, 04 Oct 2008 07:00:54 +0000

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.

LGPL was never at risk

jordanb — Sat, 04 Oct 2008 04:30:49 +0000

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.

[1] http://en.wikipedia.org/wiki/The_Wind_Done_Gone