| |||||||||||||
|
| |||||||||||||
Finding copyright holdersFinding copyright holdersPosted Jul 28, 2009 2:00 UTC (Tue) by JoeBuck (subscriber, #2330)In reply to: Finding copyright holders by gdt Parent article: A new GCC runtime library license snag? 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.
(Log in to post comments)
Finding copyright holders Posted Jul 28, 2009 2:10 UTC (Tue) by dlang (✭ supporter ✭, #313) [Link]
but that change only needs to be approved by the FSF, as opposed to hundreds or thousands of individual developers.
question: before the most recent change to the runtime exception, did it have the same problem with the GPLv2, or is this a result of the new language put in to try and block proprietary GCC modules?
Finding copyright holders Posted Jul 28, 2009 3:55 UTC (Tue) by JoeBuck (subscriber, #2330) [Link] The original idea was that the runtime license would just become GPLv3 plus the exception that was there before, but this was delayed while the plugin language was worked out. It's possible that even without the plugin language there would be an issue, because GPLv2 is quite restrictive.
No, that's not the plugin exception... Posted Jul 28, 2009 16:54 UTC (Tue) by khim (guest, #9252) [Link] Before the most recent change to the runtime exception, did it have the same problem with the GPLv2, or is this a result of the new language put in to try and block proprietary GCC modules? This is result of switch to GPLv3. And it's pretty unlikely FSF will go back on that change. You can tweak exception as much as you want - it'll not fix the problem. The only solution is to offer libgcc under "GPLv2 or later" terms and clearly FSF don't like this solution - it wants to drop GPLv2 altogether.
No, that's not the plugin exception... Posted Aug 1, 2009 23:26 UTC (Sat) by cas (subscriber, #52554) [Link]
> The only solution is to offer libgcc under "GPLv2 or later" terms and
> clearly FSF don't like this solution - it wants to drop GPLv2 altogether
no, that's NOT the only solution. it's not even the right solution, or even one of the right solutions.
the problem is with git, not with gcc.
if git wants to make use of the gcc runtime code, then it is up to git to have a compatible license. it can do that by switching to GPL v3 or by adding an explicit extra permission to its license allowing it to be linked to and distributed with GPL v3 code.
This kind of extra permission is NOT at all unusual with GPL code or software that links to GPL code. e.g. I remember several years back that many Qt & KDE programs had to have extra permission because the Qt license at that time was not quite GPL compatible.
No, that's not the plugin exception... Posted Aug 2, 2009 0:56 UTC (Sun) by dlang (✭ supporter ✭, #313) [Link]
it seems very strange that you blame a software project that uses a license produced by the FSF for incompatibilities caused by the FSF changing the license of another program to a new license that makes it easier to ship proprietary apps than it is to ship open apps.
Who to blame? Posted Aug 2, 2009 4:58 UTC (Sun) by khim (guest, #9252) [Link] Have you read the GPLv2 license? It has separate paragraph dedicated to this this problem: 9. The Free Software Foundation may publish revised and/or new versions of the General Public License from time to time. Such new versions will be similar in spirit to the present version, but may differ in detail to address new problems or concerns. If authors of Git ignored cautions embedded in the very text of the license they are using - then how the hell can you blame anyone else? Git authors knew the license will be changed - it's written in the text of the license attached to Git. They knew how to avoid troubles - again, it's written in the very text of the license attached to Git. They chosen to ignore all this - it's their right, FSF gave this right to him (unlike MPL or CC licenses GPL does not have autoupdate option embedded in the license itself), but the consequences of their choice are theirs to resolve... And the license does not make it easier to ship proprietary programs - if proprietary license include linking-prohibition similar to GPLv2 it can not be used will GCC also... So no, it's hard to blame FSF here: they thought about the problem 18 years ago, they offered the solution back then - but Git authors rejected the solution. That's the problem.
Who to blame? Posted Aug 6, 2009 10:23 UTC (Thu) by SEMW (guest, #52697) [Link]
To be fair to the authors of git etc., I find it very hard to blame someone for not wanting to release their intellectual property under a license, or series of licenses, that they not only haven't read but don't even *exist* yet; for the same reason that I wouldn't blame someone for not wanting to hand over a blank cheque or sign a contract they haven't read.
It's not exactly blank cheque Posted Aug 9, 2009 12:08 UTC (Sun) by khim (guest, #9252) [Link] Yes this is what millions of authors do every single time they release something. Some licenses don't even include opt-out - like widely used Creative Commons licenses, for example. If Git developers don't like to delegate legal problems to FSF they should solve them themselves, don't you think? If they are big enough to ignore advice (included in the text of license they selected, no less!) they should be big enough to deal with fallout...
It's not exactly blank cheque Posted Aug 12, 2009 12:26 UTC (Wed) by SEMW (guest, #52697) [Link]
> Yes this is what millions of authors do every single time they release something. Some licenses don't
> even include opt-out - like widely used Creative Commons licenses, for example.
I've just skimmed through several sample creative commons licenses, and can't see any "or later version" clauses, let alone mandatory ones. The page for all licenses before the current one even explicitely say "A new version of this license is available. ... No works are automatically put under the new license...". Are you sure you're not mistaken?
> If they are big enough to ignore advice (included in the text of license they selected, no less!) they should be big enough to deal with fallout...
Are you suggesting that anyone -- the git authors, Debian, the FSF, whoever -- knew about this before very recently? If you're saying that this side-effect was known when the git authors chose the license, then say so explicitly; the article certainly does not give that impression (and even explicitly says that, in the FSF's case, "This is a perverse result that, probably, was not envisioned or desired...").
Have you actully read the license? Posted Aug 14, 2009 10:37 UTC (Fri) by khim (guest, #9252) [Link] I've just skimmed through several sample creative commons licenses, and can't see any "or later version" clauses, let alone mandatory ones. Is this a joke? Have you read the legal code? You may Distribute or Publicly Perform an Adaptation only under the terms of: (i) this License; (ii) a later version of this License with the same License Elements as this License; (iii) a Creative Commons jurisdiction license (either this or a later license version) that contains the same License Elements as this License (e.g., Attribution-ShareAlike 3.0 US)); (iv) a Creative Commons Compatible License. Version upgrade is emebedded in the text of the license and it's not an option. Sure, you can not change the license for original work, but should you add one line to it... you are free to upgrade. Are you suggesting that anyone -- the git authors, Debian, the FSF, whoever -- knew about this before very recently? Kind of. FSF knew about the problem in general back in 1991 - that's why it included paragraph 9 in first place. Then some people decided that they don't trust FSF enough to allow combining of their code with FSF's code released under new GPLv3 (and later) licenses. Fair enough - but then obviously they are the only ones who can say if libgcc's code is Ok with them or not. If they knew nothing about licensing and ramifications then why they fiddled around with this stuff?
Stable copyleft licence nonsense Posted Aug 2, 2009 11:17 UTC (Sun) by xoddam (subscriber, #2322) [Link]
WHAT????
The Linux Kernel, version 2.6, warns its users that kernel-internal APIs may be revised from time to time for technical reasons (and for the purpose of removing cruft in the kernel) in the file Documentation/stable_api_nonsense.txt.
The GPL, version 2, wants its users that the licence text may be revised from time to time for legal reasons (and for the purpose of advancing free software) in its paragraph 9 (it's Paragraph 14 of version 3).
But it's the Linux kernel developers, and fellow travellers like the Git and Busybox developers, who have chosen not to support version 3 of the GPL.
It's a bit like a vendor of commodity hardware (say, a GPU) whose driver is not yet in-tree deciding they will never, ever support Linux kernel APIs after some API change made in kernel version 2.6.29. That's their choice. But *someone* will want to use that hardware with a later kernel, so *somehow*, the incompatibility will be resolved by someone who cares.
No, that's not the plugin exception... Posted Aug 2, 2009 8:27 UTC (Sun) by nix (subscriber, #2304) [Link]
git 'makes use of' the GCC runtime code by virtue of being *compiled* with
GCC. All git did was be written in C.
What you're saying is 'if you want to be compiled with compiler X, you
This seems seriously skewy to me.
Why can't the FSF take a leaf from Bison (again)?
No, that's not the plugin exception... Posted Aug 3, 2009 10:51 UTC (Mon) by khim (guest, #9252) [Link] What you're saying is 'if you want to be compiled with compiler X, you have to adjust your license to fit'. Several major Linux compilers (icc and GCC, for instance), have incompatible licenses, so you're saying that it should be impossible to have any program on Linux which can be compiled with both compilers and the binary then distributed. ICC does not have this problem since it's not distributed with Git. This seems seriously skewy to me. Me too, but that's what the license says... Why can't the FSF take a leaf from Bison (again)? Huh? They did. Bison has the same problem GCC does. The only difference lies in the fact that Git does not use Bison.
No, that's not the plugin exception... Posted Aug 3, 2009 22:34 UTC (Mon) by nix (subscriber, #2304) [Link]
ICC's *runtime libraries* are distributed with (incorporated into) *git
binaries* if git binaries compiled with ICC are distributed, in *exactly* the same way as libgcc is incorporated into git binaries.
That you're even asking this question indicates that you've completely
No, that's not the plugin exception... Posted Aug 4, 2009 8:26 UTC (Tue) by khim (guest, #9252) [Link] ICC's *runtime libraries* are distributed with (incorporated into) *git binaries* if git binaries compiled with ICC are distributed, in *exactly* the same way as libgcc is incorporated into git binaries. Yes. And still ICC does not have a problem where GCC does. Why? Because ICC's license forbids distribution (runtime libraries can be redistributed while ICC itself can not) and so ICC is not distributed on the same medium as git! This fits the GPL exception to a tee: However, as a special exception, the source code distributed need not include anything that is normally distributed (in either source or binary form) with the major components (compiler, kernel, and so on) of the operating system on which the executable runs, unless that component itself accompanies the executable. The *compiler* inserts calls to libgcc into the object file, and this is then resolved by linking with libgcc. Yes, but it does not change the fact that parts of libgcc ends up in git executable. GPL gives no exception for "compiler-inserted calls", instead it gives exception for "anything that is normally distributed (in either source or binary form) with the major components (compiler, kernel, and so on) of the operating system on which the executable runs" - but this exception is not valid if "that component itself accompanies the executable". GCC accompanies the executable while ICC does not - that's why we have problem with GCC, but not with ICC. Since these parts are needed to recreate binary they are part of the "complete machine-readable copy of the corresponding source code" and now the question is: must these parts be distributed under GPLv2 or do they fall under "special exception". If they fall under exception then Git can be redistributed with GCC for sure, if not - then you can not redistribute Git and GCC on the same medium. Only copyright holder of git can clear this confusion and FSF is not Git's copyright holder so I can not understand why eveyone waits for FSF's response...
No, that's not the plugin exception... Posted Aug 4, 2009 21:05 UTC (Tue) by nix (subscriber, #2304) [Link]
Oh, hell, it's *that* ugly part of the nasty GPLv2 exception. I quite
missed that.
*sigh*
No, that's not the plugin exception... Posted Aug 7, 2009 13:27 UTC (Fri) by DOT (subscriber, #58786) [Link] Does the ICC runtime library allow for relicensing under GPL version 2? That's what needs to happen for the problem to go away. The component that needs to fall under the exception is the ICC runtime library. But that code is injected into the program at compilation time. So that component accompanies the executable, which means it doesn't fall under the exception. Therefore, the ICC runtime library needs to be 1) open source, and 2) licensed under the GPL version 2. I don't believe that is the case, so Git -- compiled with any recent compiler -- cannot be legally distributed.
No, that's not the plugin exception... Posted Aug 6, 2009 5:57 UTC (Thu) by lysse (guest, #3190) [Link]
> if git wants to make use of the gcc runtime code
Aside from finding the idea of a C compiler requiring a runtime library slightly strange, presumably git doesn't particularly care which runtime code it makes use of? In which case, surely the appropriate thing for git to do is incorporate a copy of the last GPL2+-licensed version of libgcc into their own codebase, optionally customise it to suit, and simply compile with whatever option says "no default runtime, please" in future?
Or am I missing something here...?
No, that's not the plugin exception... Posted Aug 6, 2009 8:08 UTC (Thu) by johill (subscriber, #25196) [Link]
> Or am I missing something here...?
Yes. It's not feasible to maintain thousands of packages that way, and makes no sense technically either -- improvements of the runtime lib would never make it into that program, etc.
No, that's not the plugin exception... Posted Aug 7, 2009 23:17 UTC (Fri) by nix (subscriber, #2304) [Link]
C compilers all require runtime libraries. Lots of things require library
calls (e.g. long long maths on 32-bit systems); there is the startup code (on Linux a complex dance of cooperation between GCC and glibc); and there are things like binary decimal support, which has a sizeable runtime library. There are even more nasty things like C++ exception handling, which if it is to work across shared library boundaries needs shared data structures and shared code to touch those data structures. (You might think this is irrelevant to C, but C++ code can throw across C function calls with GCC, as long as the C translation units were compiled with -fexceptions: the relevant parts of the unwinding machinery are thus in the C runtime library, not in the C++ one.)
The compiler generates the calls into this library as it sees fit, and
|
|
||||||||||||