Weekly Edition
Return to the Front page
| |||||||||||||
A new GCC runtime library license snag?
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:
You have permission to propagate a work of Target Code formed by
combining the Runtime Library with Independent Modules, even if
such propagation would otherwise violate the terms of GPLv3,
provided that all Target Code was generated by Eligible Compilation
Processes. You may then convey such a combination under terms of
your choice, consistent with the licensing of the Independent
Modules.
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:
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.
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:
If the FSF keeps refusing to enter any discussion on this matter
(I'm not even talking about agreeing on a solution yet!), our
options for dealing with the GCC 4.4 relicensing fallout at Debian
are pretty limited. It's also likely that any unilateral action
will undermine the effect of some of the FSF's licensing policies.
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 (subscriber, #755) [Link]
I dunno, but it seems to me that the *loser* here is the GCC project, indirectly by way of the pain they're going to inflict on their users by moving to GPLv3.
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]
To the FSF, GCC and the other compiler-toolchain programs are the one truly indispensable thing they have contributed: there are other system libraries, other editors, but only one usable free C compiler -- even the BSDs use gcc because there is no alternative. But LLVM/Clang could well change that in the near future (it is already usable for compiling the base FreeBSD system). So the FSF will have to lighten up a bit on GCC, if they want to stay relevant. They already lost one battle when they had to accept the egcs fork and rename it the "new" GCC: but if LLVM catches up with or overtakes GCC, it will be much harder for the FSF to stay relevant.
A new GCC runtime library license snag? Posted Jul 29, 2009 1:22 UTC (Wed) by Baylink (subscriber, #755) [Link]
My understanding of the egcs un-fork didn't characterize it that way; does that mean I drank the Kool-Aid? :-)
A new GCC runtime library license snag? Posted Jul 29, 2009 8:05 UTC (Wed) by rsidd (subscriber, #2582) [Link]
My understanding is that egcs forked because it was impossible to get changes into the FSF tree. Despite ESR's analogy of free software with "the bazaar", the FSF has always had a "cathedral" mode of development. The egcs people did desire eventual re-merging and were careful to assign copyrights to the FSF. Eventually when the FSF realised gcc 2.8 was a dead-end and egcs had leapfrogged it, they agreed to re-merge with egcs and call the result gcc 2.95. But this happened after most serious users had switched to egcs anyway: gcc 2.7.x was showing its age and gcc 2.8 was seriously flaky. So it was bowing to the inevitable, but it wasn't so bad for the FSF, since it was still GNU software with copyrights held by them. The current situation could turn out worse.
A new GCC runtime library license snag? Posted Aug 2, 2009 1:30 UTC (Sun) by landley (guest, #6789) [Link]
Actually, the FSF _was_ the "cathedral" in CATB, and Linux was the "Bazaar". (Eric's said so in a couple interviews over the years, he just didn't play it up in the paper itself so as not to set-off the FSF's supporters.) Eric was comparing different methods of open source development. (Keep in mind that CATB came out shortly before the egcs fork, when gcc development was stagnant.)
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]
People have been looking for a gcc replacement for a while now. LLVM/Clang is one (supported by Apple), and the relaunched PCC is another (supported by a couple of the BSDs, see http://lwn.net/Articles/255558/ for details).
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]
Fabrice Bellard seems to be making releases of tinycc at irregular intervals (the last on May 20, 2009). He also links to your fork. Is it uninteresting because it offers insufficient scope for optimisation? 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.
A new GCC runtime library license snag? Posted Aug 2, 2009 7:11 UTC (Sun) by landley (guest, #6789) [Link]
> Fabrice Bellard seems to be making releases of tinycc at irregular
> 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
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
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]
FSF has always been more about ivory towers than users. As time goes on, I wonder more and more about the wisdom of all the license complexity the FSF has created. This is all beginning to get a sort of "spaghetti code" feel to it.
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]
Stick to the GPL v2? Or even the BSD/MIT licences. Free code that was written using those licences in the 1980s is alive and well, and free, today. Proprietary forks have mostly perished (Apple is the only major exception, I think, and even they have not really "taken code proprietary" so much as added proprietary layers on top of it). The copyleft was originally a clever idea, but it's not obvious that it was more useful than plain old BSD/MIT. Increasingly, the FSF's licences smack of control-freakery -- and nobody likes that, really. And if you can't even convince Debian (witness also the kerfuffle over GFDL some time ago) who can you convince?
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]
I'll go with "stick to GPLv2". The FSF itself decries license proliferation... except when they are the ones doing the proliferating.
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]
The GPLv3 comment system required people to attach their comment to a specific lump of text. The people who wanted a nice, shorter licence made practically no suggestions.
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.
"""
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]
> diff -u GPLv3.txt GPLv2.txt
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]
Oh, there were lots of suggestions. The FSF just didn't like them.
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 (subscriber, #24141) [Link]
> Now the previously too-long GPLv2 has become "just right" and GPLv3 is the
> 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 (subscriber, #24141) [Link]
> What part of GPLv3 is bad?
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]
GPLv2 used words like "distribute". I like seeing that word because I think I know what it means.
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]
> The licence *text* itself is more complex, but overall, knowing what the licence really means is much much easier.
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]
> it's hard to see what the hell FSF can do here
Well, there's certainly one obvious and trivially correct thing they could do...
Fatal oversight Posted Jul 31, 2009 8:15 UTC (Fri) by michaeljt (subscriber, #39183) [Link]
I think that that is the most sensible comment I have seen on this thread so far.
Fatal oversight Posted Jul 30, 2009 16:03 UTC (Thu) by bronson (subscriber, #4806) [Link]
> the problem discussed is related to the fact that GPLv2 uses unprecise definitions
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]
> 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 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]
> It is useful anywhere (for free and proprietary programs alike) - where other side does not prohibit it.
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]
> 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!
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]
Simple answer: don't go to court?
how v3 is much much simpler (after taking a hit from the crack pipe) Posted Jul 30, 2009 19:07 UTC (Thu) by DonDiego (subscriber, #24141) [Link]
> GPLv3 makes things simpler because I no longer have to know or guess the
> 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
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,
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]
Make the licence for the gcc runtime library very simple. "This (binary) library may be distributed with any binary compiled by the gcc compiler of which it is a part". That is, if a program is compiled with gcc, irrespective of its licence, and it makes calls to the runtime library then the binary gcc runtime library may be distributed with the binary of the program.
I want Minix's size but Linux's functionality.... Posted Aug 1, 2009 0:05 UTC (Sat) by coriordan (guest, #7544) [Link]
That wouldn't work, if I've understood what you mean.
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 (subscriber, #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]
This is indeed another thing GPLv3 improved. It allows you to choose someone else than the FSF as proxy for "or later..." upgrades (clause 14). So you don't have to just trust the FSF when using GPLv3 or later.
Some clarifications Posted Jul 29, 2009 15:29 UTC (Wed) by vonbrand (subscriber, #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 (✭ supporter ✭, #313) [Link]
umm, the 'or later version' was never part of the license itself, it was the same thing as just licensing the code under multiple licenses. in that case it was just GPL2, GPL3, GPLX,,,, as released by the FSF
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 (✭ supporter ✭, #313) [Link]
if the FSF takes the position that there is no need for them to change anything, everyone should just use GPLv3, what I would expect to see happen is to see GCC forked to maintain a version under a new license that doesn't have this incompatibility with GPLv2
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]
One could fork GCC and go back to GPLv2, but the forker would have to start from a point *before* the change-over to GPLv3. That's long ago already (2 years? 3 years?) so literally years of GCC development would have to be done all over again -- or all contributors have to be traced and found willing to contribute their code under GPLv2. Because the FSF is (unfortunately) still the copyright holder over all of GCC, so only the FSF can decide to use a different license.
Some clarifications Posted Jul 28, 2009 15:18 UTC (Tue) by foom (subscriber, #14868) [Link]
Luckily they wouldn't need to fork all of GCC, just libgcc.
Looking at http://gcc.gnu.org/viewcvs/trunk/libgcc/?view=log you can see there have been almost
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 (subscriber, #5777) [Link]
I don't understand this yet. In particular, I don't see the requirement in GPL2 that you have distribute the complete source code under a GPL2 license. In GPL2 section 3.a It says "...which must be distributed under the terms of Sections 1 and 2 above..." 3.b is similar.
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 (✭ supporter ✭, #313) [Link]
but that change only needs to be approved by the FSF, as opposed to hundreds or thousands of individual developers.
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 (subscriber, #52554) [Link]
> 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 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 (✭ supporter ✭, #313) [Link]
it seems very strange that you blame a software project that uses a license produced by the FSF for incompatibilities caused by the FSF changing the license of another program to a new license that makes it easier to ship proprietary apps than it is to ship open apps.
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. 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]
To be fair to the authors of git etc., I find it very hard to blame someone for not wanting to release their intellectual property under a license, or series of licenses, that they not only haven't read but don't even *exist* yet; for the same reason that I wouldn't blame someone for not wanting to hand over a blank cheque or sign a contract they haven't read.
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]
> 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.
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]
WHAT????
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]
git 'makes use of' the GCC runtime code by virtue of being *compiled* with
GCC. All git did was be written in C.
What you're saying is 'if you want to be compiled with compiler X, you
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]
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.
That you're even asking this question indicates that you've completely
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]
Oh, hell, it's *that* ugly part of the nasty GPLv2 exception. I quite
missed that.
*sigh*
No, that's not the plugin exception... Posted Aug 7, 2009 13:27 UTC (Fri) by DOT (subscriber, #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]
> if git wants to make use of the gcc runtime code
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]
> Or am I missing something here...?
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]
C compilers all require runtime libraries. Lots of things require library
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
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]
Indeed, isn't the issue not just with GPLv2 but with any copyleft licence apart from GPLv3?
Applies to any copyleft licence Posted Jul 28, 2009 9:09 UTC (Tue) by mjw (subscriber, #16740) [Link]
No, I don't think it is a real problem with the GPLv2 either. The problem seems more that people take the clarifications of the GPLv3 "patent grants are explicit when distributing code", "signing bits needed at runtime are part of the corresponding sources to get the runtime binary", "the exception to the system library clause doesn't trump the separate works clause clarification", etc. as if those weren't already (implied) in GPLv2.
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]
I don't think the intent of the licence is relevant here. The GPL version 2 says that if you distribute a derived work then you must distribute the whole work under GPL version 2. Not 'under GPLv2 or another licence that has the same intent'.
Applies to any copyleft licence Posted Jul 28, 2009 12:25 UTC (Tue) by mjw (subscriber, #16740) [Link]
Of course the intend is important. As pointed out above the intent of the system library exception was clarified in GPLv3 and it could be argued that was also what was intended with v2, since that is what Eben himself claimed. If so, the "nit" about how to precisely interpret the wording of "accompanies" in the exception to the exception disappears and all would be fine for everybody.
Applies to any copyleft licence Posted Jul 28, 2009 20:07 UTC (Tue) by epa (subscriber, #39769) [Link]
Ah, I see. You are right. Although if intent is counted, the intent of the copyright holder of the code (who made the decision to grant a licence to it under GPLv2) may be more important than the intent of the person who wrote the licence.
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]
Yes, you are right, in the end it is the copyright holder of the GPLv2-only work whose intent counts the most. But do you really believe that if the FSF says "oops, a specific literal reading could cause a problem for free operation systems, and that obviously isn't the intention, so we explicitly say that and make sure that in GPLv3 such textual ambiguity doesn't exist." That there are copyright holders that will say "yes, I specifically choose GPLv2-only to cause a problem for people wanting to read that particular exception language as intending to cause trouble for free operating systems like Debian"?
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 (✭ supporter ✭, #313) [Link]
the FSF claims that GPLv3 just 'clarifies' or corrects weaknesses in GPLv2, but many other people disagree.
Applies to any copyleft licence Posted Jul 28, 2009 21:08 UTC (Tue) by kleptog (subscriber, #1183) [Link]
Note that in a sense it is 'under GPLv2 or another licence that has the same intent'. If you take some BSD code and combine it with GPL2 code the result can be licensed under GPL2, but that doesn't change the licence of the BSD code. It can't, only the copyright holder can do that. Any subsequent user can remove all the GPL2 stuff and be left with a BSD licensed chunk of code.
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 (subscriber, #52554) [Link]
> "... unless that component itself accompanies the executable."
> [...] > 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
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 michaeljt (subscriber, #39183) [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.
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 (subscriber, #262) [Link]
So, question is the meaning of 'accompanies the executable'.
libgcc and git won't share the same deb file. Is that enough?
Explained in other words Posted Jul 28, 2009 10:45 UTC (Tue) by cortana (subscriber, #24596) [Link]
What is the difference between a Debian package, a ZIP file and an ISO9660 filesystem anyway?
Explained in other words Posted Jul 28, 2009 12:10 UTC (Tue) by MathFox (guest, #6104) [Link]
The problem is that there are several reasonable ways to interpret 'accompanies the executable' and Debian-legal is not entirely sure on what it means. I am sure that it was not the intention of the FSF to create a problem here, but it has happened in the license drafting process.
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 (subscriber, #755) [Link]
Isn't there "mere aggregation" language in there somewhere specifically to protect distributors?
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]
MathFox wrote:
> (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
Explained in other words Posted Jul 29, 2009 20:03 UTC (Wed) by vonbrand (subscriber, #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]
They'll look at whether things are intended to be together, or intended to be combined after download, etc. They won't view Debian+OpenSolaris in the same way as they'd view git+gcc packages for Debian.
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]
> Florian reports that attempts to get clarification from the FSF have gone
> 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]
One solution is to get LLVM-Clang production ready and get distributions to use that instead of GCC.
A new GCC runtime library license snag? Posted Jul 28, 2009 9:48 UTC (Tue) by MisterIO (guest, #36192) [Link]
I agree. By the next release, LLVM-Clang will be production ready for C code.
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]
http://en.wikipedia.org/wiki/Clang
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]
However, one should note that the effort to get FreeBSD working has come as much from FreeBSD as from the LLVM people. There are probably, also, fewer GNU-isms in the FreeBSD source.
A new GCC runtime library license snag? Posted Jul 28, 2009 11:45 UTC (Tue) by Lumag (subscriber, #22579) [Link]
And what about C++? Obj-C, Fortran, etc.? Who can predict which kinds of licensing problems will Clang bring to us? Will it be possible to compile C libraries with Clang and other (C++, etc.) with GCC?
A new GCC runtime library license snag? Posted Jul 28, 2009 12:11 UTC (Tue) by stevenb (guest, #11536) [Link]
The LLVM folks have a surprisingly high success rate for "stealing" GCC front ends and making them work with LLVM. Ada and Fortran already mostly work with LLVM.
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]
Hmmm. Both of them aren't angels. I wouldn't rather trust both of them. However I'd trust Apple less.
A new GCC runtime library license snag? Posted Jul 28, 2009 13:19 UTC (Tue) by boudewijn (subscriber, #14185) [Link]
And what, exactly, has the FSF done to abuse your trust?
A new GCC runtime library license snag? Posted Jul 28, 2009 14:42 UTC (Tue) by bronson (subscriber, #4806) [Link]
Wrote licenses that are now so complex that they don't even understand them themselves?
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]
Three things come to mind:
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
A new GCC runtime library license snag? Posted Jul 28, 2009 16:29 UTC (Tue) by drag (subscriber, #31333) [Link]
> 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.
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.
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]
Not quite sure what the point you're trying to make is... Nobody is cliaming that the FSF is perfect ("an angel") and nobody so far has claimed to agree with the FSF 100%.
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]
IMHO the 'who do you trust' model of software licensing reduces everything to a soap opera of good companies and bad companies and isn't a sane way to make decisions.
A new GCC runtime library license snag? Posted Jul 29, 2009 16:46 UTC (Wed) by Lumag (subscriber, #22579) [Link]
I'd agree with you, if it will be all about simple licensing. OTOH if we talk about 'we can change the license for this software as we'd like to' this is about trust (only).
A new GCC runtime library license snag? Posted Jul 28, 2009 9:32 UTC (Tue) by ikm (subscriber, #493) [Link]
I failed to understand what was that all about. My brains were overheating even with the new GCC runtime library exception alone -- and what's going on here now is just not possible to comprehend at all. The whole thing looks like an extreme case of mental masturbation. Sometimes I start to understand BSD folks.
Seems like a real problem at first sight Posted Jul 30, 2009 2:11 UTC (Thu) by mikov (subscriber, #33179) [Link]
I think this problem is not completely theoretical.
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]
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:
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 (subscriber, #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 michaeljt (subscriber, #39183) [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.
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]
Well it's still theoretical, because nobody has done this yet :) but the point you make is that theoretical does not mean unimportant.
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]
This is rather convoluted but I really think this has already happened a thousand times before and there is no problem whatsoever.
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...
|
|||||||||||||