A new GCC runtime library license snag?
| Benefits for LWN subscribers The primary benefit from subscribing to LWN is helping to keep us publishing, but, beyond that, subscribers get immediate access to all site content and access to a number of extra site features. Please sign up today! |
The saga of the GCC runtime library has been covered here a couple of times in the past. The library's license is a legal hack which tries to accomplish a set of seemingly conflicting goals. The GCC runtime library (needed by almost all GCC-compiled programs) is licensed under GPLv3; that notwithstanding, the Free Software Foundation wants this library to be usable by proprietary programs - but only if no proprietary GCC plugins have been used in the compilation process. The runtime library exception published by the FSF appears to have accomplished those objectives. But now it seems that, perhaps, the GCC runtime licensing has put distributors into a difficult position.
The problem has to do with programs which are licensed exclusively under version 2 of the GPL. Examples of such programs include git and udev, but there are quite a few more. The GPLv3 licensing of the GCC runtime library (as of version 4.4) would normally make that library impossible to distribute in combination with a GPLv2-licensed program, since the two licenses are incompatible. The runtime library exception is intended to make that problem go away; the relevant text is:
So, as long as the licensing of the "Independent Modules" (the GPLv2-licensed code, in this case) allows it, the GCC runtime library can be distributed in binary form with code under a GPLv3-incompatible license. So there should not be a problem here.
But what if the licensing of the "Independent Modules" does not allow this to happen? That is the question which Florian Weimer raised on the GCC mailing list. The GCC runtime library exception allows that code to be combined with programs incompatible with its license. But, if the program in question is covered by GPLv2, the problem has not been entirely resolved: GPLv2 still does not allow the distribution of a derived work containing code with a GPLv2-incompatible license. The GPLv3 licensing of the runtime library is, indeed, incompatible with GPLv2, so combining the two and distributing the result would appear to be a violation of the program's license.
The authors of version 2 of the GPL actually anticipated this problem; for that reason, that license, too, contains an exception:
This is the "system library" exception; without it, distributing binary copies of GPLv2-licensed programs for proprietary platforms would not be allowed. Even distributing a Linux binary would risk putting the people distributing the program in a position where they would have to be prepared to provide (under a GPLv2-compatible license) the sources for all of the libraries used by the binary. This exception is important; without it, distributing GPLv2-licensed programs in binary form would be painful (at best) or simply impossible.
But note that the exception itself contains an exception: "unless
that component itself accompanies the executable.
" This says that,
if somebody distributes GCC together with a GPLv2-licensed program, the
system library exception does not apply to the code which comes from GCC.
And that includes the GCC runtime library. One might think that tossing a
copy of the compiler into the distribution of a binary program would be a
strange course of action, but that is
exactly what distributors do. So,
on the face of it, distributors like Debian (which, naturally, turned up
this problem) cannot package GPLv2-licensed code with the GCC 4.4 runtime
library without violating the terms of GPLv2.
This is a perverse result that, probably, was not envisioned or desired by the FSF when it wrote these licenses. But Florian reports that attempts to get clarification from the FSF have gone unanswered since last April. He adds:
One could argue that the real problem is with the GPLv2 system library exception-exception. That (legal) code was written in a world where there were no free operating systems or distributors thereof, and where nobody was really thinking that there could be conflicting versions of the GPL. Fixing GPLv2 is not really an option, though; this particular problem will have to be resolved elsewhere. But it's not entirely clear where that resolution could be.
A statement from the FSF that, in its view, distributing GPLv2-licensed binaries with the GPLv3-licensed GCC runtime library is consistent with the requirements of both licenses might be enough. But such a statement would not be binding on any other copyright holders - and it is probable that the bulk of the code which is not making the move to GPLv3 is not owned by the FSF. A loosening of the licensing on the GCC runtime library could help, but this is a problem which could return, zombie-like, every time a body of library code moves to GPLv3. It's a consequence of the fundamental incompatibility between versions 2 and 3 of the license.
This has the look of the sort of problem that might ordinarily be studiously ignored into oblivion. If one avoids the cynical view that the FSF desires this incompatibility as a way of pushing code toward GPLv3, it's hard to see a situation where a copyright holder would actually challenge a distributor for shipping this particular combination. But the Debian Project is not known for ignoring this kind of issue. So we may well be hearing more about this conflict in the coming months.
(Thanks to Brad Hards for the heads-up on this issue).
(Log in to post comments)
A new GCC runtime library license snag?
Posted Jul 27, 2009 21:53 UTC (Mon) by Baylink (guest, #755) [Link]
Sometimes, you can leverage your loving audience into doing the things you want them to do; sometimes not so much. This might be a "not so much" time.
Don't get me wrong: just as in politics, we *need* people at all points in the ideological spectrum: though no one uses the Hurd, if rms hadn't written the GPL to be hardcore enough that companies waste money on lawyers debating whether it will infect their business, then Linux wouldn't be where it's at today; I firmly believe that, and I've been running open source code since my newsfeed came in at 1200bps and I could read all of it.
A new GCC runtime library license snag?
Posted Jul 28, 2009 7:39 UTC (Tue) by rsidd (subscriber, #2582) [Link]
A new GCC runtime library license snag?
Posted Jul 29, 2009 1:22 UTC (Wed) by Baylink (guest, #755) [Link]
A new GCC runtime library license snag?
Posted Jul 29, 2009 8:05 UTC (Wed) by rsidd (subscriber, #2582) [Link]
A new GCC runtime library license snag?
Posted Aug 2, 2009 1:30 UTC (Sun) by landley (guest, #6789) [Link]
Eric got the idea for the paper at a conference in 1996, which is described in some detail here:
A new GCC runtime library license snag?
Posted Aug 2, 2009 1:34 UTC (Sun) by landley (guest, #6789) [Link]
Tinycc was aiming to be a third one, but it died. (The corpse lurches onward zombie-like as a windows compiler, but is unlikely to ever amount to anything on Linux. Alas.)
Rob
A new GCC runtime library license snag?
Posted Aug 2, 2009 5:15 UTC (Sun) by rsidd (subscriber, #2582) [Link]
A new GCC runtime library license snag?
Posted Aug 2, 2009 7:11 UTC (Sun) by landley (guest, #6789) [Link]
> intervals (the last on May 20, 2009).
Fabrice didn't make that release, Griscka did. Fabrice just uploaded it. Fabrice dropped tinycc to work on QEMU, and the project stalled years ago. He still drops by the mailing list about once a year (I believe his most recent post to the list was 15 months ago, and the last post before that was 24 months ago).
Well over half of the work in the .24 release was either stuff done after the previous release back before Fabrice lost interest, stuff I collected and sent to Fabrice back at the start of my fork (back around 2006), or stuff Grischkah ported over from my fork. Grisckha primarily does work on the windows target, not on Linux. (Grishcka literally said that he didn't port of a lot of the work in my fork because he didn't understand it. Not that he'd asked.)
The only real non-Windows work in the .25 release I'm aware of was somebody in Japan popping up out of nowhere with an x86-64 backend at the start of this year, not anything that came from any existing developers on the list. They had a release because somebody dropped an x86-64 target in their laps out of the blue, not because of any work done on the list. (Not that the tcc codebase they're using is 64 bit clean, but you can sort of fake it if you're only building toy programs.)
> He also links to your fork.
My fork's long dead, as explained on the page they (still) link to.
> Is it uninteresting because it offers insufficient scope for
> optimisation?
It's uninteresting because five years ago, Fabrice came up with a specific list of things required to build an unmodified (2.4) Linux kernel, and it still can't do it today, and making it do it isn't a goal of the current developers (let alone building 2.6, busybox, and uClibc):
http://bellard.org/tcc/tccboot_readme.html
Note that building a 2.6 kernel is harder than building a 2.4 kernel. The two big pieces of infrastructure missing are variable length arrays and simple dead code elimination, and neither is currently under active development. (I was working on both when they drove me off, now I don't care.)
For a couple years there, I did more work on it than the rest of the tcc development community combined. (Not because I really had time or expertise, but because nobody ELSE was doing it.) Since I left, except for the guy who added the x86-64 target, the rest of the development community has implemented the occasional bugfix. Maybe it's changed in the past few months, I haven't been paying attention, but list traffic was still mostly bug reports from windows people last I checked. (The project's mailing list often went weeks between posts, and the majority of the traffic was about Windows. Not very interesting.)
> People who want to use C in the first place care more about fast
> binaries than fast compilation, and if development time (as in
> compilation time and other things) is more important than runtime speed,
> there are other and better languages, it seems to me.
Sure. But the compiler/interpreter/runtime for those languages are implemented in C. If you're creating a self-bootstrapping environment, you need a C compiler.
What attracted me to tinycc is that it was _simple_. The entire compiler is about 100k lines of source, it just needed a huge cleanup and refactoring to be extended to support multiple architecture targets, build a full Linux kernel, be maintainable by anybody but its original author...
What I really wanted to do was refactor tinycc into a busybox-like swiss army knife executable providing "ld", "cc", "as", "strip", and so on so it could properly replace gcc and binutils. It would also be good to look into using qemu's new code generator (tcg) as the back-end rather than trying to maintain a dozen processor targets with a half-dozen variants each.
But the existing tinycc development community has little interest in doing any new work on it. Change to existing code seems to upset them.
The smallest self-bootstrapping Linux system is, theoretically, the linux kernel, uClibc, a swiss-army-knifed tcc, and busybox extended a bit to include things like "make" and a bash replacement sh. Alas, in the past 5 years we haven't come noticeably closer to that happening.
Rob
A new GCC runtime library license snag?
Posted Jul 27, 2009 21:57 UTC (Mon) by johill (subscriber, #25196) [Link]
The really stupid part is how the FSF is trying to ignore the problem – you could think they've stopped caring about their users.
A new GCC runtime library license snag?
Posted Jul 28, 2009 2:17 UTC (Tue) by sbergman27 (guest, #10767) [Link]
I want Minix's size but Linux's functionality....
Posted Jul 28, 2009 3:39 UTC (Tue) by coriordan (guest, #7544) [Link]
What would you do differently in the licences?
I want Minix's size but Linux's functionality....
Posted Jul 28, 2009 8:45 UTC (Tue) by rsidd (subscriber, #2582) [Link]
I predict that rather than accept forced licence changes, people will fork the project (as happened to XFree86) or move on to other alternatives like LLVM.
I want Minix's size but Linux's functionality....
Posted Jul 28, 2009 18:50 UTC (Tue) by coriordan (guest, #7544) [Link]
What part of GPLv3 is bad?
I want Minix's size but Linux's functionality....
Posted Jul 28, 2009 20:06 UTC (Tue) by sbergman27 (guest, #10767) [Link]
GPLv2 still encompasses too much complexity. But the level of complexity is at least arguably worth it. GPLv3 adds far complexity just to add some "refinements". ("Refinements" which the long and bitter debate made clear that *many* do not even like or agree with.)
But in general, when the FSF, after excruciatingly drawn out deliberation, can't seem to keep their own new license clauses from conflicting with their other licenses... that's a pretty strong indication of a problem. It's the same kind of situation as when your spaghetti code, which seemed like such a good idea when you were writing it, starts catching up with you and your programming life turns into a living nightmare.
That perfect GPLv2
Posted Jul 28, 2009 21:32 UTC (Tue) by coriordan (guest, #7544) [Link]
Now the previously too-long GPLv2 has become "just right" and GPLv3 is the target of "make it shorter!" - I too wish that we could have it on the back of a beermat, but which unnecessary sentences should be removed?
That perfect GPLv2
Posted Jul 28, 2009 22:19 UTC (Tue) by sbergman27 (guest, #10767) [Link]
Now the previously too-long GPLv2 has become "just right"...
"""
GPLv2 is still too long. But its length is, at least, defensible.
"""
but which unnecessary sentences should be removed?
"""
Honestly? This should do:
diff -u GPLv3.txt GPLv2.txt
(Make sure you have enough RAM + swap.)
The result is well tested, relatively bug free, and has a feature set which most people were reasonably happy with. Do we really have to wreck everything just to get back at Tivo?
That perfect GPLv2
Posted Jul 29, 2009 0:55 UTC (Wed) by jordanb (guest, #45668) [Link]
Clearly the solution for the FSF is to produce a GPLv4, thus rendering the GPLv3 "too long but defensible."
That perfect GPLv2
Posted Jul 29, 2009 0:47 UTC (Wed) by bronson (subscriber, #4806) [Link]
Ciaran, You and I had some back-and-forths right here on LWN back in the day. I was practically begging the FSF to remove the Tivoization language because, in my opinion, it was contorting the GPLv3 into a monster that only professional lawyers could understand. Ah, those were good times.
(I think I also mentioned on how painful it was to try to hold a conversation on the GPLv3's automated comment system. This explains my lack of feedback there anyway... Ii was like trying to critique a painting using a web form that only allows comments on individual colors.)
Ah well, water under the bridge. I still totally support the FSF. I do avoid the GPLv3 when I can, though, since I still don't completely understand it. If you'd like to discuss reducing the size of the GPLv3 by reducing its scope, rather than by shortening individual sentences, I'd be overjoyed to reopen that discussion.
That perfect GPLv2
Posted Jul 29, 2009 12:05 UTC (Wed) by DonDiego (guest, #24141) [Link]
> target of "make it shorter!"
No, both should be shorter, version 3 just makes the problem worse.
GPL version 3 problems
Posted Jul 29, 2009 12:01 UTC (Wed) by DonDiego (guest, #24141) [Link]
Have you read and understood it? I think I can confidently claim that I understand version 2 quite well, but version 3 gives me headaches.
I still don't get the difference between "conveying" and "propagating" after reading those paragraphs about a dozen times. Version 2 is hard enough to understand for laymen, but version 3 is a readability and complexity disaster, sorry.
Read GPL version 1, 2 and 3 one after the other. The bloat^wcomplexity keeps increasing and version 3 finally does not appear to have programmers, but legal experts as its core audience. This is sad. The same effect could have been achieved with less words and much clearer language.
how v3 is much much simpler
Posted Jul 29, 2009 18:44 UTC (Wed) by coriordan (guest, #7544) [Link]
When a company places an internet-connected, sealed box, which continues to belong to them, in your house for a fixed period of time, and that box contains a computer running GNU/Linux, did the company "distribute"? That's the problem. While I do have a general idea, I don't know what exact meaning that word has in Ireland, the UK, USA, Australia, New Zealand, Canada... And when you translate it, all bets are off.
That makes uncertainty because that company can say they're not "distributing", so I'm worried about going to court, and worse, if I do go to court, the judge might even agree that, by the legal definition of that country, they're indeed not "distributing".
GPLv3 makes things simpler because I no longer have to know or guess the meaning of "distribute" in every country. "Propagate" and "convey" were chosen specifically because they have no existing meanings with regard to software. This means that the licence can explain the intended meaning. So I just read the licence. The licence *text* itself is more complex, but overall, knowing what the licence really means is much much easier.
how v3 is much much simpler
Posted Jul 29, 2009 20:51 UTC (Wed) by bronson (subscriber, #4806) [Link]
Well that's a relief! Since figuring out what the GPLv3 really means is so much easier, it must be simple to answer the license snag brought up by this article?
Fatal oversight
Posted Jul 30, 2009 5:21 UTC (Thu) by khim (subscriber, #9252) [Link]
Well that's a relief! Since figuring out what the GPLv3 really means is so much easier, it must be simple to answer the license snag brought up by this article?
Have you even read the article? Yup. Sure. Absolutely. When Git and udev will switch to GPLv3 it'll be easy. But till then we are stuck: the problem discussed is related to the fact that GPLv2 uses unprecise definitions and so it's impossible to fix it wihout changing the GPLv2 text or adding some explanations to it. Since FSF is not a copyright holder of Git/udev/etc it's hard to see what the hell FSF can do here.
Fatal oversight
Posted Jul 30, 2009 12:40 UTC (Thu) by foom (subscriber, #14868) [Link]
Well, there's certainly one obvious and trivially correct thing they could do...
Change the license on libgcc to GPLv2+ :)
Fatal oversight
Posted Jul 31, 2009 8:15 UTC (Fri) by mjthayer (guest, #39183) [Link]
Fatal oversight
Posted Jul 30, 2009 16:03 UTC (Thu) by bronson (subscriber, #4806) [Link]
I did read the article so, yep, I know that it brought up more issues than this one. You read the whole thing too, right?
If the problem were truly that the GPLv2 uses imprecise terminology then all the FSF has to do is release a GPL2.1 with language bugfixes, or even just an addendum describing language intent.
> Since FSF is not a copyright holder of Git/udev/etc it's hard to see what the hell FSF can do here.
There are two sides to every integration problem. The most obvious thing the FSF can do is, gosh, simply let the runtime library be usable anywhere. Or, they could roll back to the 2008 license, probably with *minor* changes: http://lwn.net/Articles/316835/ (like foom says)
I'm sure they have other options too.
Fatal oversight
Posted Jul 30, 2009 16:18 UTC (Thu) by jordanb (guest, #45668) [Link]
They did release an update to the GPL fixing language ambiguities. The copyright holders in question chose not to move to it, either because they had a belief that it 'overreached' or they had removed the 'or later version' clause and now find it too much bother to do a license change.
Maybe a "2.1" would placate some who feel that GPLv3 "overreached" (I doubt it) but it would do nothing to address the second case. The vast majority of the software that's still under GPLv2 would not move to a newer license even if the changes were minor.
> or even just an addendum describing language intent.
This would not be binding on copyright holders not a party to the 'addendum'. (Which is to say, it would only apply to the FSF, which would make it totally irrelevant because all the FSF code is under GPLv3.)
Here we go again...
Posted Jul 31, 2009 7:25 UTC (Fri) by khim (subscriber, #9252) [Link]
If the problem were truly that the GPLv2 uses imprecise terminology then all the FSF has to do is release a GPL2.1 with language bugfixes
They did so - it's called GPLv3.
even just an addendum describing language intent.
There are no need to do this for FSF-licensed software (GPLv3 serves as such clarification) and "addenum" will not be automatically attached to the text of license used by git/udev/etc.
The most obvious thing the FSF can do is, gosh, simply let the runtime library be usable anywhere.
It is useful anywhere (for free and proprietary programs alike) - where other side does not prohibit it.
Or, they could roll back to the 2008 license, probably with *minor* changes: http://lwn.net/Articles/316835/ (like foom says). I'm sure they have other options too.
I see no such options - except one: return back to the GPLv2. And FSF surely will do no such things. Reasons were explained well in advance. This switch was planned more then two years ago - if people wanted to raise racket the time was back in 2007, not today.
Here we go again...
Posted Aug 6, 2009 10:10 UTC (Thu) by SEMW (guest, #52697) [Link]
Of course it's "useful anywhere... where the other side does not prohibit it". But the point is that it is written in such a way that the GPL v2 -- a widely used and free license -- *does* prohibit it (if the runtime library is distributed with the binary). To plead that this is the GPL2's fault is trivially true, but missing the point (in a similar way to Joerg Shilling's defending Sun's use of the GPL-incompatible CDDL on the grounds that it's a completely free license, and if the FSF thinks it's incompatible with the GPL, that's not Sun's problem).
> if people wanted to raise racket the time was back in 2007, not today.
That is bordering on disingenuous. As you know, no-one noticed this problem in 2007, it's only just been pointed out.
This is not GPLv2 fault, sorry...
Posted Aug 9, 2009 11:58 UTC (Sun) by khim (subscriber, #9252) [Link]
But the point is that it is written in such a way that the GPL v2 -- a widely used and free license -- *does* prohibit it (if the runtime library is distributed with the binary).
Nope. It does not prohibit anything if you apply it correctly. Please read GPLv2 - specifically paragraph 9. GPLv3 does the same in paragraph 14. The problems only arise when someone applies GPLv2 in such a way as to create the problems - but then the conventional wisdom says it's not a problem of GPL...
To plead that this is the GPL2's fault is trivially true, but missing the point (in a similar way to Joerg Shilling's defending Sun's use of the GPL-incompatible CDDL on the grounds that it's a completely free license, and if the FSF thinks it's incompatible with the GPL, that's not Sun's problem).
I can't see your point. In both cases copyright owners did what they thought was right. The results are unfortunate: Linux does not include ZFS as the result, Git should be compiled with GCC 4.3.
The situation was somewhat different in these two cases: Sun's decision created problem immediately, Git's developer's decision created problem few years down the road - but it's not like they had no warning: indeed, the warning is embedded in the very text of the license they've used!
This is not GPLv2 fault, sorry...
Posted Aug 12, 2009 12:36 UTC (Wed) by SEMW (guest, #52697) [Link]
Being there and being apparent are very different things. The current problem is as a result of an interaction between the gcc runtime exception and the GPLv2 that, whilst it was in a trivial sense there all along, no-one had noticed until Kalle Niemitalo pointed it out very recently. (If I am mistaken and it was, in fact, known before, please say so; as I said in the other thread, the story does not give that impression).
You can study ZFC for quite a while without deducing Fermat's last theorem, even though it is a logical consequence of them. And the fact that the two licenses interact in this way might have been there all along, but it was apparently sufficiently non-obvious that, yes, the git developers could certainly be said to have had no warning.
how v3 is much much simpler
Posted Jul 30, 2009 10:17 UTC (Thu) by rsidd (subscriber, #2582) [Link]
how v3 is much much simpler (after taking a hit from the crack pipe)
Posted Jul 30, 2009 19:07 UTC (Thu) by DonDiego (guest, #24141) [Link]
> meaning of "distribute" in every country.
At least I could understand the license in *one* country with v2..
> "Propagate" and "convey" were chosen specifically because they have no
> existing meanings with regard to software. This means that the licence can
> explain the intended meaning.
I wish it did explain the intended meaning. Have you understood the intended meaning and difference between "propagate" and "convey"? I still fail to clearly see a difference and the GPL FAQ obscures the point further.
> So I just read the licence. The licence *text* itself is more complex,
> but overall, knowing what the licence really means is much much easier.
This is a contradiction. A complex text, by its nature, lends itself more to different interpretations than a clear and simple one. How can you now be sure that your interpretation is the intended one? And who guarantees that a judge will not disagree?
But the main problem remains: The target audience seems to have shifted from laypersons to experts in reading legalese. This is very sad and counterproductive. I myself will not release code under v3 for the foreseeable future and will not suggest using v3 to anybody, maybe even recommend to stay away from it when asked for licensing advice. I bet I am far from the only person that thinks so and I do not see people around me rushing to adopt v3, on the contrary. This cannot have been what the authors of v3 had in mind.
I shudder when I think what v4 or v5 might look like...
I want Minix's size but Linux's functionality....
Posted Jul 30, 2009 5:36 UTC (Thu) by grahammm (guest, #773) [Link]
I want Minix's size but Linux's functionality....
Posted Aug 1, 2009 0:05 UTC (Sat) by coriordan (guest, #7544) [Link]
The combination of binary runtime library plus binary git (or any gplv2 application) can be distributed. And the recipient reads the licence of git and sees that she's entitled to a copy of the complete corresponding source code under the terms of the GPLv2... but she can't have the source code to the runtime library (which is part of git after compilation) under GPLv2 because the runtime library's licence is GPLv3, not GPLv2.
It's an interesting path alright, and I'm thinking about other types of clauses that could go into the runtime library exception along the same lines....
Some clarifications
Posted Jul 27, 2009 22:14 UTC (Mon) by JoeBuck (subscriber, #2330) [Link]
There is no possible issue with any GPLv2+ ("GPLv2 or any later version") code, and all FSF-owned code either is GPLv2+ or GPLv3+. The question is whether there is an issue for GPLv2-only code. Even then, the system library exception in GPLv2 makes the issue moot for most; the problem (if any) can exist only for those who distribute the gcc runtime library as well as the GPLv2-only application on the same medium.The gcc runtime library license is not GPLv3. Rather, it is GPLv3 plus a highly permissive exception, that allows linking not only to GPLv2 code, but to proprietary code as well.
We only have a problem if the runtime library's license forbids something that GPLv2 permits. DRM? No, that's waived by the runtime exception. Stricter standards for patent licensing? Again, that's waived. It's possible that the rules for proprietary compiler plugin passes are a new restriction, and if that is the case there's a problem.
I guess the issue in that case is who has a cause of action. The FSF? No. The combined executable wouldn't violate the license on any of their code. If there is a real conflict (and IANAL and it's a confusing matter, so I don't know), then it would be the copyright owner of the GPLv2-only code (that is, not the FSF, since it has no GPLv2-only code) who would have a cause of action.
But it occurs to me that this might not be a new problem. Are we sure that other GPL-incompatible licenses are all compatible with the license for older gcc runtimes (which were GPLv2+ with an exception)? To the extent that any of the other licenses are copylefts, there could be other lurking issues there.
Some clarifications
Posted Jul 28, 2009 0:32 UTC (Tue) by fuhchee (guest, #40059) [Link]
I guess the issue in that case is who has a cause of action. The FSF? No. The combined executable wouldn't violate the license on any of their code.Not so, if there is any (C)FSF application code in existence/use that is GPLv2 (not GPLv2+).
In any case, it would be rather sad if a resolution to this issue rested not on whether such GPLv2 -vs- GCC4.4 licensing compatibility is desirable, but rather who's likely to sue whom for its violation.
Some clarifications
Posted Jul 28, 2009 1:08 UTC (Tue) by JoeBuck (subscriber, #2330) [Link]
There is no GPLv2-only code owned by the FSF, and there never was. After all, not writing "or any later version" is basically a statement saying "I don't trust the FSF", since the FSF is the body that would produce the later versions.
Some clarifications
Posted Jul 28, 2009 18:28 UTC (Tue) by mingo (subscriber, #31122) [Link]
There is no GPLv2-only code owned by the FSF, and there never was. After all, not writing "or any later version" is basically a statement saying "I don't trust the FSF", since the FSF is the body that would produce the later versions.
No, the omission of "or any later version" is basically a statement saying "I find this license fine but I don't necessarily trust future decisions of the FSF". Can the current FSF guarantee that future FSF generations (years down the line) will always get it right? If yes, what are the mechanisms to ensure that?
Also, why couldn't they say that it's fine not to trust them in advance?
It would be perfectly fine for the FSF to release code with a license they don't have the power to change later on. Why is "you don't have to trust my future decisions in advance" such a bad idea in your opinion? Nobody and no organization is infallible.
In my opinion that would be the intellectually honest thing to do. The FSF is not a person but a foundation, and foundations can change: Their leadership can change, their position can change: their leadership can change and/or their positions can change.
Some clarifications
Posted Jul 29, 2009 8:11 UTC (Wed) by mjw (subscriber, #16740) [Link]
Some clarifications
Posted Jul 29, 2009 15:29 UTC (Wed) by vonbrand (guest, #4458) [Link]
Great. Before we had "license proliferation", now we have proliferation within the same license, and not just due to "extra permissions" (that anyone can strip out), but due to exactly who is allowed to update the license language?
This is sheer madness...
Some clarifications
Posted Jul 29, 2009 17:53 UTC (Wed) by dlang (guest, #313) [Link]
there was absolutly nothing preventing people from putting multi-license criteria in that included other people to specify additional licenses on _any_ code, under _any_ license (including GPLv2, GPLv3, BSD, MIT, Apache, etc)
Some clarifications
Posted Jul 28, 2009 0:33 UTC (Tue) by dlang (guest, #313) [Link]
the other solution is that the FSF can make a GPLv3.1 (or GCC specific extension) that explicitly allows for distribution of the runtime under GPLv2 (or dual license GCC under both GPLv2 and GPLv3, but I don't think they will want to do that)
Some clarifications
Posted Jul 28, 2009 12:08 UTC (Tue) by stevenb (guest, #11536) [Link]
Some clarifications
Posted Jul 28, 2009 15:18 UTC (Tue) by foom (subscriber, #14868) [Link]
Looking at http://gcc.gnu.org/viewcvs/trunk/libgcc/?view=log you can see there have been almost
no changes since the GPLv3 switch. In fact, *none* of the changes look relevant to libgcc compiled
on Linux or BSD, and therefore if Debian used a forked GPLv2 libgcc it would currently be
absolutely identical.
GPLv2 only code
Posted Aug 6, 2009 9:18 UTC (Thu) by forthy (guest, #1525) [Link]
You should all take into account that the FSF did not forsee or want anyone to use GPLv2 only code. The "or any later" part is intentional, drop it and you break the whole system. If you now find that you have a broken license mess because you dropped the "or any later" part, it's you fault. Get over it, the GPLv2+ is compatible with the GPLv3+, as it was meant by the FSF. I hope the FSF follows the path they had during GPLv3 development, and makes future GPLs compatible with even more other copyleft licenses, like CDDL and MPL-derived licenses. The part that's not covered with the current GPL is mixing stuff - IMHO if the conditions required are similar enough (all four freedoms preserved), mixing should be allowed. This might give us a future GPLv4, which then would again be one-side compatible with the GPLv2-only, but that's not yet achieved, and probably doesn't solve the problem either (because even now, we have CDDL, which is one-side compatible with GPLv2-only, but not the other way round).
As Joe Buck said, the ball is in the field of the GPLv2-only party, who messed up their license, and if they find that this was a stupid move, well, maybe they have to rethink. Given how much zeal they invest into defending their decision (including their praise of the backdoor-DRM-allowance which is IMHO only valid in the USA, and a GPL violation violation elsewhere, because it clearly violates the spirit of the license, stated in the preamble), this is not likely to happen soon.
GPLv2 only code
Posted Aug 6, 2009 9:45 UTC (Thu) by hppnq (guest, #14462) [Link]
You should all take into account that the FSF did not forsee or want anyone to use GPLv2 only code. The "or any later" part is intentional, drop it and you break the whole system.
The relevant part of the GPLv2 license is:
either version 2 of the License, or (at your option) any later version
Clearly, the license itself offers the choice to use only version 2 of the license. Note that this part (only) appears in the "How to apply these terms to your new programs" section of the license.
Explained in other words
Posted Jul 27, 2009 23:54 UTC (Mon) by coriordan (guest, #7544) [Link]
I didn't understand the issue at first, but now that I have, here's me restating it in other words. The chances of this issue causing a real problem in the near/mid-term are miniscule, but it's an interesting puzzle nonetheless...
If I compile Git with GCC, the resulting Git binary will be a combination of the Git source code plus the GCC runtime library source code which GCC injected in during compilation. If I then want to distribute my Git binary, I can do so under GPLv2 because the GCC runtime library source code allows you to distribute binaries (called Target Code in the runtime libraries exception licence) under any terms you wish.
The problem is that GPLv2 says that when I distribute binaries, I have to make complete corresponding source code available under GPLv2. So I'm given an impossible requirement. I have to make the GCC runtime libraries source code available under GPLv2, but that's not their licence. Their licence is incompatible with GPLv2.
If I was distributing the Git binary on its own, then I wouldn't have this problem because GPLv2's system library exception says that code for components such as the compiler or kernel code isn't required. But if I am also distributing GCC, then I do have a problem because that system library exception is only valid "unless that component itself accompanies the executable".
(This all assumes we're reading the licences correctly and haven't missed anything.)
Explained in other words
Posted Jul 28, 2009 0:45 UTC (Tue) by gjmarter (guest, #5777) [Link]
So either the requirement that the complete source must be GPL2 is somewhere else in the license, or the problem is that Sections 1 and/or 2 of GPL2 are incompatible with the GCC license somehow.
Can you shed some light on that?
Explained in other words
Posted Jul 28, 2009 0:56 UTC (Tue) by coriordan (guest, #7544) [Link]
The problem is section 2b:
b) You must cause any work that you distribute or publish, that in whole or in part contains or is derived from the Program or any part thereof, to be licensed as a whole at no charge to all third parties under the terms of this License.
So when section 3 says "must be distributed under the terms of Sections 1 and 2 above", section 2b kicks in. And I can't comply with 2b because I can't make the GCC runtime libraries source code available under "this License" when "this License" means "GPLv2". The GCC runtime library exception only solves the problem of distributing binaries.
but there is an exception
Posted Jul 28, 2009 1:23 UTC (Tue) by JoeBuck (subscriber, #2330) [Link]
GPLv2 states:However, 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, unless that component itself accompanies the executable.What this means is that your git distribution is completely legal: the gcc runtime library is a major component of the operating system on which the executable runs (even for non-GNU systems, the compiler counts as a major component). Or, almost ...
I consider the clause "unless that component itself accompanies the executable" to be a major flaw in GPLv2, and it seems to be the nit. RMS wasn't thinking of entirely-free OSes when he wrote that; he was thinking of proprietary OSes throwing the kitchen sink into "system libraries" and shipping them separately to go with GNU software, I think.
The claim is that the violation happens if a distro includes git and the libgcc runtime on the same disk. Note that there's no violation if you download git as a .deb or RPM.
Maybe the workaround is for git and similar GPLv2-only projects to change their license. Say that the license is GPLv2, except that the phrase "unless that component itself accompanies the executable" is considered to be removed.
Finding copyright holders
Posted Jul 28, 2009 1:47 UTC (Tue) by gdt (subscriber, #6284) [Link]
Maybe the workaround is for git and similar GPLv2-only projects to change their license.
That depends who holds the copyright. In some important projects there is no copyright assignment. In those projects to alter the license you need to find all of the authors (and perhaps their employers, their estates, their divorced partners, their major creditors) and obtain their agreement to the change.
People in these comments find it difficult to even understand the licensing problem, so the motivation for the massive amount of work to obtain the permission of many people for a license change doesn't seem likely. Even then, all it takes is a significant contributor to say "no".
Finding copyright holders
Posted Jul 28, 2009 2:00 UTC (Tue) by JoeBuck (subscriber, #2330) [Link]
It works both ways; getting a change to the runtime library exception terms, if it's decided that this is what is needed, is also going to be an extremely laborious process.
Finding copyright holders
Posted Jul 28, 2009 2:10 UTC (Tue) by dlang (guest, #313) [Link]
question: before the most recent change to the runtime exception, did it have the same problem with the GPLv2, or is this a result of the new language put in to try and block proprietary GCC modules?
Finding copyright holders
Posted Jul 28, 2009 3:55 UTC (Tue) by JoeBuck (subscriber, #2330) [Link]
The original idea was that the runtime license would just become GPLv3 plus the exception that was there before, but this was delayed while the plugin language was worked out. It's possible that even without the plugin language there would be an issue, because GPLv2 is quite restrictive.
No, that's not the plugin exception...
Posted Jul 28, 2009 16:54 UTC (Tue) by khim (subscriber, #9252) [Link]
Before the most recent change to the runtime exception, did it have the same problem with the GPLv2, or is this a result of the new language put in to try and block proprietary GCC modules?
This is result of switch to GPLv3. And it's pretty unlikely FSF will go back on that change. You can tweak exception as much as you want - it'll not fix the problem. The only solution is to offer libgcc under "GPLv2 or later" terms and clearly FSF don't like this solution - it wants to drop GPLv2 altogether.
No, that's not the plugin exception...
Posted Aug 1, 2009 23:26 UTC (Sat) by cas (guest, #52554) [Link]
> clearly FSF don't like this solution - it wants to drop GPLv2 altogether
no, that's NOT the only solution. it's not even the right solution, or even one of the right solutions.
the problem is with git, not with gcc.
if git wants to make use of the gcc runtime code, then it is up to git to have a compatible license. it can do that by switching to GPL v3 or by adding an explicit extra permission to its license allowing it to be linked to and distributed with GPL v3 code.
This kind of extra permission is NOT at all unusual with GPL code or software that links to GPL code. e.g. I remember several years back that many Qt & KDE programs had to have extra permission because the Qt license at that time was not quite GPL compatible.
No, that's not the plugin exception...
Posted Aug 2, 2009 0:56 UTC (Sun) by dlang (guest, #313) [Link]
Who to blame?
Posted Aug 2, 2009 4:58 UTC (Sun) by khim (subscriber, #9252) [Link]
Have you read the GPLv2 license? It has separate paragraph dedicated to this this problem:
9. The Free Software Foundation may publish revised and/or new versions of the General Public License from time to time. Such new versions will be similar in spirit to the present version, but may differ in detail to address new problems or concerns.
Each version is given a distinguishing version number. If the Program specifies a version number of this License which applies to it and "any later version", you have the option of following the terms and conditions either of that version or of any later version published by the Free Software Foundation. If the Program does not specify a version number of this License, you may choose any version ever published by the Free Software Foundation.
If authors of Git ignored cautions embedded in the very text of the license they are using - then how the hell can you blame anyone else? Git authors knew the license will be changed - it's written in the text of the license attached to Git. They knew how to avoid troubles - again, it's written in the very text of the license attached to Git. They chosen to ignore all this - it's their right, FSF gave this right to him (unlike MPL or CC licenses GPL does not have autoupdate option embedded in the license itself), but the consequences of their choice are theirs to resolve...
And the license does not make it easier to ship proprietary programs - if proprietary license include linking-prohibition similar to GPLv2 it can not be used will GCC also...
So no, it's hard to blame FSF here: they thought about the problem 18 years ago, they offered the solution back then - but Git authors rejected the solution. That's the problem.
Who to blame?
Posted Aug 6, 2009 10:23 UTC (Thu) by SEMW (guest, #52697) [Link]
It's not exactly blank cheque
Posted Aug 9, 2009 12:08 UTC (Sun) by khim (subscriber, #9252) [Link]
Yes this is what millions of authors do every single time they release something. Some licenses don't even include opt-out - like widely used Creative Commons licenses, for example.
If Git developers don't like to delegate legal problems to FSF they should solve them themselves, don't you think? If they are big enough to ignore advice (included in the text of license they selected, no less!) they should be big enough to deal with fallout...
It's not exactly blank cheque
Posted Aug 12, 2009 12:26 UTC (Wed) by SEMW (guest, #52697) [Link]
> even include opt-out - like widely used Creative Commons licenses, for example.
I've just skimmed through several sample creative commons licenses, and can't see any "or later version" clauses, let alone mandatory ones. The page for all licenses before the current one even explicitely say "A new version of this license is available. ... No works are automatically put under the new license...". Are you sure you're not mistaken?
> If they are big enough to ignore advice (included in the text of license they selected, no less!) they should be big enough to deal with fallout...
Are you suggesting that anyone -- the git authors, Debian, the FSF, whoever -- knew about this before very recently? If you're saying that this side-effect was known when the git authors chose the license, then say so explicitly; the article certainly does not give that impression (and even explicitly says that, in the FSF's case, "This is a perverse result that, probably, was not envisioned or desired...").
Have you actully read the license?
Posted Aug 14, 2009 10:37 UTC (Fri) by khim (subscriber, #9252) [Link]
I've just skimmed through several sample creative commons licenses, and can't see any "or later version" clauses, let alone mandatory ones.
Is this a joke? Have you read the legal code?
You may Distribute or Publicly Perform an Adaptation only under the terms of: (i) this License; (ii) a later version of this License with the same License Elements as this License; (iii) a Creative Commons jurisdiction license (either this or a later license version) that contains the same License Elements as this License (e.g., Attribution-ShareAlike 3.0 US)); (iv) a Creative Commons Compatible License.
Version upgrade is emebedded in the text of the license and it's not an option. Sure, you can not change the license for original work, but should you add one line to it... you are free to upgrade.
Are you suggesting that anyone -- the git authors, Debian, the FSF, whoever -- knew about this before very recently?
Kind of. FSF knew about the problem in general back in 1991 - that's why it included paragraph 9 in first place. Then some people decided that they don't trust FSF enough to allow combining of their code with FSF's code released under new GPLv3 (and later) licenses. Fair enough - but then obviously they are the only ones who can say if libgcc's code is Ok with them or not. If they knew nothing about licensing and ramifications then why they fiddled around with this stuff?
Stable copyleft licence nonsense
Posted Aug 2, 2009 11:17 UTC (Sun) by xoddam (subscriber, #2322) [Link]
The Linux Kernel, version 2.6, warns its users that kernel-internal APIs may be revised from time to time for technical reasons (and for the purpose of removing cruft in the kernel) in the file Documentation/stable_api_nonsense.txt.
The GPL, version 2, wants its users that the licence text may be revised from time to time for legal reasons (and for the purpose of advancing free software) in its paragraph 9 (it's Paragraph 14 of version 3).
But it's the Linux kernel developers, and fellow travellers like the Git and Busybox developers, who have chosen not to support version 3 of the GPL.
It's a bit like a vendor of commodity hardware (say, a GPU) whose driver is not yet in-tree deciding they will never, ever support Linux kernel APIs after some API change made in kernel version 2.6.29. That's their choice. But *someone* will want to use that hardware with a later kernel, so *somehow*, the incompatibility will be resolved by someone who cares.
No, that's not the plugin exception...
Posted Aug 2, 2009 8:27 UTC (Sun) by nix (subscriber, #2304) [Link]
GCC. All git did was be written in C.
What you're saying is 'if you want to be compiled with compiler X, you
have to adjust your license to fit'. Several major Linux compilers (icc
and GCC, for instance), have incompatible licenses, so you're saying that
it should be impossible to have any program on Linux which can be compiled
with both compilers and the binary then distributed.
This seems seriously skewy to me.
Why can't the FSF take a leaf from Bison (again)?
No, that's not the plugin exception...
Posted Aug 3, 2009 10:51 UTC (Mon) by khim (subscriber, #9252) [Link]
What you're saying is 'if you want to be compiled with compiler X, you have to adjust your license to fit'. Several major Linux compilers (icc and GCC, for instance), have incompatible licenses, so you're saying that it should be impossible to have any program on Linux which can be compiled with both compilers and the binary then distributed.
ICC does not have this problem since it's not distributed with Git.
This seems seriously skewy to me.
Me too, but that's what the license says...
Why can't the FSF take a leaf from Bison (again)?
Huh? They did. Bison has the same problem GCC does. The only difference lies in the fact that Git does not use Bison.
No, that's not the plugin exception...
Posted Aug 3, 2009 22:34 UTC (Mon) by nix (subscriber, #2304) [Link]
binaries* if git binaries compiled with ICC are distributed, in *exactly*
the same way as libgcc is incorporated into git binaries.
That you're even asking this question indicates that you've completely
failed to grasp the problem, and indeed the rationale for a special
license for libgcc :( nobody is worried about someone distributing source
for libgcc along with Git, and Git does not intentionally call into
libgcc. The *compiler* inserts calls to libgcc into the object file, and
this is then resolved by linking with libgcc. libgcc is necessarily
GCC-specific: ICC uses something different.
No, that's not the plugin exception...
Posted Aug 4, 2009 8:26 UTC (Tue) by khim (subscriber, #9252) [Link]
ICC's *runtime libraries* are distributed with (incorporated into) *git binaries* if git binaries compiled with ICC are distributed, in *exactly* the same way as libgcc is incorporated into git binaries.
Yes. And still ICC does not have a problem where GCC does. Why? Because ICC's license forbids distribution (runtime libraries can be redistributed while ICC itself can not) and so ICC is not distributed on the same medium as git! This fits the GPL exception to a tee: However, 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, unless that component itself accompanies the executable.
The *compiler* inserts calls to libgcc into the object file, and this is then resolved by linking with libgcc.
Yes, but it does not change the fact that parts of libgcc ends up in git executable. GPL gives no exception for "compiler-inserted calls", instead it gives exception for "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" - but this exception is not valid if "that component itself accompanies the executable". GCC accompanies the executable while ICC does not - that's why we have problem with GCC, but not with ICC. Since these parts are needed to recreate binary they are part of the "complete machine-readable copy of the corresponding source code" and now the question is: must these parts be distributed under GPLv2 or do they fall under "special exception". If they fall under exception then Git can be redistributed with GCC for sure, if not - then you can not redistribute Git and GCC on the same medium. Only copyright holder of git can clear this confusion and FSF is not Git's copyright holder so I can not understand why eveyone waits for FSF's response...
No, that's not the plugin exception...
Posted Aug 4, 2009 21:05 UTC (Tue) by nix (subscriber, #2304) [Link]
missed that.
*sigh*
No, that's not the plugin exception...
Posted Aug 7, 2009 13:27 UTC (Fri) by DOT (guest, #58786) [Link]
Does the ICC runtime library allow for relicensing under GPL version 2? That's what needs to happen for the problem to go away. The component that needs to fall under the exception is the ICC runtime library. But that code is injected into the program at compilation time. So that component accompanies the executable, which means it doesn't fall under the exception. Therefore, the ICC runtime library needs to be 1) open source, and 2) licensed under the GPL version 2. I don't believe that is the case, so Git -- compiled with any recent compiler -- cannot be legally distributed.
No, that's not the plugin exception...
Posted Aug 6, 2009 5:57 UTC (Thu) by lysse (guest, #3190) [Link]
Aside from finding the idea of a C compiler requiring a runtime library slightly strange, presumably git doesn't particularly care which runtime code it makes use of? In which case, surely the appropriate thing for git to do is incorporate a copy of the last GPL2+-licensed version of libgcc into their own codebase, optionally customise it to suit, and simply compile with whatever option says "no default runtime, please" in future?
Or am I missing something here...?
No, that's not the plugin exception...
Posted Aug 6, 2009 8:08 UTC (Thu) by johill (subscriber, #25196) [Link]
Yes. It's not feasible to maintain thousands of packages that way, and makes no sense technically either -- improvements of the runtime lib would never make it into that program, etc.
No, that's not the plugin exception...
Posted Aug 7, 2009 23:17 UTC (Fri) by nix (subscriber, #2304) [Link]
calls (e.g. long long maths on 32-bit systems); there is the startup code
(on Linux a complex dance of cooperation between GCC and glibc); and there
are things like binary decimal support, which has a sizeable runtime
library. There are even more nasty things like C++ exception handling,
which if it is to work across shared library boundaries needs shared data
structures and shared code to touch those data structures. (You might
think this is irrelevant to C, but C++ code can throw across C function
calls with GCC, as long as the C translation units were compiled
with -fexceptions: the relevant parts of the unwinding machinery are thus
in the C runtime library, not in the C++ one.)
The compiler generates the calls into this library as it sees fit, and
links the library to the object files it generates. It's completely
compiler-dependent and often compiler-version-dependent too (although for
obvious reasons backward compatibility is very strictly maintained).
but there is an exception to the exceptiuon
Posted Jul 28, 2009 7:47 UTC (Tue) by mjw (subscriber, #16740) [Link]
I think this is the right interpretation of the "nit". There was a similar uncertainty about OpenSolaris, which mainly uses the GPL-incompatbile, but free, CDDL license. Which apparently Eben Moglen clarified:During the discussion, Eben Moglen took special care to assert that he always believed the GPL v2 should be interpreted in the way GPL v3 now makes explicit - it was never the intent to prevent aggregation of otherwise unrelated code because of the GPL being triggered just because a system function or C runtime was invoked. I found that clarification especially valuable.http://www.opensolaris.org/jive/thread.jspa?messageID=21134&h;#21134
So, it would be good to get this explicit clarification somewhere on gcc.gnu.org.
Applies to any copyleft licence
Posted Jul 28, 2009 8:32 UTC (Tue) by epa (subscriber, #39769) [Link]
Applies to any copyleft licence
Posted Jul 28, 2009 9:09 UTC (Tue) by mjw (subscriber, #16740) [Link]
What seems to be happening is that instead of taking these as clarifications of the intent of v2, they are taken as some kind of fatal flaws in the old text. Instead of taking v3 and using it as a guide to the intend of v2.
Things would be much easier if people saw v3 as just a clarification of the text and intent of what v2 always already was about.
Applies to any copyleft licence
Posted Jul 28, 2009 12:10 UTC (Tue) by epa (subscriber, #39769) [Link]
Applies to any copyleft licence
Posted Jul 28, 2009 12:25 UTC (Tue) by mjw (subscriber, #16740) [Link]
Applies to any copyleft licence
Posted Jul 28, 2009 20:07 UTC (Tue) by epa (subscriber, #39769) [Link]
Applies to any copyleft licence
Posted Jul 28, 2009 20:12 UTC (Tue) by hppnq (guest, #14462) [Link]
One has to assume that the intent of the person who choose the license was to try and understand the intent of the person who wrote it. ;-)
Applies to any copyleft licence
Posted Jul 29, 2009 8:07 UTC (Wed) by mjw (subscriber, #16740) [Link]
IMHO, unless a copyright holder explicitly tells you to ignore the stated intent of the license drafter, you can safely ignore that possibility.
Applies to any copyleft licence
Posted Jul 29, 2009 17:54 UTC (Wed) by dlang (guest, #313) [Link]
Applies to any copyleft licence
Posted Jul 28, 2009 21:08 UTC (Tue) by kleptog (subscriber, #1183) [Link]
It basically all it means is that all constituent parts must meet *at least* the requirements of the GPL2 but it may grant more rights. The problem being that whatever GCC is doing grants less.
Messy, but I'm not sure if there's any easy solution here (other than the FSF blinking).
but there is an exception
Posted Aug 1, 2009 23:14 UTC (Sat) by cas (guest, #52554) [Link]
> [...]
> RMS wasn't thinking of entirely-free OSes when he wrote that;
easily fixed in a hypothetical GPL v2.1, or in an addition to the git license:
"... unless that component itself accompanies the executable AND is not licensed with a Copyleft-style license such as the GPL v3 or any compatible Free Software license"
or making it a new sentence might make it clearer/less clumsy:
"... unless that component itself accompanies the executable. This exception does not apply if the component is licensed with a Copyleft-style license such as the GPL v3 or any compatible Free Software license".
> Say that the license is GPLv2, except that the phrase "unless that
> component itself accompanies the executable" is considered to be removed.
there's a reason for that exception. it's to prevent people from subverting the intent of the GPL and merging it with proprietary code by claiming that they are merely aggregating the work.
Explained in other words
Posted Jul 29, 2009 10:29 UTC (Wed) by mjthayer (guest, #39183) [Link]
>
>b) You must cause any work that you distribute or publish, that in whole or in part contains or is derived from the Program or any part thereof, to be licensed as a whole at no charge to all third parties under the terms of this License.
I am assuming that the distributions have local changes to the code, otherwise they can distribute under the terms of section 1, which are more liberal than 2b. This seems to come down to the question of whether the runtime library counts as part of the derived work. Section 3 seems to require the source to the runtime to be included (mandated by both sections 1 and 2). However, if the runtime is not part of the derived work, then the terms of section 1 seem to be sufficient.
IANAL should be implicit in licence discussions unless stated otherwise :)
Explained in other words
Posted Jul 28, 2009 7:20 UTC (Tue) by elama (guest, #262) [Link]
libgcc and git won't share the same deb file. Is that enough?
Or may they not share the same CD, DVD, Distributor?
Explained in other words
Posted Jul 28, 2009 10:45 UTC (Tue) by cortana (subscriber, #24596) [Link]
Explained in other words
Posted Jul 28, 2009 12:10 UTC (Tue) by MathFox (guest, #6104) [Link]
Reasonable interpretations of "accompanying" would be "on the same CD or in the same CD set" and "side by side on the same server". So, if you follow a strict license interpretation, Debian has to choose between GPLv2-git and a new GPLv3-gcc and can not carry both. (Well, as a stopgap they could compile GPLv2 only programs with a GPLv2+ version of gcc...)
The problem exists because version 2 and 3 of the GPL are incompatible and the authors of the GPLv2 only programs can not relicense libgcc.
Explained in other words
Posted Jul 29, 2009 1:41 UTC (Wed) by Baylink (guest, #755) [Link]
Yes and no
Posted Jul 30, 2009 5:28 UTC (Thu) by khim (subscriber, #9252) [Link]
Isn't there "mere aggregation" language in there somewhere specifically to protect distributors?
Yes, but that sentence covers totally different case. It gives you right to ship GPLed git and proprietary adobe flash player on the same CD: as long as program are totally unrelated their license don't clash. Unfortunatelly git and libgcc are intimately intervined, so "mere aggregation" defense does not fly...
Explained in other words
Posted Jul 29, 2009 11:14 UTC (Wed) by garloff (subscriber, #319) [Link]
> (Well, as a stopgap they could compile GPLv2 only programs with a
> GPLv2+ version of gcc...)
It would be enough if Debian compiled a GPLv2+ version of libgcc and made
sure that git uses that one instead of the GPLv3 libgcc. As someone pointed
out, the changes to libgcc have been minimal, so that effort is not very
large.
Explained in other words
Posted Jul 29, 2009 20:03 UTC (Wed) by vonbrand (guest, #4458) [Link]
"Side by side on the same server"... this would mean that if I have e.g. OpenSolaris and BSD and some Linux distributions on a mirror somwehwere, the license terms kick in? Sounds horrible.
human judges
Posted Jul 29, 2009 20:12 UTC (Wed) by coriordan (guest, #7544) [Link]
When learning to be a computer admin or programmer, we're taught how to see *past* the differences between a lump of bits that forms an operating system ISO and a lump of bits that forms a picture. To think about legal issues, we have to remember to look *at* those differences.
A new GCC runtime library license snag?
Posted Jul 28, 2009 3:16 UTC (Tue) by paulv (guest, #14911) [Link]
> unanswered since last April.
This seems odd -- did our editor attempt to make contact with the FSF at all in the process of writing this article?
A new GCC runtime library license snag?
Posted Jul 28, 2009 5:47 UTC (Tue) by ptman (subscriber, #57271) [Link]
A new GCC runtime library license snag?
Posted Jul 28, 2009 9:48 UTC (Tue) by MisterIO (guest, #36192) [Link]
A new GCC runtime library license snag?
Posted Jul 28, 2009 10:14 UTC (Tue) by mosfet (guest, #45339) [Link]
Will LLVM-Clang by next release compile a bootable Linux kernel?
A new GCC runtime library license snag?
Posted Jul 28, 2009 14:55 UTC (Tue) by MisterIO (guest, #36192) [Link]
Look at the "Current Status" section. There's still work to do for Linux Kernel support, but when something like FreeBSD is working, I think 1 or 2 more releases will be enough to achieve at least a partial success.
A new GCC runtime library license snag?
Posted Jul 28, 2009 15:44 UTC (Tue) by rsidd (subscriber, #2582) [Link]
A new GCC runtime library license snag?
Posted Jul 28, 2009 11:45 UTC (Tue) by Lumag (subscriber, #22579) [Link]
A new GCC runtime library license snag?
Posted Jul 28, 2009 12:11 UTC (Tue) by stevenb (guest, #11536) [Link]
As for Clang licensing problems, the question is: "Who do you trust more: Apple or the FSF"... ;-)
A new GCC runtime library license snag?
Posted Jul 28, 2009 13:03 UTC (Tue) by Lumag (subscriber, #22579) [Link]
A new GCC runtime library license snag?
Posted Jul 28, 2009 13:19 UTC (Tue) by halla (subscriber, #14185) [Link]
A new GCC runtime library license snag?
Posted Jul 28, 2009 14:42 UTC (Tue) by bronson (subscriber, #4806) [Link]
Lumag did say that he trusts the FSF more than Apple. That's something!
A new GCC runtime library license snag?
Posted Jul 28, 2009 15:25 UTC (Tue) by foom (subscriber, #14868) [Link]
Made a license called "GNU Free Documentation License" which isn't free. Claimed documentation
doesn't actually need to be free. Prohibited addition of plugin support for GCC for 10 years.
Of course if you're willing to conflate RMS-as-individual with FSF, there's many more. :)
Don't get me wrong, I do think FSF and RMS have been an overall positive by far, but they've also
done many remarkably stupid things.
A new GCC runtime library license snag?
Posted Jul 28, 2009 16:29 UTC (Tue) by drag (guest, #31333) [Link]
If you agree with everything that another person (or group of people) says or does then:
A) Your being lied to and your falling for it.
B) Your lying to yourself.
C) Your brainwashed.
D) You have no mind of your own and you'll happily follow them off the edge of a cliff.
E) Your not thinking hard enough.
The thing about RMS is that he has a vision and he is compelled to follow it. That is a very very much superior approach then 90% of the 'pragmatists' out there that would rather not try anything new, not take risks, and don't want to think for themselves.
Of course he has problems, errors in his logic, errors in his approach, and has personality issues. The flip side is that people that don't have problems, don't have personality issues, and don't make mistakes are people that don't contribute, can't progress, are boring, and worthless as turds roasting on a hot sidewalk.
A new GCC runtime library license snag?
Posted Jul 28, 2009 21:44 UTC (Tue) by bronson (subscriber, #4806) [Link]
By 'pragmatists' do you mean people who disagree with the FSF or GPL? Say, the BSD crew? If so, I certainly don't agree.
Finally, it really sounds like you're saying that people who don't have personality issues are boring and worthless. If so, I don't agree there either!
A new GCC runtime library license snag?
Posted Jul 29, 2009 11:57 UTC (Wed) by epa (subscriber, #39769) [Link]
A new GCC runtime library license snag?
Posted Jul 29, 2009 16:46 UTC (Wed) by Lumag (subscriber, #22579) [Link]
A new GCC runtime library license snag?
Posted Jul 28, 2009 9:32 UTC (Tue) by ikm (subscriber, #493) [Link]
Seems like a real problem at first sight
Posted Jul 30, 2009 2:11 UTC (Thu) by mikov (guest, #33179) [Link]
Let's say I develop a useful application, and while keeping the copyright to myself, release it under GPLv2. Let's say that it gets included in Debian and distributed after being compiled with GCC 4.4.
Then, I sell the application to a proprietary company. It is till GPLv2, but the company owns the copyright.
Couldn't at that point the company sue Debian?
They could but the case will not go very far
Posted Jul 30, 2009 5:45 UTC (Thu) by khim (subscriber, #9252) [Link]
Then, I sell the application to a proprietary company. It is till GPLv2, but the company owns the copyright.
Couldn't at that point the company sue Debian?
Not yet. Since there are reasonable interpretation which leaves the Debian in the clear the court will be very reluctant to give anything to the new company. But if/when Debian decide that it's illegal after all... then yes, the story will be finished: since Debian perceived this limitation as limiting (and this idea is present to the court) and new company can easily agree (it's in their interests) the case will have a merit. Here is what then lawer will say:
It generally turns out, as I know from having spent almost a quarter of a century now as a lawyer for hackers, that when hackers pretend to be lawyers, there are certain predictable formulations that they come to; they assume a degree of consistence in legal rules that is not achievable; this is a primary problem which occurs particularly in US focused conversation, such is that in Debian Legal, where the libertarian demand for intellectual consistency, and the hacker belief that laws are form of code that are executed without errors or ambiguities, joins together to create a particular frame of analysis for legal questions.
It doesn't work very well for me as a lawyer, I think it doesn't work very well for lawyers elsewhere in the World, because the one thing which lawyers around the world all share is an awareness of the squishiness of law, it is by no means the hard arthropod carapace for internal soft organs that non-lawyers have a tendency to assume it is.
When you start publicly discuss your rights which fall into the grey area it's very easy to lose them: court will use your own words against you! That's why law is usually discussed privately. This is especially true for patents but other aspects follow the same pattern...
They could but the case will not go very far
Posted Jul 30, 2009 16:35 UTC (Thu) by mikov (guest, #33179) [Link]
When you start publicly discuss your rights which fall into the grey area it's very easy to lose them: court will use your own words against you! That's why law is usually discussed privately. This is especially true for patents but other aspects follow the same pattern...
I have to tell you this is really scary ... (for lack of a better word). The notion that discussing your rights makes it easier to lose them...
I really liked the quote from the lawyer; thanks for posting it!
They could but the case will not go very far
Posted Jul 31, 2009 8:34 UTC (Fri) by mjthayer (guest, #39183) [Link]
>> Couldn't at that point the company sue Debian?
> Not yet. Since there are reasonable interpretation which leaves the Debian in the clear the court will be very reluctant to give anything to the new company.
I don't think that it is enough for Debian to be able to find a reasonable interpretation that speaks in their favour. I think that there is a problem if there is just a single reasonable interpretation which does *not* leave Debian in the clear. Debian don't want to be taken to court at all, not even if they are reasonably sure (you can never be more than reasonably sure) of winning, as it costs them time and money they would surely rather use for other things.
There are exactly one way to do this - and it's not what Debian wants...
Posted Aug 2, 2009 4:34 UTC (Sun) by khim (subscriber, #9252) [Link]
Debian don't want to be taken to court at all, not even if they are reasonably sure (you can never be more than reasonably sure) of winning, as it costs them time and money they would surely rather use for other things.
Then they should close the shop. It's more-or-less impossible to do so. Most programs out there infringe more then one patent, for example. Sure, these patents are bogus, but if you are determined to avoid court at all - you should remove all programs from distribution and since distribution with zero programs or files is pretty much useless it'll be the end for Debian...
Seems like a real problem at first sight
Posted Jul 30, 2009 12:51 UTC (Thu) by jond (subscriber, #37669) [Link]
A new GCC runtime library license snag?
Posted Jul 30, 2009 6:46 UTC (Thu) by jimbo (subscriber, #6689) [Link]
In my opinion we shouldn't make use of GCC difficult for people who may require to build non-free programs. I use mainly non-free software tools at work. For my hobby use of computers, it is incredibly refreshing to be able to "just install" code, and not to have to interact with a telephone robot in order to activate a product that I may or may not need.Please let's set up some language that clearly lays out what the compiler user may do with his compiled output. We will surely get more credit with people outside the immediate FOSS community if we show ourselves as the "less hassle" alternative to proprietary systems than we will by making it difficult for people to start playing in the shallow end of Free Software.
--jimbo
A new GCC runtime library license snag?
Posted Jul 30, 2009 19:29 UTC (Thu) by spitzak (guest, #4593) [Link]
There are plenty of distributions that include closed-source drivers, and include GPL2/3 programs that when run will call those drivers. Nobody ever thought that was a problem.
The fact that they are on the same disk is irrelevant. It is the fact that they are a "standard system component" that makes all the difference.
What if the disk was partitioned, so you installed the OS first, and then installed the application second? What if that was done automatically? How about if it was on another disk, or if the installation of the OS automatically ran a program that downloaded the app and installed it? It seems these are allowed, so disallowing the same-disk distribution is totally silly.
Also the purpose of the same-distribution clause was to prevent people from putting a big function into a closed-source "standard system component". Since the library is NOT closed source, I cannot see any plausible way that this is a problem or conflict.
Are you sure?
Posted Jul 31, 2009 4:34 UTC (Fri) by khim (subscriber, #9252) [Link]
There are plenty of distributions that include closed-source drivers, and include GPL2/3 programs that when run will call those drivers. Nobody ever thought that was a problem.
That's because syscall interface creates demarcation line: it implements POSIX and so you can consider program which uses kernel directly. When both sides are in kernel it is a problem, when GPLed code uses non-GPLed library it's a problem too (note how QPL/GPL incompatibility was never sidestepped with "system libraries" excuse - nobody ever suggested it and RMS was even eager to point out that Misusing a GPL-covered program permanently forfeits the right to distribute the code at all.
What if the disk was partitioned, so you installed the OS first, and then installed the application second?
Courts will look at the intent. If these two discs come from separate companies then it's clearly allowed, but if they are sold as a bundle intended to be used in tandem... then the answer is probably no.
What if that was done automatically?
Probably not, but then degree of automatization matter.
How about if it was on another disk, or if the installation of the OS automatically ran a program that downloaded the app and installed it?
Again: what was the intent of all these dances, why you are doing it this way and not that way, etc.
It seems these are allowed, so disallowing the same-disk distribution is totally silly.
These are not unconditionally allowed, so distribution on the same-disk can be allowed or disallowed.
You are forgetting again that law is squishy. When you construct long series or argument you in effect construct some "chain of reasoning": if A then B, if B then C, if C then D, etc. And then you expect to use it to prove that of A then K. But lawer looks on this chain in different way: it says "if A then B - hmm, good argument, 80% probablity to withstand test in the court", then "if B then C - hmm, good argument too, 80% probability it'll be Ok in court", then you "agree" again and again and in the end you are saying "Ok, not we have the proof that if A then K" and lawer says "sorry, but we have no such proof because this chain has roughly 10% chance to withstand test in court".
Actually it's easy for geek to see how it all works if s/he ever heard about fuzzy logic. Logic related with law is fuzzy. There are no hard rules - there are probabilities. They can be bigger and smaller in different cases, but they never reach 100% and they never reach 0%. For practical purposes the fact which is supprted by ten different 99% proofs is bullet-proof (probability of failure is 1e-20 and our universe is too young to allow such a chance), but when you are using long enough chains of logic even such probabilities can be exhausted.
Also the purpose of the same-distribution clause was to prevent people from putting a big function into a closed-source "standard system component". Since the library is NOT closed source, I cannot see any plausible way that this is a problem or conflict.
Yes, that's position of FSF and it was clarified in GPLv3. But since copyright holders explicitly refused such clarification (they are not using "or later" text to show that they agree with FSF's interpretation) we can not use FSF's intent to justify such reading. The only guys who can clarify the issue are git/udev/etc copyright holders - and they are silent AFAICS...