LWN: Comments on "A new GCC runtime library license snag?"

Have you actully read the license?

khim — Fri, 14 Aug 2009 10:37:52 +0000

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?

This is not GPLv2 fault, sorry...

SEMW — Wed, 12 Aug 2009 12:36:00 +0000

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

It's not exactly blank cheque

SEMW — Wed, 12 Aug 2009 12:26:36 +0000

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

It's not exactly blank cheque

khim — Sun, 09 Aug 2009 12:08:05 +0000

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

This is not GPLv2 fault, sorry...

khim — Sun, 09 Aug 2009 11:58:14 +0000

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!

No, that's not the plugin exception...

nix — Fri, 07 Aug 2009 23:17:21 +0000

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

No, that's not the plugin exception...

DOT — Fri, 07 Aug 2009 13:27:07 +0000

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.

Who to blame?

SEMW — Thu, 06 Aug 2009 10:23:53 +0000

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.

Here we go again...

SEMW — Thu, 06 Aug 2009 10:10:19 +0000

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

GPLv2 only code

hppnq — Thu, 06 Aug 2009 09:45:54 +0000

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.

GPLv2 only code

forthy — Thu, 06 Aug 2009 09:18:46 +0000

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.

No, that's not the plugin exception...

johill — Thu, 06 Aug 2009 08:08:24 +0000

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

lysse — Thu, 06 Aug 2009 05:57:30 +0000

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

nix — Tue, 04 Aug 2009 21:05:05 +0000

Oh, hell, it's *that* ugly part of the nasty GPLv2 exception. I quite
missed that.

*sigh*

No, that's not the plugin exception...

khim — Tue, 04 Aug 2009 08:26:00 +0000

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

nix — Mon, 03 Aug 2009 22:34:10 +0000

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

khim — Mon, 03 Aug 2009 10:51:28 +0000

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.

Stable copyleft licence nonsense

xoddam — Sun, 02 Aug 2009 11:17:08 +0000

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

nix — Sun, 02 Aug 2009 08:27:56 +0000

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

A new GCC runtime library license snag?

landley — Sun, 02 Aug 2009 07:11:01 +0000

> 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
> optimisation?

It's uninteresting because five years ago, Fabrice came up with a specific list of things required to build an unmodified (2.4) Linux kernel, and it still can't do it today, and making it do it isn't a goal of the current developers (let alone building 2.6, busybox, and uClibc):

http://bellard.org/tcc/tccboot_readme.html

