| |||||||||||||
|
| |||||||||||||
Explained in other wordsExplained in other wordsPosted Jul 27, 2009 23:54 UTC (Mon) by coriordan (guest, #7544)Parent article: A new GCC runtime library license snag?
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.)
(Log in to post comments)
Explained in other words Posted Jul 28, 2009 0:45 UTC (Tue) by gjmarter (subscriber, #5777) [Link]
I don't understand this yet. In particular, I don't see the requirement in GPL2 that you have distribute the complete source code under a GPL2 license. In GPL2 section 3.a It says "...which must be distributed under the terms of Sections 1 and 2 above..." 3.b is similar.
So either the requirement that the complete source must be GPL2 is somewhere else in the license, or the problem is that Sections 1 and/or 2 of GPL2 are incompatible with the GCC license somehow.
Can you shed some light on that?
Explained in other words Posted Jul 28, 2009 0:56 UTC (Tue) by coriordan (guest, #7544) [Link] The problem is section 2b: b) You must cause any work that you distribute or publish, that in whole or in part contains or is derived from the Program or any part thereof, to be licensed as a whole at no charge to all third parties under the terms of this License. So when section 3 says "must be distributed under the terms of Sections 1 and 2 above", section 2b kicks in. And I can't comply with 2b because I can't make the GCC runtime libraries source code available under "this License" when "this License" means "GPLv2". The GCC runtime library exception only solves the problem of distributing binaries.
but there is an exception Posted Jul 28, 2009 1:23 UTC (Tue) by JoeBuck (subscriber, #2330) [Link] GPLv2 states:However, as a special exception, the source code distributed need not include anything that is normally distributed (in either source or binary form) with the major components (compiler, kernel, and so on) of the operating system on which the executable runs, unless that component itself accompanies the executable.What this means is that your git distribution is completely legal: the gcc runtime library is a major component of the operating system on which the executable runs (even for non-GNU systems, the compiler counts as a major component). Or, almost ... I consider the clause "unless that component itself accompanies the executable" to be a major flaw in GPLv2, and it seems to be the nit. RMS wasn't thinking of entirely-free OSes when he wrote that; he was thinking of proprietary OSes throwing the kitchen sink into "system libraries" and shipping them separately to go with GNU software, I think. The claim is that the violation happens if a distro includes git and the libgcc runtime on the same disk. Note that there's no violation if you download git as a .deb or RPM. Maybe the workaround is for git and similar GPLv2-only projects to change their license. Say that the license is GPLv2, except that the phrase "unless that component itself accompanies the executable" is considered to be removed.
Finding copyright holders Posted Jul 28, 2009 1:47 UTC (Tue) by gdt (subscriber, #6284) [Link] Maybe the workaround is for git and similar GPLv2-only projects to change their license. That depends who holds the copyright. In some important projects there is no copyright assignment. In those projects to alter the license you need to find all of the authors (and perhaps their employers, their estates, their divorced partners, their major creditors) and obtain their agreement to the change. People in these comments find it difficult to even understand the licensing problem, so the motivation for the massive amount of work to obtain the permission of many people for a license change doesn't seem likely. Even then, all it takes is a significant contributor to say "no".
Finding copyright holders Posted Jul 28, 2009 2:00 UTC (Tue) by JoeBuck (subscriber, #2330) [Link] It works both ways; getting a change to the runtime library exception terms, if it's decided that this is what is needed, is also going to be an extremely laborious process.
Finding copyright holders Posted Jul 28, 2009 2:10 UTC (Tue) by dlang (✭ supporter ✭, #313) [Link]
but that change only needs to be approved by the FSF, as opposed to hundreds or thousands of individual developers.
question: before the most recent change to the runtime exception, did it have the same problem with the GPLv2, or is this a result of the new language put in to try and block proprietary GCC modules?
Finding copyright holders Posted Jul 28, 2009 3:55 UTC (Tue) by JoeBuck (subscriber, #2330) [Link] The original idea was that the runtime license would just become GPLv3 plus the exception that was there before, but this was delayed while the plugin language was worked out. It's possible that even without the plugin language there would be an issue, because GPLv2 is quite restrictive.
No, that's not the plugin exception... Posted Jul 28, 2009 16:54 UTC (Tue) by khim (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
but there is an exception to the exceptiuon Posted Jul 28, 2009 7:47 UTC (Tue) by mjw (subscriber, #16740) [Link] I think this is the right interpretation of the "nit". There was a similar uncertainty about OpenSolaris, which mainly uses the GPL-incompatbile, but free, CDDL license. Which apparently Eben Moglen clarified:During the discussion, Eben Moglen took special care to assert that he always believed the GPL v2 should be interpreted in the way GPL v3 now makes explicit - it was never the intent to prevent aggregation of otherwise unrelated code because of the GPL being triggered just because a system function or C runtime was invoked. I found that clarification especially valuable.http://www.opensolaris.org/jive/thread.jspa?messageID=21134&h;#21134 So, it would be good to get this explicit clarification somewhere on gcc.gnu.org.
Applies to any copyleft licence Posted Jul 28, 2009 8:32 UTC (Tue) by epa (subscriber, #39769) [Link]
Indeed, isn't the issue not just with GPLv2 but with any copyleft licence apart from GPLv3?
Applies to any copyleft licence Posted Jul 28, 2009 9:09 UTC (Tue) by mjw (subscriber, #16740) [Link]
No, I don't think it is a real problem with the GPLv2 either. The problem seems more that people take the clarifications of the GPLv3 "patent grants are explicit when distributing code", "signing bits needed at runtime are part of the corresponding sources to get the runtime binary", "the exception to the system library clause doesn't trump the separate works clause clarification", etc. as if those weren't already (implied) in GPLv2.
What seems to be happening is that instead of taking these as clarifications of the intent of v2, they are taken as some kind of fatal flaws in the old text. Instead of taking v3 and using it as a guide to the intend of v2.
Things would be much easier if people saw v3 as just a clarification of the text and intent of what v2 always already was about.
Applies to any copyleft licence Posted Jul 28, 2009 12:10 UTC (Tue) by epa (subscriber, #39769) [Link]
I don't think the intent of the licence is relevant here. The GPL version 2 says that if you distribute a derived work then you must distribute the whole work under GPL version 2. Not 'under GPLv2 or another licence that has the same intent'.
Applies to any copyleft licence Posted Jul 28, 2009 12:25 UTC (Tue) by mjw (subscriber, #16740) [Link]
Of course the intend is important. As pointed out above the intent of the system library exception was clarified in GPLv3 and it could be argued that was also what was intended with v2, since that is what Eben himself claimed. If so, the "nit" about how to precisely interpret the wording of "accompanies" in the exception to the exception disappears and all would be fine for everybody.
Applies to any copyleft licence Posted Jul 28, 2009 20:07 UTC (Tue) by epa (subscriber, #39769) [Link]
Ah, I see. You are right. Although if intent is counted, the intent of the copyright holder of the code (who made the decision to grant a licence to it under GPLv2) may be more important than the intent of the person who wrote the licence.
Applies to any copyleft licence Posted Jul 28, 2009 20:12 UTC (Tue) by hppnq (subscriber, #14462) [Link] One has to assume that the intent of the person who choose the license was to try and understand the intent of the person who wrote it. ;-)
Applies to any copyleft licence Posted Jul 29, 2009 8:07 UTC (Wed) by mjw (subscriber, #16740) [Link]
Yes, you are right, in the end it is the copyright holder of the GPLv2-only work whose intent counts the most. But do you really believe that if the FSF says "oops, a specific literal reading could cause a problem for free operation systems, and that obviously isn't the intention, so we explicitly say that and make sure that in GPLv3 such textual ambiguity doesn't exist." That there are copyright holders that will say "yes, I specifically choose GPLv2-only to cause a problem for people wanting to read that particular exception language as intending to cause trouble for free operating systems like Debian"?
IMHO, unless a copyright holder explicitly tells you to ignore the stated intent of the license drafter, you can safely ignore that possibility.
Applies to any copyleft licence Posted Jul 29, 2009 17:54 UTC (Wed) by dlang (✭ supporter ✭, #313) [Link]
the FSF claims that GPLv3 just 'clarifies' or corrects weaknesses in GPLv2, but many other people disagree.
Applies to any copyleft licence Posted Jul 28, 2009 21:08 UTC (Tue) by kleptog (subscriber, #1183) [Link]
Note that in a sense it is 'under GPLv2 or another licence that has the same intent'. If you take some BSD code and combine it with GPL2 code the result can be licensed under GPL2, but that doesn't change the licence of the BSD code. It can't, only the copyright holder can do that. Any subsequent user can remove all the GPL2 stuff and be left with a BSD licensed chunk of code.
It basically all it means is that all constituent parts must meet *at least* the requirements of the GPL2 but it may grant more rights. The problem being that whatever GCC is doing grants less.
Messy, but I'm not sure if there's any easy solution here (other than the FSF blinking).
but there is an exception Posted Aug 1, 2009 23:14 UTC (Sat) by cas (subscriber, #52554) [Link]
> "... unless that component itself accompanies the executable."
> [...] > RMS wasn't thinking of entirely-free OSes when he wrote that;
easily fixed in a hypothetical GPL v2.1, or in an addition to the git license:
"... unless that component itself accompanies the executable AND is not licensed with a Copyleft-style license such as the GPL v3 or any compatible Free Software license"
or making it a new sentence might make it clearer/less clumsy:
"... unless that component itself accompanies the executable. This exception does not apply if the component is licensed with a Copyleft-style license such as the GPL v3 or any compatible Free Software license".
> Say that the license is GPLv2, except that the phrase "unless that
there's a reason for that exception. it's to prevent people from subverting the intent of the GPL and merging it with proprietary code by claiming that they are merely aggregating the work.
Explained in other words Posted Jul 29, 2009 10:29 UTC (Wed) by michaeljt (subscriber, #39183) [Link]
>The problem is section 2b:
> >b) You must cause any work that you distribute or publish, that in whole or in part contains or is derived from the Program or any part thereof, to be licensed as a whole at no charge to all third parties under the terms of this License.
I am assuming that the distributions have local changes to the code, otherwise they can distribute under the terms of section 1, which are more liberal than 2b. This seems to come down to the question of whether the runtime library counts as part of the derived work. Section 3 seems to require the source to the runtime to be included (mandated by both sections 1 and 2). However, if the runtime is not part of the derived work, then the terms of section 1 seem to be sufficient.
IANAL should be implicit in licence discussions unless stated otherwise :)
Explained in other words Posted Jul 28, 2009 7:20 UTC (Tue) by elama (subscriber, #262) [Link]
So, question is the meaning of 'accompanies the executable'.
libgcc and git won't share the same deb file. Is that enough?
Explained in other words Posted Jul 28, 2009 10:45 UTC (Tue) by cortana (subscriber, #24596) [Link]
What is the difference between a Debian package, a ZIP file and an ISO9660 filesystem anyway?
Explained in other words Posted Jul 28, 2009 12:10 UTC (Tue) by MathFox (guest, #6104) [Link]
The problem is that there are several reasonable ways to interpret 'accompanies the executable' and Debian-legal is not entirely sure on what it means. I am sure that it was not the intention of the FSF to create a problem here, but it has happened in the license drafting process.
Reasonable interpretations of "accompanying" would be "on the same CD or in the same CD set" and "side by side on the same server". So, if you follow a strict license interpretation, Debian has to choose between GPLv2-git and a new GPLv3-gcc and can not carry both. (Well, as a stopgap they could compile GPLv2 only programs with a GPLv2+ version of gcc...)
The problem exists because version 2 and 3 of the GPL are incompatible and the authors of the GPLv2 only programs can not relicense libgcc.
Explained in other words Posted Jul 29, 2009 1:41 UTC (Wed) by Baylink (guest, #755) [Link]
Isn't there "mere aggregation" language in there somewhere specifically to protect distributors?
Yes and no Posted Jul 30, 2009 5:28 UTC (Thu) by khim (guest, #9252) [Link] Isn't there "mere aggregation" language in there somewhere specifically to protect distributors? Yes, but that sentence covers totally different case. It gives you right to ship GPLed git and proprietary adobe flash player on the same CD: as long as program are totally unrelated their license don't clash. Unfortunatelly git and libgcc are intimately intervined, so "mere aggregation" defense does not fly...
Explained in other words Posted Jul 29, 2009 11:14 UTC (Wed) by garloff (subscriber, #319) [Link]
MathFox wrote:
> (Well, as a stopgap they could compile GPLv2 only programs with a > GPLv2+ version of gcc...)
It would be enough if Debian compiled a GPLv2+ version of libgcc and made
Explained in other words Posted Jul 29, 2009 20:03 UTC (Wed) by vonbrand (subscriber, #4458) [Link] "Side by side on the same server"... this would mean that if I have e.g. OpenSolaris and BSD and some Linux distributions on a mirror somwehwere, the license terms kick in? Sounds horrible.
human judges Posted Jul 29, 2009 20:12 UTC (Wed) by coriordan (guest, #7544) [Link]
They'll look at whether things are intended to be together, or intended to be combined after download, etc. They won't view Debian+OpenSolaris in the same way as they'd view git+gcc packages for Debian.
When learning to be a computer admin or programmer, we're taught how to see *past* the differences between a lump of bits that forms an operating system ISO and a lump of bits that forms a picture. To think about legal issues, we have to remember to look *at* those differences.
|
|
||||||||||||