A new GCC runtime library license snag?
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).
Posted Jul 27, 2009 21:53 UTC (Mon)
by Baylink (guest, #755)
[Link] (7 responses)
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.
Posted Jul 28, 2009 7:39 UTC (Tue)
by rsidd (subscriber, #2582)
[Link] (6 responses)
Posted Jul 29, 2009 1:22 UTC (Wed)
by Baylink (guest, #755)
[Link] (2 responses)
Posted Jul 29, 2009 8:05 UTC (Wed)
by rsidd (subscriber, #2582)
[Link] (1 responses)
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:
Posted Aug 2, 2009 1:34 UTC (Sun)
by landley (guest, #6789)
[Link] (2 responses)
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
Posted Aug 2, 2009 5:15 UTC (Sun)
by rsidd (subscriber, #2582)
[Link] (1 responses)
Posted Aug 2, 2009 7:11 UTC (Sun)
by landley (guest, #6789)
[Link]
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
Posted Jul 27, 2009 21:57 UTC (Mon)
by johill (subscriber, #25196)
[Link] (26 responses)
Posted Jul 28, 2009 2:17 UTC (Tue)
by sbergman27 (guest, #10767)
[Link] (25 responses)
Posted Jul 28, 2009 3:39 UTC (Tue)
by coriordan (guest, #7544)
[Link] (24 responses)
Posted Jul 28, 2009 8:45 UTC (Tue)
by rsidd (subscriber, #2582)
[Link] (21 responses)
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.
Posted Jul 28, 2009 18:50 UTC (Tue)
by coriordan (guest, #7544)
[Link] (20 responses)
Posted Jul 28, 2009 20:06 UTC (Tue)
by sbergman27 (guest, #10767)
[Link] (5 responses)
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.
Posted Jul 28, 2009 21:32 UTC (Tue)
by coriordan (guest, #7544)
[Link] (4 responses)
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?
Posted Jul 28, 2009 22:19 UTC (Tue)
by sbergman27 (guest, #10767)
[Link] (1 responses)
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?
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."
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.
Posted Jul 29, 2009 12:05 UTC (Wed)
by DonDiego (guest, #24141)
[Link]
No, both should be shorter, version 3 just makes the problem worse.
Posted Jul 29, 2009 12:01 UTC (Wed)
by DonDiego (guest, #24141)
[Link] (13 responses)
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.
Posted Jul 29, 2009 18:44 UTC (Wed)
by coriordan (guest, #7544)
[Link] (12 responses)
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.
Posted Jul 29, 2009 20:51 UTC (Wed)
by bronson (subscriber, #4806)
[Link] (9 responses)
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?
Posted Jul 30, 2009 5:21 UTC (Thu)
by khim (subscriber, #9252)
[Link] (8 responses)
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.
Posted Jul 30, 2009 12:40 UTC (Thu)
by foom (subscriber, #14868)
[Link] (1 responses)
Well, there's certainly one obvious and trivially correct thing they could do...
Posted Jul 31, 2009 8:15 UTC (Fri)
by mjthayer (guest, #39183)
[Link]
Posted Jul 30, 2009 16:03 UTC (Thu)
by bronson (subscriber, #4806)
[Link] (5 responses)
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.
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.)
Posted Jul 31, 2009 7:25 UTC (Fri)
by khim (subscriber, #9252)
[Link] (3 responses)
They did so - it's called GPLv3. 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. It is useful anywhere (for free and proprietary programs alike) -
where other side does not prohibit it. 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.
Posted Aug 6, 2009 10:10 UTC (Thu)
by SEMW (guest, #52697)
[Link] (2 responses)
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.
Posted Aug 9, 2009 11:58 UTC (Sun)
by khim (subscriber, #9252)
[Link] (1 responses)
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... 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!
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.
Posted Jul 30, 2009 10:17 UTC (Thu)
by rsidd (subscriber, #2582)
[Link]
Posted Jul 30, 2009 19:07 UTC (Thu)
by DonDiego (guest, #24141)
[Link]
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...
Posted Jul 30, 2009 5:36 UTC (Thu)
by grahammm (guest, #773)
[Link] (1 responses)
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....
Posted Jul 27, 2009 22:14 UTC (Mon)
by JoeBuck (subscriber, #2330)
[Link] (11 responses)
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.
Posted Jul 28, 2009 0:32 UTC (Tue)
by fuhchee (guest, #40059)
[Link] (5 responses)
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.
Posted Jul 28, 2009 1:08 UTC (Tue)
by JoeBuck (subscriber, #2330)
[Link] (4 responses)
Posted Jul 28, 2009 18:28 UTC (Tue)
by mingo (guest, #31122)
[Link] (3 responses)
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.
Posted Jul 29, 2009 8:11 UTC (Wed)
by mjw (subscriber, #16740)
[Link] (2 responses)
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...
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)
Posted Jul 28, 2009 0:33 UTC (Tue)
by dlang (guest, #313)
[Link] (2 responses)
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)
Posted Jul 28, 2009 12:08 UTC (Tue)
by stevenb (guest, #11536)
[Link] (1 responses)
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
Posted Aug 6, 2009 9:18 UTC (Thu)
by forthy (guest, #1525)
[Link] (1 responses)
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.
Posted Aug 6, 2009 9:45 UTC (Thu)
by hppnq (guest, #14462)
[Link]
The relevant part of the GPLv2 license is:
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.
Posted Jul 27, 2009 23:54 UTC (Mon)
by coriordan (guest, #7544)
[Link] (45 responses)
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.)
Posted Jul 28, 2009 0:45 UTC (Tue)
by gjmarter (guest, #5777)
[Link] (36 responses)
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?
Posted Jul 28, 2009 0:56 UTC (Tue)
by coriordan (guest, #7544)
[Link] (35 responses)
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.
Posted Jul 28, 2009 1:23 UTC (Tue)
by JoeBuck (subscriber, #2330)
[Link] (33 responses)
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.
Posted Jul 28, 2009 1:47 UTC (Tue)
by gdt (subscriber, #6284)
[Link] (21 responses)
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".
Posted Jul 28, 2009 2:00 UTC (Tue)
by JoeBuck (subscriber, #2330)
[Link] (20 responses)
Posted Jul 28, 2009 2:10 UTC (Tue)
by dlang (guest, #313)
[Link] (19 responses)
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?
Posted Jul 28, 2009 3:55 UTC (Tue)
by JoeBuck (subscriber, #2330)
[Link]
Posted Jul 28, 2009 16:54 UTC (Tue)
by khim (subscriber, #9252)
[Link] (17 responses)
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.
Posted Aug 1, 2009 23:26 UTC (Sat)
by cas (guest, #52554)
[Link] (16 responses)
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.
Posted Aug 2, 2009 0:56 UTC (Sun)
by dlang (guest, #313)
[Link] (6 responses)
Posted Aug 2, 2009 4:58 UTC (Sun)
by khim (subscriber, #9252)
[Link] (4 responses)
Have you read the GPLv2 license? It has separate paragraph dedicated to
this this problem: 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.
Posted Aug 6, 2009 10:23 UTC (Thu)
by SEMW (guest, #52697)
[Link] (3 responses)
Posted Aug 9, 2009 12:08 UTC (Sun)
by khim (subscriber, #9252)
[Link] (2 responses)
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...
Posted Aug 12, 2009 12:26 UTC (Wed)
by SEMW (guest, #52697)
[Link] (1 responses)
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...").
Posted Aug 14, 2009 10:37 UTC (Fri)
by khim (subscriber, #9252)
[Link]
Is this a joke? Have you read the legal
code? 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. 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?
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.
Posted Aug 2, 2009 8:27 UTC (Sun)
by nix (subscriber, #2304)
[Link] (5 responses)
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)?
Posted Aug 3, 2009 10:51 UTC (Mon)
by khim (subscriber, #9252)
[Link] (4 responses)
ICC does not have this problem since it's not distributed with Git. Me too, but that's what the license says... Huh? They did. Bison has the same problem GCC does. The only difference
lies in the fact that Git does not use Bison.
Posted Aug 3, 2009 22:34 UTC (Mon)
by nix (subscriber, #2304)
[Link] (3 responses)
That you're even asking this question indicates that you've completely
Posted Aug 4, 2009 8:26 UTC (Tue)
by khim (subscriber, #9252)
[Link] (2 responses)
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. 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...
Posted Aug 4, 2009 21:05 UTC (Tue)
by nix (subscriber, #2304)
[Link]
*sigh*
Posted Aug 7, 2009 13:27 UTC (Fri)
by DOT (subscriber, #58786)
[Link]
Posted Aug 6, 2009 5:57 UTC (Thu)
by lysse (guest, #3190)
[Link] (2 responses)
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...?
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.
Posted Aug 7, 2009 23:17 UTC (Fri)
by nix (subscriber, #2304)
[Link]
The compiler generates the calls into this library as it sees fit, and
Posted Jul 28, 2009 7:47 UTC (Tue)
by mjw (subscriber, #16740)
[Link] (9 responses)
So, it would be good to get this explicit clarification somewhere on gcc.gnu.org.
Posted Jul 28, 2009 8:32 UTC (Tue)
by epa (subscriber, #39769)
[Link] (8 responses)
Posted Jul 28, 2009 9:09 UTC (Tue)
by mjw (subscriber, #16740)
[Link] (7 responses)
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.
Posted Jul 28, 2009 12:10 UTC (Tue)
by epa (subscriber, #39769)
[Link] (6 responses)
Posted Jul 28, 2009 12:25 UTC (Tue)
by mjw (subscriber, #16740)
[Link] (4 responses)
Posted Jul 28, 2009 20:07 UTC (Tue)
by epa (subscriber, #39769)
[Link] (3 responses)
Posted Jul 28, 2009 20:12 UTC (Tue)
by hppnq (guest, #14462)
[Link]
Posted Jul 29, 2009 8:07 UTC (Wed)
by mjw (subscriber, #16740)
[Link] (1 responses)
IMHO, unless a copyright holder explicitly tells you to ignore the stated intent of the license drafter, you can safely ignore that possibility.
Posted Jul 29, 2009 17:54 UTC (Wed)
by dlang (guest, #313)
[Link]
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).
Posted Aug 1, 2009 23:14 UTC (Sat)
by cas (guest, #52554)
[Link]
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.
Posted Jul 29, 2009 10:29 UTC (Wed)
by mjthayer (guest, #39183)
[Link]
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 :)
Posted Jul 28, 2009 7:20 UTC (Tue)
by elama (guest, #262)
[Link] (7 responses)
libgcc and git won't share the same deb file. Is that enough?
Posted Jul 28, 2009 10:45 UTC (Tue)
by cortana (subscriber, #24596)
[Link]
Posted Jul 28, 2009 12:10 UTC (Tue)
by MathFox (guest, #6104)
[Link] (5 responses)
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.
Posted Jul 29, 2009 1:41 UTC (Wed)
by Baylink (guest, #755)
[Link] (1 responses)
Posted Jul 30, 2009 5:28 UTC (Thu)
by khim (subscriber, #9252)
[Link]
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...
Posted Jul 29, 2009 11:14 UTC (Wed)
by garloff (subscriber, #319)
[Link]
It would be enough if Debian compiled a GPLv2+ version of libgcc and made
Posted Jul 29, 2009 20:03 UTC (Wed)
by vonbrand (subscriber, #4458)
[Link] (1 responses)
"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.
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.
Posted Jul 28, 2009 3:16 UTC (Tue)
by paulv (guest, #14911)
[Link]
This seems odd -- did our editor attempt to make contact with the FSF at all in the process of writing this article?
Posted Jul 28, 2009 5:47 UTC (Tue)
by ptman (subscriber, #57271)
[Link] (14 responses)
Posted Jul 28, 2009 9:48 UTC (Tue)
by MisterIO (guest, #36192)
[Link] (13 responses)
Posted Jul 28, 2009 10:14 UTC (Tue)
by mosfet (guest, #45339)
[Link] (2 responses)
Posted Jul 28, 2009 14:55 UTC (Tue)
by MisterIO (guest, #36192)
[Link] (1 responses)
Posted Jul 28, 2009 15:44 UTC (Tue)
by rsidd (subscriber, #2582)
[Link]
Posted Jul 28, 2009 11:45 UTC (Tue)
by Lumag (subscriber, #22579)
[Link] (9 responses)
Posted Jul 28, 2009 12:11 UTC (Tue)
by stevenb (guest, #11536)
[Link] (8 responses)
As for Clang licensing problems, the question is: "Who do you trust more: Apple or the FSF"... ;-)
Posted Jul 28, 2009 13:03 UTC (Tue)
by Lumag (subscriber, #22579)
[Link] (5 responses)
Posted Jul 28, 2009 13:19 UTC (Tue)
by halla (subscriber, #14185)
[Link] (4 responses)
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!
Posted Jul 28, 2009 15:25 UTC (Tue)
by foom (subscriber, #14868)
[Link] (2 responses)
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
Posted Jul 28, 2009 16:29 UTC (Tue)
by drag (guest, #31333)
[Link] (1 responses)
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.
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!
Posted Jul 29, 2009 11:57 UTC (Wed)
by epa (subscriber, #39769)
[Link] (1 responses)
Posted Jul 29, 2009 16:46 UTC (Wed)
by Lumag (subscriber, #22579)
[Link]
Posted Jul 28, 2009 9:32 UTC (Tue)
by ikm (guest, #493)
[Link]
Posted Jul 30, 2009 2:11 UTC (Thu)
by mikov (guest, #33179)
[Link] (5 responses)
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?
Posted Jul 30, 2009 5:45 UTC (Thu)
by khim (subscriber, #9252)
[Link] (3 responses)
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...
Posted Jul 30, 2009 16:35 UTC (Thu)
by mikov (guest, #33179)
[Link]
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!
Posted Jul 31, 2009 8:34 UTC (Fri)
by mjthayer (guest, #39183)
[Link] (1 responses)
>> 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.
Posted Aug 2, 2009 4:34 UTC (Sun)
by khim (subscriber, #9252)
[Link]
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...
Posted Jul 30, 2009 12:51 UTC (Thu)
by jond (subscriber, #37669)
[Link]
Posted Jul 30, 2009 6:46 UTC (Thu)
by jimbo (subscriber, #6689)
[Link]
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.
Posted Jul 30, 2009 19:29 UTC (Thu)
by spitzak (guest, #4593)
[Link] (1 responses)
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.
Posted Jul 31, 2009 4:34 UTC (Fri)
by khim (subscriber, #9252)
[Link]
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. 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. Probably not, but then degree of automatization matter. Again: what was the intent of all these dances, why you are doing it
this way and not that way, etc. 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. 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...
A new GCC runtime library license snag?
A new GCC runtime library license snag?
A new GCC runtime library license snag?
A new GCC runtime library license snag?
A new GCC runtime library license snag?
A new GCC runtime library license snag?
A new GCC runtime library license snag?
A new GCC runtime library license snag?
> intervals (the last on May 20, 2009).
> optimisation?
> 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.
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?
A new GCC runtime library license snag?
What would you do differently in the licences?
I want Minix's size but Linux's functionality....
I want Minix's size but Linux's functionality....
What part of GPLv3 is bad?
I want Minix's size but Linux's functionality....
I want Minix's size but Linux's functionality....
That perfect GPLv2
That perfect GPLv2
Now the previously too-long GPLv2 has become "just right"...
"""
but which unnecessary sentences should be removed?
"""
That perfect GPLv2
That perfect GPLv2
That perfect GPLv2
> target of "make it shorter!"
GPL version 3 problems
how v3 is much much simpler
how v3 is much much simpler
Fatal oversight
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
Change the license on libgcc to GPLv2+ :)
Fatal oversight
Fatal oversight
Fatal oversight
Here we go again...
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
even just an addendum describing language intent.
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.
Here we go again...
This is not GPLv2 fault, sorry...
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).
This is not GPLv2 fault, sorry...
how v3 is much much simpler
how v3 is much much simpler (after taking a hit from the crack pipe)
> meaning of "distribute" in every country.
> existing meanings with regard to software. This means that the licence can
> explain the intended meaning.
> but overall, knowing what the licence really means is much much easier.
I want Minix's size but Linux's functionality....
I want Minix's size but Linux's functionality....
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.
Some clarifications
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.
Some clarifications
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
Some clarifications
Some clarifications
Some clarifications
Some clarifications
Some clarifications
Some clarifications
Some clarifications
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
GPLv2 only code
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.
either version 2 of the License, or (at your option) any later version
Explained in other words
Explained in other words
Explained in other words
GPLv2 states:
but there is 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.
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 ...
Finding copyright holders
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
Finding copyright holders
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.
Finding copyright holders
No, that's not the plugin exception...
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?
No, that's not the plugin exception...
> clearly FSF don't like this solution - it wants to drop GPLv2 altogether
No, that's not the plugin exception...
Who to blame?
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.Who to blame?
It's not exactly blank cheque
It's not exactly blank cheque
> even include opt-out - like widely used Creative Commons licenses, for example.
Have you actully read the license?
I've just skimmed through several sample creative commons
licenses, and can't see any "or later version" clauses, let alone mandatory
ones.
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.
Are you suggesting that anyone -- the git authors, Debian, the
FSF, whoever -- knew about this before very recently?
Stable copyleft licence nonsense
No, that's not the plugin exception...
GCC. All git did was be written in C.
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.
No, that's not the plugin exception...
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...
binaries* if git binaries compiled with ICC are distributed, in *exactly*
the same way as libgcc is incorporated into git binaries.
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...
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.
The *compiler* inserts calls to libgcc into the object file,
and this is then resolved by linking with libgcc.
No, that's not the plugin exception...
missed that.
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...
No, that's not the plugin exception...
No, that's not the plugin exception...
No, that's not the plugin exception...
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.)
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).
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:
but there is an exception to the exceptiuon
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
Applies to any copyleft licence
Applies to any copyleft licence
Applies to any copyleft licence
Applies to any copyleft licence
Applies to any copyleft licence
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
Applies to any copyleft licence
Applies to any copyleft licence
Applies to any copyleft licence
but there is an exception
> [...]
> RMS wasn't thinking of entirely-free OSes when he wrote that;
> component itself accompanies the executable" is considered to be removed.
Explained in other words
>
>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.
Explained in other words
Or may they not share the same CD, DVD, Distributor?
Explained in other words
Explained in other words
Explained in other words
Yes and no
Isn't there "mere aggregation" language in there somewhere
specifically to protect distributors?
Explained in other words
> (Well, as a stopgap they could compile GPLv2 only programs with a
> GPLv2+ version of gcc...)
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
human judges
A new GCC runtime library license snag?
> unanswered since last April.
A new GCC runtime library license snag?
A new GCC runtime library license snag?
Will LLVM-Clang by next release compile a bootable Linux kernel?
A new GCC runtime library license snag?
A new GCC runtime library license snag?
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?
A new GCC runtime library license snag?
A new GCC runtime library license snag?
A new GCC runtime library license snag?
A new GCC runtime library license snag?
A new GCC runtime library license snag?
A new GCC runtime library license snag?
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.
done many remarkably stupid things.
A new GCC runtime library license snag?
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.
A new GCC runtime library license snag?
A new GCC runtime library license snag?
A new GCC runtime library license snag?
A new GCC runtime library license snag?
Seems like a real problem at first sight
They could but the case will not go very far
They could but the case will not go very far
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
There are exactly one way to do this - and it's not what Debian wants...
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.
Seems like a real problem at first sight
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.
A new GCC runtime library license snag?
--
jimbo
A new GCC runtime library license snag?
Are you sure?
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.
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.