Note that building a 2.6 kernel is harder than building a 2.4 kernel. The two big pieces of infrastructure missing are variable length arrays and simple dead code elimination, and neither is currently under active development. (I was working on both when they drove me off, now I don't care.)

For a couple years there, I did more work on it than the rest of the tcc development community combined. (Not because I really had time or expertise, but because nobody ELSE was doing it.) Since I left, except for the guy who added the x86-64 target, the rest of the development community has implemented the occasional bugfix. Maybe it's changed in the past few months, I haven't been paying attention, but list traffic was still mostly bug reports from windows people last I checked. (The project's mailing list often went weeks between posts, and the majority of the traffic was about Windows. Not very interesting.)

> People who want to use C in the first place care more about fast
> binaries than fast compilation, and if development time (as in
> compilation time and other things) is more important than runtime speed,
> there are other and better languages, it seems to me.

Sure. But the compiler/interpreter/runtime for those languages are implemented in C. If you're creating a self-bootstrapping environment, you need a C compiler.

What attracted me to tinycc is that it was _simple_. The entire compiler is about 100k lines of source, it just needed a huge cleanup and refactoring to be extended to support multiple architecture targets, build a full Linux kernel, be maintainable by anybody but its original author...

What I really wanted to do was refactor tinycc into a busybox-like swiss army knife executable providing "ld", "cc", "as", "strip", and so on so it could properly replace gcc and binutils. It would also be good to look into using qemu's new code generator (tcg) as the back-end rather than trying to maintain a dozen processor targets with a half-dozen variants each.

But the existing tinycc development community has little interest in doing any new work on it. Change to existing code seems to upset them.

The smallest self-bootstrapping Linux system is, theoretically, the linux kernel, uClibc, a swiss-army-knifed tcc, and busybox extended a bit to include things like "make" and a bash replacement sh. Alas, in the past 5 years we haven't come noticeably closer to that happening.

Rob

A new GCC runtime library license snag?

rsidd — Sun, 02 Aug 2009 05:15:00 +0000

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.

Who to blame?

khim — Sun, 02 Aug 2009 04:58:39 +0000

Have you read the GPLv2 license? It has separate paragraph dedicated to this this problem:

9. The Free Software Foundation may publish revised and/or new versions of the General Public License from time to time. Such new versions will be similar in spirit to the present version, but may differ in detail to address new problems or concerns.

Each version is given a distinguishing version number. If the Program specifies a version number of this License which applies to it and "any later version", you have the option of following the terms and conditions either of that version or of any later version published by the Free Software Foundation. If the Program does not specify a version number of this License, you may choose any version ever published by the Free Software Foundation.

If authors of Git ignored cautions embedded in the very text of the license they are using - then how the hell can you blame anyone else? Git authors knew the license will be changed - it's written in the text of the license attached to Git. They knew how to avoid troubles - again, it's written in the very text of the license attached to Git. They chosen to ignore all this - it's their right, FSF gave this right to him (unlike MPL or CC licenses GPL does not have autoupdate option embedded in the license itself), but the consequences of their choice are theirs to resolve...

And the license does not make it easier to ship proprietary programs - if proprietary license include linking-prohibition similar to GPLv2 it can not be used will GCC also...

So no, it's hard to blame FSF here: they thought about the problem 18 years ago, they offered the solution back then - but Git authors rejected the solution. That's the problem.

There are exactly one way to do this - and it's not what Debian wants...

khim — Sun, 02 Aug 2009 04:34:40 +0000

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

A new GCC runtime library license snag?

landley — Sun, 02 Aug 2009 01:34:49 +0000

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?

landley — Sun, 02 Aug 2009 01:30:23 +0000

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:

http://oreilly.com/openbook/freedom/ch11.html

No, that's not the plugin exception...

dlang — Sun, 02 Aug 2009 00:56:28 +0000

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.

No, that's not the plugin exception...

cas — Sat, 01 Aug 2009 23:26:07 +0000

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

but there is an exception

cas — Sat, 01 Aug 2009 23:14:39 +0000

> "... 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
> component itself accompanies the executable" is considered to be removed.

there's a reason for that exception. it's to prevent people from subverting the intent of the GPL and merging it with proprietary code by claiming that they are merely aggregating the work.

I want Minix's size but Linux's functionality....

coriordan — Sat, 01 Aug 2009 00:05:15 +0000

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

They could but the case will not go very far

mjthayer — Fri, 31 Jul 2009 08:34:28 +0000

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

Fatal oversight

mjthayer — Fri, 31 Jul 2009 08:15:01 +0000

I think that that is the most sensible comment I have seen on this thread so far.

Here we go again...

khim — Fri, 31 Jul 2009 07:25:48 +0000

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.

Are you sure?

khim — Fri, 31 Jul 2009 04:34:33 +0000

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

A new GCC runtime library license snag?

spitzak — Thu, 30 Jul 2009 19:29:53 +0000

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.

how v3 is much much simpler (after taking a hit from the crack pipe)

DonDiego — Thu, 30 Jul 2009 19:07:08 +0000

> 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
> existing meanings with regard to software. This means that the licence can
> explain the intended meaning.

I wish it did explain the intended meaning. Have you understood the intended meaning and difference between "propagate" and "convey"? I still fail to clearly see a difference and the GPL FAQ obscures the point further.

> So I just read the licence. The licence *text* itself is more complex,
> but overall, knowing what the licence really means is much much easier.

This is a contradiction. A complex text, by its nature, lends itself more to different interpretations than a clear and simple one. How can you now be sure that your interpretation is the intended one? And who guarantees that a judge will not disagree?

But the main problem remains: The target audience seems to have shifted from laypersons to experts in reading legalese. This is very sad and counterproductive. I myself will not release code under v3 for the foreseeable future and will not suggest using v3 to anybody, maybe even recommend to stay away from it when asked for licensing advice. I bet I am far from the only person that thinks so and I do not see people around me rushing to adopt v3, on the contrary. This cannot have been what the authors of v3 had in mind.

I shudder when I think what v4 or v5 might look like...

They could but the case will not go very far

mikov — Thu, 30 Jul 2009 16:35:29 +0000

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!

Fatal oversight

jordanb — Thu, 30 Jul 2009 16:18:31 +0000

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

Fatal oversight

bronson — Thu, 30 Jul 2009 16:03:25 +0000

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

Seems like a real problem at first sight

jond — Thu, 30 Jul 2009 12:51:55 +0000

Well it's still theoretical, because nobody has done this yet :) but the point you make is that theoretical does not mean unimportant.

Fatal oversight

foom — Thu, 30 Jul 2009 12:40:26 +0000

> 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...
Change the license on libgcc to GPLv2+ :)