No, that's not the plugin exception...
No, that's not the plugin exception...
Posted Jul 28, 2009 16:54 UTC (Tue) by khim (subscriber, #9252)In reply to: Finding copyright holders by dlang
Parent article: A new GCC runtime library license snag?
Before the most recent change to the runtime exception, did it have the same problem with the GPLv2, or is this a result of the new language put in to try and block proprietary GCC modules?
This is result of switch to GPLv3. And it's pretty unlikely FSF will go back on that change. You can tweak exception as much as you want - it'll not fix the problem. The only solution is to offer libgcc under "GPLv2 or later" terms and clearly FSF don't like this solution - it wants to drop GPLv2 altogether.
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
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).