GCC, LLVM, and compiler plugins

Posted Jan 30, 2014 13:52 UTC (Thu) by nix (subscriber, #2304)
In reply to: GCC, LLVM, and compiler plugins by kugel
Parent article: GCC, LLVM, and compiler plugins

I disagree with that. When I write a proper C program that does not depend on any of GCC extensions and I can compile it fine with a different compiler, then compilation with GCC of that program doesn't make that program derivate work. Whether GCC builds a runtime library into the program is the choice of GCC and an implementation detail,

Copyright law does not talk about 'implementation details'. What matters is the direct textual inclusion of work licensed under two different licenses into a single aggregate, which has definitely happened when libgcc is linked into a binary under another license: that sort of inclusion is what linkers do.

Fortunately, the runtime library exception makes this sort of use not a problem: libgcc's use only imposes extra requirements on proprietary software distributors if they hack libgcc (in which case they must distribute the source to the hacked copy, and its build system).

GCC, LLVM, and compiler plugins

Posted Jan 30, 2014 14:57 UTC (Thu) by madscientist (subscriber, #16861) [Link]

Put another way: yes, absolutely compiling with GCC doesn't cause _your source code_ to come under the GPL. However, _the generated binary_ output from the GCC linker contains copyrighted code from the FSF licensed under the GPL, and so if you redistribute that you have to obey the GPL license, and that license puts requirements you to distribute the source code, which is perfectly legal (insofar as anyone knows).

If you take your code and compile it with a different compiler then you can do whatever you want with THAT binary.

But as nix points out, the entire discussion is moot since the GCC license contains exceptions exactly for this situation.

GCC, LLVM, and compiler plugins

Posted Jan 30, 2014 16:30 UTC (Thu) by marcH (subscriber, #57642) [Link] (22 responses)

> What matters is the direct textual inclusion of work licensed under two different licenses into a single aggregate,

The GPL is quite clear that it does not really care about aggregation.

The real question is about what makes a "Derivative Work" and - like Kugel and many others wrote - it is a quite complex and still debated question.

GCC, LLVM, and compiler plugins

Posted Jan 30, 2014 17:22 UTC (Thu) by vonbrand (subscriber, #4458) [Link] (6 responses)

GPL could say it cares about mere aggregation until it was blue in the face, that wouldn't change anything: The law says mere aggregation doesn't matter. Likewise, what RMS would like to mean by "derivative" is totality irrelevant. It would have to be decided by a court.

GCC, LLVM, and compiler plugins

Posted Jan 30, 2014 18:00 UTC (Thu) by marcH (subscriber, #57642) [Link] (1 responses)

A license is not a law

GCC, LLVM, and compiler plugins

Posted Jan 31, 2014 15:05 UTC (Fri) by nix (subscriber, #2304) [Link]

The license only has any force because copyright law says it does.

GCC, LLVM, and compiler plugins

Posted Jan 30, 2014 19:35 UTC (Thu) by DOT (subscriber, #58786) [Link] (2 responses)

A license can say that you may only use or distribute the program if you don't wear purple pajamas. It can't forbid your wearing of purple pajamas at all, but it can forbid using or distributing the program in that case. In the same way, it can put whatever restrictions on your use or distribution of the program in case you do it together with another, proprietary, program. This is not dependent on any standard definition of derivative work or any law whatsoever: it can attach any restrictions to the use of the program.

GCC, LLVM, and compiler plugins

Posted Jan 30, 2014 20:34 UTC (Thu) by vonbrand (subscriber, #4458) [Link] (1 responses)

Licenses like GPL operate in the range regulated by copyright law. If the PPL says the software can't be used unless wearing purple pajamas, that restriction is void as copyright doesn't cover use, only copying and distribution. Likewise, coyright covers copying of a particular work, not if it is shipped together with other stuff (unless it becomes a part of a greater whole, in which case you are talking about coyright on the collection as such). And I believe there are some "reasonableness" conditions in what the license might demand.

In what is wrongly called "software licenses" (which are really contracts) you can agree to more stringent conditions.

GCC, LLVM, and compiler plugins

Posted Jan 30, 2014 20:44 UTC (Thu) by DOT (subscriber, #58786) [Link]

Right, my mistake. Still, this only changes my argument slightly: a copyright license can still demand anything in return for giving you permission to copy or distribute. It may demand that you don't link it with proprietary software just like it may demand that you wear purple pajamas while doing the distributing.

This does restrict the power of the GPL: it cannot say anything about linking the program with a proprietary one on you own system. But it can say just fine that it considers such linking a BadThing, and it may not be distributed while it is a BadThing.

GCC, LLVM, and compiler plugins

Posted Jan 30, 2014 22:39 UTC (Thu) by madscientist (subscriber, #16861) [Link]

I'm not sure what you mean regarding the GPL: the GPL doesn't try to enforce itself in a "mere aggregation" situation: http://www.gnu.org/licenses/old-licenses/gpl-2.0-faq.html...

> Likewise, what RMS would like to mean by "derivative" is totality irrelevant.

Well, it is VERY relevant in at least one way: it lets people using the software understand what the license holder considers the license to be, and THAT lets them know what behaviors are likely to cause them to face some sort of legal action from the FSF.

And, believe me, that's no small thing.

Sure, maybe the courts would decide the FSF is full of it. But so far we haven't seen anyone (in the US) willing to step up and take that risk, for whatever reason. One reason might be that their legal teams tell them it's a bad bet.

GCC, LLVM, and compiler plugins

Posted Jan 30, 2014 22:33 UTC (Thu) by madscientist (subscriber, #16861) [Link] (14 responses)

nix's use of the term "aggregate" was unfortunate; I don't think he meant it in the legal sense of "mere aggregation". He meant it in the English language sense of "things put together".

It's pretty clear (I think) that a binary linked with libgcc is NOT a "mere aggregation" since if you remove libgcc the entire thing is useless and inoperable.

GCC, LLVM, and compiler plugins

Posted Jan 30, 2014 23:51 UTC (Thu) by marcH (subscriber, #57642) [Link] (13 responses)

> It's pretty clear (I think) that a binary linked with libgcc is NOT a "mere aggregation" since if you remove libgcc the entire thing is useless and inoperable.

I don't think this is even relevant. If you push this logic further you eventually come to the conclusion that statically linking has different licensing implications from dynamically linking - even to the exact same library. Reading the GPL from some distance it does not look like its initial authors intended something that silly.

Licenses/contracts have one thing in common with laws: since they are written in natural languages they need to be interpreted; in the worst cases in a court. Such interpretations always take into account the intentions of the parties involved, including the intentions of the license authors.

The "spirit" of the GPL is clearly about the high-level, business question: "Is this software reusing GPL work / does it have a hard dependency on GPL work in some way"? as opposed to low-level engineering details like different linking techniques or network protocols between modules. Arguing otherwise is basically pretending that the authors of the GPL were idiots completely missing their own point. I don't think they were.

All this being said, with what you can see happening with patents there is of course still a good chance that any BS interpretation of the GPL out there could be validated in some court (and then invalidated in another).

Going full circle: yes I think the libgcc exception looks pointless, missing the philosophy of the GPL. Useless and harmless.

GCC, LLVM, and compiler plugins

Posted Jan 31, 2014 1:46 UTC (Fri) by artem (subscriber, #51262) [Link] (12 responses)

Static linking obviously has different implications when you are distributing the binary. If linked statically, you are distributing bits from the library. If linked dynamically, you can distribute only your own bits, and tell your recipients to get library bits themselves. Look at the difference between GPL and LGPL - does it seem silly to you too?

GCC, LLVM, and compiler plugins

Posted Jan 31, 2014 7:59 UTC (Fri) by marcH (subscriber, #57642) [Link] (11 responses)

> Static linking obviously has different implications when you are distributing the binary.

No, static versus dynamic linking does not make any "obvious" difference with respect to the GPL. In fact the FSF argues the exact opposite.

"- Hi, is your program/work combined with any GPL code?
- No, it's not, I used dynamic linking as a workaround. Now don't forget to make sure you have libGPLx.so and libGPLy.so installed; without these there is not a chance it can work"

Do I find this made up example completely ridiculous and nonsensical? Yes. Could some red-neck court validate this anyway? Sure, why not? The sky is the limit.

This question has been debated a million times already, let's not do it once again. Just Google "GPL+dynamic+linking"

https://www.gnu.org/licenses/lgpl-java.html

> Look at the difference between GPL and LGPL - does it seem silly to you too?

The LGPL is not defined in terms of static versus dynamic linking.

GCC, LLVM, and compiler plugins

Posted Jan 31, 2014 13:59 UTC (Fri) by mathstuf (subscriber, #69389) [Link]

Without the text here, IIRC, the LGPL states something along the lines of that the LGPL portion must be replaceable by the end user. In practice, this is easy for shared but hard for static builds (as you'd have to ship you intermediate .a files per platform to avoid source).

GCC, LLVM, and compiler plugins

Posted Jan 31, 2014 14:44 UTC (Fri) by oshepherd (guest, #90163) [Link] (9 responses)

Lets just say, for the purposes of example, that said GPLed library was libgcc.so.0 (We will ignore the existence of the runtime library exception for the purposes of this example)

Is my program bound by the terms of the GPL just because it was compiled with GCC, which linked it against libgcc.so.0?

What about if on <my|one of my user's> systems, libgcc.so.0 is a symlink to libcompiler-rt.so.0? We will note that the latter is under the MIT/X11 license.

One would not argue that Compiler-RT is derivative of libgcc, in spite of implementing exactly the same interface. (In fact to do so would be to claim that an API is copyrightable, which is both preposterous and has been proven false in at least one jurisdiction (the US))

What about if my application was linked against libgcc.so.0 in the year 2001, long before Compiler-RT was created as a project?

I find it hard to reconcile this collection of situations into a consistent rule set which doesn't imply that the claimed restrictions of the GPL on dynamic linking may be an exaggeration of the truth.

YMMV. IANAL, and all that.

GCC, LLVM, and compiler plugins

Posted Jan 31, 2014 21:17 UTC (Fri) by marcH (subscriber, #57642) [Link] (8 responses)

When confusion reigns, it can be useful to take a giant step back. AFAIK the founding principle of the GPL is: if you take (something GPL) then you must give back (to the GPL community). I think it's quite clear that this is the rationale behind the "Derived Work" / "Combined Work" wording.

Joe is maintaining a very portable and closed source C application that runs on AIX and Solaris. One day his boss asks him to compile it on Linux for some new customers. Thanks to the good people at POSIX everything just works. Without Joe realizing it, GCC has sneaked some statically linked libgcc binary into his program (most developers have never heard about things like libgcc). Then he ships his closed source application as a binary to his Linux customers.

Joe never touched GCC or any GPL software before. Even though he did not change one line in his application he now has to give his entire program "back" to the GPL community because of some (irrelevant) implementation detail he did not even need to be aware of? Sorry but that does not make any kind of sense. Joe did not take anything from the GPL community. You could rather argue he made the effort to support GNU/Linux.

Of course not every case is that simple. Yet this is one is perfectly realistic and makes the libgcc exception ridiculously pointless.

GCC, LLVM, and compiler plugins

Posted Jan 31, 2014 21:43 UTC (Fri) by anselm (subscriber, #2796) [Link] (7 responses)

It is a very widespread belief that distributing a proprietary program that includes GPLed parts means that the whole program must be put under the GPL. That belief is, however, incorrect.

You never »have to give your entire program to the GPL community« if you inadvertently distributed it with some GPL code linked into it. Putting your own code under the GPL is just one of the options; you can also remove the GPL code in question and replace it with something under a more suitable license, or negotiate a separate license deal with the copyright holder(s).

In the GCC case, the libgcc license contains explicit language allowing you to link your stuff with libgcc and propagate the result, so as far as GCC is concerned the issue is moot, anyway.

GCC, LLVM, and compiler plugins

Posted Feb 1, 2014 11:22 UTC (Sat) by hummassa (subscriber, #307) [Link] (6 responses)

Anyway, the example is weird, and it's easily shown:

Joe is maintaining a very portable and closed source C application that runs on AIX and Solaris. One day his boss asks him to compile it on Windows for some new customers. Thanks to the good people at POSIX everything just works. Without Joe realizing it, MSVC has sneaked some statically linked msvcrt binary into his program (most developers have never heard about things like libgcc). Then he ships his closed source application as a binary to his Windows customers.

Joe never touched Microsoft software before. Even though he did not change one line in his application he now has to obey arbitrary Microsoft licensing terms? Sorry but that does not make any kind of sense. Joe did not take anything from Microsoft. You could rather argue he made the effort to support Windows.

Now, even if libgcc was 100%, just-GPL, don't let proprietary software near me, it's Joe's boss responsibility to follow the license for some software his company uses. Because it would be a liability to do otherwise... It is quite simple.

GCC, LLVM, and compiler plugins

Posted Feb 1, 2014 12:39 UTC (Sat) by khim (subscriber, #9252) [Link] (3 responses)

Joe did not take anything from Microsoft.

Really? Where exactly msvcrt comes from?

You could rather argue he made the effort to support Windows.

Does not matter. He shipped code made by Microsoft, he must play by Microsoft rules.

It's not a new development. Think dBase II (thirty years old by now): if you compile you program using dBase II compiler and want to ship the resulting .exe you need to pay royalty! Even if you didn't knew anything about Ashton-Tate and wrote you program without prior knowleadge of dBase (pretty hard to do in 1981, but we are talking hyphothetical possibilities here, right?)—you still need to pay royalty because said .exe includes bits and pieces owned by Ashton-Tate!

License fee for runtime package may not be common today (software is cheaper today as a matter of course, some is even free), but it was the norm half-century ago. And if law can force you to pay actual money for the privilege (the ability to actually ship compiled binary is a privilege not right as law is concerned!) then why it can not force you to do other things, too?

GCC, LLVM, and compiler plugins

Posted Feb 6, 2014 9:51 UTC (Thu) by hummassa (subscriber, #307) [Link]

whooosh? The sound of the parody I made passing over?

My point exactly. GPL's terms + copyright law = if you want to distribute it, follow the terms of the license.

GCC, LLVM, and compiler plugins

Posted Feb 6, 2014 18:59 UTC (Thu) by Wol (subscriber, #4433) [Link] (1 responses)

This dBase II example is hilarious, given that there is a pretty nice sting in the tale :-)

You do know that the original dBase was Public Domain, don't you? And there was a lawsuit over copying, which Ashton Tate pretty resoundingly lost ...

Cheers,
Wol

GCC, LLVM, and compiler plugins

Posted Feb 6, 2014 19:54 UTC (Thu) by khim (subscriber, #9252) [Link]

Said lawsuid had nothing to do with dBase runtime and everything to do with dBase language and file format. Basically Ashton-Tate wanted to outlaw Clipper and FoxPro and failed. This defeat meant you could use Clipper runtime for free but if you wanted to use orginal dBase II runtime for whatever reason you still needed to pay even after that “resounding defeat”. And of course all that happened much, much later in an era of dBase IV, not dBase II.

GCC, LLVM, and compiler plugins

Posted Feb 1, 2014 13:25 UTC (Sat) by marcH (subscriber, #57642) [Link] (1 responses)

Since when Microsoft licences have anything in common with the GPL??

GCC, LLVM, and compiler plugins

Posted Feb 2, 2014 0:49 UTC (Sun) by mathstuf (subscriber, #69389) [Link]

That you must conform to the terms and conditions before redistributing?