Licensing Problems with Debian Packages (Was Re: Copyright lawyers analysis of Andreas Pour's Interpretation)
Raul Miller wrote: > On Tue, Feb 15, 2000 at 03:46:48AM -0500, Andreas Pour wrote: > > > [ Raul Miller wrote: ] > > > > No clauses from the BSD license were presented which conflicted with > > > any of the clauses from the GPL. > > [ Andreas Pour wrote: ] > > The advertising clause is a "further restrictions on the recipients' > > exercise > > of the rights granted herein" (Section 6 of the GPL). [ Raul Miller responded: ] > That clause was discarded years ago. The BSD license no longer contains it. > > As I understand it, that clause was discarded because: > > (1) it was unenforcable, and > (2) it conflicted with the GPL. OK, so you admit that the advertising clause conflicts with the GPL. Well, that's very interesting, b/c the Apache license (see http://www.apache.org/LICENSE.txt, clause 3) includes this provision, as well as several others (clauses 4 and 5) that are inconsistent with the GPL. Now, Apache links with libc, and under your reading of the GPL, Debian must distribute libc under the GPL rather than the LGPL (as (1) you read Sections 3(a) and 2(b) of the GPL to require the "entire Program" to be licensed under the GPL, (2) you link libc with actually GPL'd programs, such as 'grep', and (3) you provide only one copy of libc which can be either LGPL or GPL, but not both). Hence Apache links to a GPL'd work. Nevertheless, Debian distributes Apache (see http://www.debian.org/Packages/stable/web/). Incidentally, Perl (http://www.debian.org/Packages/stable/interpreters/) has the same problem as Apache. Have a look at clause 9 of the Artistic License (http://www.perl.com/language/misc/Artistic.html). What's even more interesting is that FSF distributes BSD-licensed code as part of libc. See http://www.gnu.org/manual/glibc-2.0.6/html_node/libc_524.html. The notable part about that is, this code retains the advertising clause. It also contains DEC-licensed code, which not only includes an advertising clause, but, also specifies that its license applies to all redistributions (and hence the code cannot be distributed under GPL or LGPL). Moreover, having looked at your libc license (http://cgi.debian.org/cgi-bin/get-copyright?package=libc6), Debian has not in fact converted libc to GPL, and Debian appears to distribute only one copy of libc, so I guess all Debian's GPL programs that link to it are in violation of the GPL (under your reading of Sections 3(a) and 2(b)). When will I see Debian start distributing a separate libc/libgdbm that is in fact licensed under the LGPL and to which only non-GPL programs link, since under Debian's reading GPL works cannot link to LGPL libraries? Ohhh, but darn it, even that won't work. Debian's libc includes libio, and libio is licensed under the GPL (see http://cgi.debian.org/cgi-bin/get-copyright?package=libc6) (I note that the exception in the libio license, which says the executable is not governed by the GPL, does not apply to the source code, and your reading of Sections 3(a) and 2(b) apply to the source code). Oh well, I guess Debian can't distribute Apache or Perl unless you remove libio from your libc :-(. Interestingly enough, it looks like Debian somehow thinks it can distribute libc linked to libio, even though one is (apparently) under the LGPL, and libio is licensed under the GPL, and they are a single work (no dynamic linking issues come up). I found all these problems just looking at your packages for a few minutes. How many could I find if I looked at all your packages? If you promise to make changes to comply with your own reading of the GPL, I will be happy to perform this service for you (of course, there will not be a working Debian distribution left afterwards . . . .). The more you look at reality, the more absurd your interpretation that Section 2(b) requires licensing all source code under the GPL. Nobody, not even the FSF or Debian, does this. Ciao, Andreas
Re: Licensing Problems with Debian Packages (Was Re: Copyright lawyers analysis of Andreas Pour's Interpretation)
On Wed, Feb 16, 2000 at 11:53:06AM -0500, Andreas Pour wrote: > OK, so you admit that the advertising clause conflicts with the > GPL. Well, that's very interesting, b/c the Apache license (see > http://www.apache.org/LICENSE.txt, clause 3) includes this provision, > as well as several others (clauses 4 and 5) that are inconsistent with > the GPL. Now, Apache links with libc, and under your reading of the > GPL, Debian must distribute libc under the GPL rather than the LGPL > (as (1) you read Sections 3(a) and 2(b) of the GPL to require the > "entire Program" to be licensed under the GPL, (2) you link libc with > actually GPL'd programs, such s 'grep', and (3) you provide only one > acopy of libc which can be either LGPL or GPL, but not both). Hence > Apache links to a GPL'd work. Nevertheless, Debian distributes Apache > (see http://www.debian.org/Packages/stable/web/). Since the associateion between apache and grep is mere aggregation, I don't see how this is relevant. > Incidentally, Perl > (http://www.debian.org/Packages/stable/interpreters/) has the same > problem as Apache. Have a look at clause 9 of the Artistic License > (http://www.perl.com/language/misc/Artistic.html). Perl can already be distributed under the GPL. > What's even more interesting is that FSF > distributes BSD-licensed code as part of libc. See > http://www.gnu.org/manual/glibc-2.0.6/html_node/libc_524.html. The > notable part about that is, this code retains the advertising clause. > It also contains DEC-licensed code, which not only includes an > advertising clause, but, also specifies that its license applies to > all redistributions (and hence the code cannot be distributed under > GPL or LGPL). Well, I've filed a bug report against Debian's libc6 on this issue. I suspect that the issue has been ignored because the advertising clause is considered unenforceable. > Moreover, having looked at your libc license > (http://cgi.debian.org/cgi-bin/get-copyright?package=libc6), Debian > has not in fact converted libc to GPL, and Debian appears to > distribute only one copy of libc, so I guess all Debian's GPL programs > that link to it are in violation of the GPL (under your reading of > Sections 3(a) and 2(b)). If the advertising clause is legally relevant, yes. > When will I see Debian start distributing a separate libc/libgdbm > that is in fact licensed under the LGPL and to which only non-GPL > programs link, since under Debian's reading GPL works cannot link to > LGPL libraries? I'll see what the response is to my bug report before tackling this issue. > Ohhh, but darn it, even that won't work. Debian's libc > includes libio, and libio is licensed under the GPL (see > http://cgi.debian.org/cgi-bin/get-copyright?package=libc6) (I note > that the exception in the libio license, which says the executable is > not governed by the GPL, does not apply to the source code, and your > reading of Sections 3(a) and 2(b) apply to the source code). I think that exception is clear enough about what it means. > Oh well, I guess Debian can't distribute Apache or Perl unless you > remove libio from your libc :-(. Again, this isn't even an issue if the advertising clause is not legally relevant. > Interestingly enough, it looks like Debian somehow thinks it can > distribute libc linked to libio, even though one is (apparently) under > the LGPL, and libio is licensed under the GPL, and they are a single > work (no dynamic linking issues come up). libio is GPL + an exception, not just plain GPL. > I found all these problems just looking at your packages for a few > minutes. How many could I find if I looked at all your packages? If > you promise to make changes to comply with your own reading of the > GPL, I will be happy to perform this service for you (of course, there > will not be a working Debian distribution left afterwards . . . .). If you find copyright bugs, I'll be happy to file bug reports. I've already filed one on the advertising clause issue -- and I'm not completely confident that that bug report isn't bogus. So I'll not be filing any more on that issue until I find out more. But if you find any other sorts of copyright bugs I'll be grateful. > The more you look at reality, the more absurd your interpretation that > Section 2(b) requires licensing all source code under the GPL. Nobody, > not even the FSF or Debian, does this. Like I said: if you find any problems, I'll file bug reports. -- Raul
Re: Licensing Problems with Debian Packages (Was Re: Copyright lawyers analysis of Andreas Pour's Interpretation)
Raul Miller wrote: > On Wed, Feb 16, 2000 at 11:53:06AM -0500, Andreas Pour wrote: > > OK, so you admit that the advertising clause conflicts with the > > GPL. Well, that's very interesting, b/c the Apache license (see > > http://www.apache.org/LICENSE.txt, clause 3) includes this provision, > > as well as several others (clauses 4 and 5) that are inconsistent with > > the GPL. Now, Apache links with libc, and under your reading of the > > GPL, Debian must distribute libc under the GPL rather than the LGPL > > (as (1) you read Sections 3(a) and 2(b) of the GPL to require the > > "entire Program" to be licensed under the GPL, (2) you link libc with > > actually GPL'd programs, such s 'grep', and (3) you provide only one > > acopy of libc which can be either LGPL or GPL, but not both). Hence > > Apache links to a GPL'd work. Nevertheless, Debian distributes Apache > > (see http://www.debian.org/Packages/stable/web/). > > Since the associateion between apache and grep is mere aggregation, > I don't see how this is relevant. It is relevant b/c, under your reading, to link libc with 'grep', you have to license libc under the GPL. So that means the libc distributed with Debian is a GPL libc, not an LGPL libc (ignoring for the moment that Debian does not in fact do the conversion). Since libc is under the GPL, you cannot link it to something like Apache, which is not licensed under the GPL and imposed additional requirements which the GPL does not impose. > > Incidentally, Perl > > (http://www.debian.org/Packages/stable/interpreters/) has the same > > problem as Apache. Have a look at clause 9 of the Artistic License > > (http://www.perl.com/language/misc/Artistic.html). > > Perl can already be distributed under the GPL. Where do you get this information from? Looking at http://www.perl.com/pub/language/info/software.html#srclic, I see it only being licensed as Artistic. > > What's even more interesting is that FSF > > distributes BSD-licensed code as part of libc. See > > http://www.gnu.org/manual/glibc-2.0.6/html_node/libc_524.html. The > > notable part about that is, this code retains the advertising clause. > > It also contains DEC-licensed code, which not only includes an > > advertising clause, but, also specifies that its license applies to > > all redistributions (and hence the code cannot be distributed under > > GPL or LGPL). > > Well, I've filed a bug report against Debian's libc6 on this issue. > > I suspect that the issue has been ignored because the advertising clause > is considered unenforceable. So you know that to be true in each jurisdiction where Debian is distributed? and under what theory is it considered unenforceable? And, incidentally, there are *two* advertising clauses. One says you have to acknowledge the copyright holder; I suppose this is the one you think "unenforceable". But there is also the other one which says you cannot use the copyright holder's name to promote the software. In any event, it may be that the licensor cannot get damages if you breach the no-advertisement clause, but does that necessarily mean that the person who breached that clause is entitled to distribute the software? It is quite likely that if a court finds the no-advertisement clause invalid it will find the entire License invalid, in which case there is no permission to redistribute the software at all. So the person doing the advertising might win the battle but lose the war. What I'm essentially saying is that, if you want to take the position that the advertising clause is unenforceable, you should as a consequence take the position that you have no right to redistribute the software. Besides, the GPL does not say in Section 6 that "You may not impose any further restrictions on the recipients' exercise of the rights granted herein." It says nothing about those restrictions having to be "legally enforceable". Enforceable or not, it's a restriction that's imposed; there is at a minimum a moral imperative not to violate that condition, and hence if you have any morals it's a restriction. If now you consider enforceability relevant to the interpretation of the GPL, I suggest you revisit your claim that you can license X code under the GPL, b/c that is less likely to be enforceable than is the advertising clause. Anyway, it goes beyond the advertising clause. Certain parts of FSF's libc specify that they must be licensed under terms other than the GPL, hence they cannot be licensed under the GPL (just like X can't); and certain parts (like libio) are licensed under the GPL and hence cannot be combined with LGPL works like libc. However, unlike X, these portions are not dynamically linked to libc; they are definitely part of the entire work. > > Moreover, having looked at your libc license > > (http://cgi.debian.org/cgi-bin/get-copyright?package=libc6), Debian > > has not in fact converted libc to GPL, and Debian appears to > > distribute only one copy of libc, so I guess all Debian
Re: Licensing Problems with Debian Packages (Was Re: Copyright lawyers analysis of Andreas Pour's Interpretation)
On Feb 16, Andreas Pour wrote: > It is relevant b/c, under your reading, to link libc with 'grep', you have > to license libc under the GPL. So that means the libc distributed with > Debian is a GPL libc, not an LGPL libc (ignoring for the moment that Debian > does not in fact do the conversion). Since libc is under the GPL, you > cannot link it to something like Apache, which is not licensed under the > GPL and imposed additional requirements which the GPL does not impose. GNU libc is licensed under the LGPL, not the GPL. Bzzt. You lose. (To link GNU grep against GNU libc, the only requirement that applies is that the sum "grep+libc" must be provided under terms no more restrictive than the GPL. Incidentally, you can also link GNU libc against the libc used by *BSD. Neither of these acts "relicenses" libc; the linking and distributing only places the combined work (grep+libc) under the GPL, not its constituent parts for ever and in eternity). I think you're trolling now... Chris -- = |Chris Lawrence | You have a computer. Do you have Linux? | | <[EMAIL PROTECTED]> |http://www.linux-m68k.org/index.html | | | | | Grad Student, Pol. Sci. | This address has been spam-proofed. | | University of Mississippi | All spam goes to your postmaster. | =
Re: Licensing Problems with Debian Packages (Was Re: Copyright lawyers analysis of Andreas Pour's Interpretation)
On Wed, Feb 16, 2000 at 10:42:51PM -0500, Andreas Pour wrote: > It is relevant b/c, under your reading, to link libc with 'grep', you > have to license libc under the GPL. So that means the libc distributed > with Debian is a GPL libc, not an LGPL libc (ignoring for the moment > that Debian does not in fact do the conversion). Since libc is under > the GPL, you cannot link it to something like Apache, which is not > licensed under the GPL and imposed additional requirements which the > GPL does not impose. You can distribute a work under more than one license, so I still don't see why this is an issue. Perhaps your claim is that when libc is distributed under the GPL we can no longer distribute it under the LGPL? > > > Incidentally, Perl > > > (http://www.debian.org/Packages/stable/interpreters/) has the same > > > problem as Apache. Have a look at clause 9 of the Artistic License > > > (http://www.perl.com/language/misc/Artistic.html). > > > > Perl can already be distributed under the GPL. > > Where do you get this information from? Looking at > http://www.perl.com/pub/language/info/software.html#srclic, I see it only > being licensed as Artistic. Quoting from /usr/doc/perl-5.005/copyright on my debian system: This program is free software; you can redistribute it and/or modify it under the terms of either: a) the GNU General Public License as published by the Free Software Foundation; either version 1, or (at your option) any later version, or b) the "Artistic License" which comes with Debian. If I pull down a copy of the perl sources, I see that this is an exact quote from perl5.005_03/README, and that there's a "Copying" file there which contains the text of the GPL. Or, if I look at a random source file, I see comments such as: /*perl.c * *Copyright (c) 1987-1999 Larry Wall * *You may distribute under the terms of either the GNU General Public *License or the Artistic License, as specified in the README file. * */ /* * "A ship then new they built for him/of mithril and of elven glass" --Bilbo */ By the way, I recall the same licensing conditions existed back when I was building perl in 1989. > > > What's even more interesting is that FSF > > > distributes BSD-licensed code as part of libc. See > > > http://www.gnu.org/manual/glibc-2.0.6/html_node/libc_524.html. The > > > notable part about that is, this code retains the advertising clause. > > > It also contains DEC-licensed code, which not only includes an > > > advertising clause, but, also specifies that its license applies to > > > all redistributions (and hence the code cannot be distributed under > > > GPL or LGPL). > > > > Well, I've filed a bug report against Debian's libc6 on this issue. > > I suspect that the issue has been ignored because the advertising clause > > is considered unenforceable. > > So you know that to be true in each jurisdiction where Debian is > distributed? and under what theory is it considered unenforceable? Do you think "I suspect" equates to any kind of guarantee of in depth knowledge of this particular issue? I can tell you what I remember from the discussions where I've been told that it was unenforceable, but I have not studied this issue personally. > And, incidentally, there are *two* advertising clauses. One says you have > to acknowledge the copyright holder; I suppose this is the one you think > "unenforceable". But there is also the other one which says you cannot use > the copyright holder's name to promote the software. The reason that this is considered unenforcable is that advertising is not related to copying. If the advertisements themselves included BSD copyrighted material, that would be a different story. And, that reminds me, the GPL doesn't concern itself with advertising or promotions -- those activities are outside the scope of the license. The BSD advertising clauses do not restrict the distribution or modification of BSD code, it's pretty obvious that the major problem with the clauses is that they confuse people, such as yourself, who are trying to understand the licensing issues. I'm going to clip some material from your post which appears to me to reiterate your position that the advertising clause is relevant. If you think I've missed some important point, please mention it, and I'll post a response which addresses this point. > If now you consider enforceability relevant to the interpretation of the > GPL, I suggest you revisit your claim that you can license X code under the > GPL, b/c that is less likely to be enforceable than is the advertising > clause. Which claim? > Anyway, it goes beyond the advertising clause. Certain parts of FSF's > libc specify that they must be licensed under terms other than the > GPL, hence they cannot be licensed under the GPL (just like X can't); > and certain parts (like libio) are licensed under the GPL and hence > cannot be combined with LGPL works like li
Re: Licensing Problems with Debian Packages (Was Re: Copyright lawyers analysis of Andreas Pour's Interpretation)
Raul Miller wrote: > On Wed, Feb 16, 2000 at 10:42:51PM -0500, Andreas Pour wrote: > > It is relevant b/c, under your reading, to link libc with 'grep', you > > have to license libc under the GPL. So that means the libc distributed > > with Debian is a GPL libc, not an LGPL libc (ignoring for the moment > > that Debian does not in fact do the conversion). Since libc is under > > the GPL, you cannot link it to something like Apache, which is not > > licensed under the GPL and imposed additional requirements which the > > GPL does not impose. > > You can distribute a work under more than one license, so I still don't > see why this is an issue. May be true in general, but not w/ the LGPL. Look at Section 3 of the LGPL: You may opt to apply the terms of the ordinary GNU General Public License instead of this License to a given copy of the Library. To do this, you must alter all the notices that refer to this License, so that they refer to the ordinary GNU General Public License, version 2 instead of to this License. . . . Do not make any other change in these notices. Once this change is made in a given copy, it is irreversible for that copy, so the ordinary GNU General Public License applies to all subsequent copies and derivative works made from that copy. So, you see, you have to change the notices so they refer to the GPL and not to the LGPL, and the change is irreversible. So the copy cannot at the same time be licensed under both licenses. If you want both a GPL libc and a LGPL libc, you need to distribute two copies -- one which has had its headers changed, and another which has not. > Perhaps your claim is that when libc is distributed under the GPL we > can no longer distribute it under the LGPL? Exactly. That is extremely clear from the language, why would you dispute it? > > > > Incidentally, Perl > > > > (http://www.debian.org/Packages/stable/interpreters/) has the same > > > > problem as Apache. Have a look at clause 9 of the Artistic License > > > > (http://www.perl.com/language/misc/Artistic.html). > > > > > > Perl can already be distributed under the GPL. > > > > Where do you get this information from? Looking at > > http://www.perl.com/pub/language/info/software.html#srclic, I see it only > > being licensed as Artistic. [ ... ] You are correct about the Perl license; I apologize, it seems their web site is out of date when it comes to the license. However, I looked at the mod_perl license, which Debian also distributes (see http://www.debian.org/Packages/stable/web/libapache-mod-perl.html), and it does not have the GPL option (see the source code or http://cgi.debian.org/cgi-bin/get-copyright?package=libapache-mod-perl). In fact many of the Perl add-ons are solely under the Artistic license. [ ... ] > > And, incidentally, there are *two* advertising clauses. One says you have > > to acknowledge the copyright holder; I suppose this is the one you think > > "unenforceable". But there is also the other one which says you cannot use > > the copyright holder's name to promote the software. > > The reason that this is considered unenforcable is that advertising is not > related to copying. If the advertisements themselves included BSD copyrighted > material, that would be a different story. There are lots of licensing conditions that do not relate to copying. E.g., Section 6 of the GPL has the "no additional restrictions" provision, which does not relate to copying or distribution, but relates to the rights of the person who receives a copy. Moreover, the GPL imposes restrictions/conditions on code that is written by third parties, which is also not related to copying or distributing the GPL code. Finally, there are obligations in the GPL (such as Section 2(c)) which relate to a user executing a work. Also, I do not see any reason why all requirements of a license need to deal with copying and distributing. The only problem I can see off-hand with the advertising clauses is that they may interfere with "fair use". But then a court would have to decide that "fair use" outweighs the license. You may note, too, that advertising is *very much* related to distribution. You are advertising it to distribute it. Finally, you have not addressed my two points that (a) even if the advertising clause is not legally enforceable, it is a *moral* requirement, and hence would conflict with Section 6's prohibitions anyway; and (b) if the advertising clause is unenforceable, a court would invalidate the entire license, leaving you with no right to redistribute the software at all (this is often held up as an example of why the GPL will not be challenged, since if it is held to be invalid, there is no right to distribute at all). > And, that reminds me, the GPL doesn't concern itself with advertising or > promotions -- those activities are outside the scope of the license. Right, but Section 6 does not limit itself to addition
Re: Licensing Problems with Debian Packages (Was Re: Copyright lawyers analysis of Andreas Pour's Interpretation)
Raul Miller wrote: > > You can distribute a work under more than one license, so I still don't > > see why this is an issue. On Thu, Feb 17, 2000 at 10:24:17AM -0500, Andreas Pour wrote: > May be true in general, but not w/ the LGPL. Look at Section 3 of the LGPL: > > You may opt to apply the terms of the ordinary GNU General Public > License instead of this License to a given copy of the Library. To > do this, you must alter all the notices that refer to this License, so > that they refer to the ordinary GNU General Public License, version > 2 instead of to this License. . . . Do not make any other change in > these notices. > > Once this change is made in a given copy, it is irreversible for that > copy, so the ordinary GNU General Public License applies to all > subsequent copies and derivative works made from that copy. > > So, you see, you have to change the notices so they refer to the GPL > and not to the LGPL, and the change is irreversible. So the copy > cannot at the same time be licensed under both licenses. If you want > both a GPL libc and a LGPL libc, you need to distribute two copies -- > one which has had its headers changed, and another which has not. You're claiming that since it's possible to replace the copyright on the library that it's necessary? > > Perhaps your claim is that when libc is distributed under the GPL we > > can no longer distribute it under the LGPL? > > Exactly. That is extremely clear from the language, why would you > dispute it? I don't see why, after you've gone to such pains to establish that the on a module license doesn't change when a module is linked with a GPLed program. Why have you decided that this is a necessary step for this case? Once again: you can have multiple licenses on a collective work. > However, I looked at the mod_perl license, > which Debian also distributes (see > http://www.debian.org/Packages/stable/web/libapache-mod-perl.html), > and it does not have the GPL option (see the source code or > http://cgi.debian.org/cgi-bin/get-copyright?package=libapache-mod-perl > ). In fact many of the Perl add-ons are solely under the Artistic > license. Ok. You might have something here. However, before I file a bug report: what conflict do you see with the Artistic license? Is there anything other than that you can't claim to have written the package? > > The reason that this is considered unenforcable is that advertising > > is not related to copying. If the advertisements themselves included > > BSD copyrighted material, that would be a different story. > > There are lots of licensing conditions that do not relate to copying. > E.g., Section 6 of the GPL has the "no additional restrictions" > provision, which does not relate to copying or distribution, but > relates to the rights of the person who receives a copy. Moreover, the > GPL imposes restrictions/conditions on code that is written by third > parties, which is also not related to copying or distributing the GPL > code. Finally, there are obligations in the GPL (such as Section 2(c)) > which relate to a user executing a work. My point about the advertising clause -- especially the one where possessing a BSD license doesn't represent an endorsement by the BSD Regents, is that it doesn't have anything to do with modification or redistribution. You already aren't endorsed by the BSD Regents before you get a copy of some BSD software, why should it make a difference that you're not endorsed afterwards? What's the restriction? For the explicit advertising clause: if there's no BSD copyrighted material being distributed in "advertising materials", then it's not a BSD copyright issue. So, this only makes sense in contexts where BSD copyrighted materials are being distributed. In this case, the GPL already requires that: "you conspicuously and appropriately publish on each copy an appropriate copyright notice ...". Since this advertising clause is a part of the BSD copyright notice, it's not clear that there is any restriction here that's not already in the GPL. That is, unless, you can come up with some kind of legal basis where copyright can restrict the distribution of non-copyrighted materials. [It probably is possible, but not without spelling out exactly what is meant in a lot of detail.] This is very different from the QPL issue -- there's no doubt that modifications to QPL licensed code must be relicenseable such that Troll owns them. Or is there? Are you claiming that there's no legal merit to Troll's clause? > Also, I do not see any reason why all requirements of a license need > to deal with copying and distributing. If the BSD copyright defined what it meant by advertising materials and restricted the distribution of BSD copyrighted material under conditions where its advertising materials requirements weren't explicitly meant then I think you would have a point. As it is, all I can say is that I don't think that this is an i
Re: Licensing Problems with Debian Packages (Was Re: Copyright lawyers analysis of Andreas Pour's Interpretation)
Raul Miller wrote: > Raul Miller wrote: > > > You can distribute a work under more than one license, so I still don't > > > see why this is an issue. > > On Thu, Feb 17, 2000 at 10:24:17AM -0500, Andreas Pour wrote: > > May be true in general, but not w/ the LGPL. Look at Section 3 of the LGPL: > > > > You may opt to apply the terms of the ordinary GNU General Public > > License instead of this License to a given copy of the Library. To > > do this, you must alter all the notices that refer to this License, so > > that they refer to the ordinary GNU General Public License, version > > 2 instead of to this License. . . . Do not make any other change in > > these notices. > > > > Once this change is made in a given copy, it is irreversible for that > > copy, so the ordinary GNU General Public License applies to all > > subsequent copies and derivative works made from that copy. > > > > So, you see, you have to change the notices so they refer to the GPL > > and not to the LGPL, and the change is irreversible. So the copy > > cannot at the same time be licensed under both licenses. If you want > > both a GPL libc and a LGPL libc, you need to distribute two copies -- > > one which has had its headers changed, and another which has not. > > You're claiming that since it's possible to replace the copyright on > the library that it's necessary? You mean change the license? I'm just quoting from the LGPL, don't blame me. > > > Perhaps your claim is that when libc is distributed under the GPL we > > > can no longer distribute it under the LGPL? > > > > Exactly. That is extremely clear from the language, why would you > > dispute it? > > I don't see why, after you've gone to such pains to establish that the > on a module license doesn't change when a module is linked with a GPLed > program. Why have you decided that this is a necessary step for this > case? B/c the LGPL says so. It says you can change the license to GPL, but then it is no longer under the LGPL. Now you want to have it both ways. However, the LGPL prohibits it. > Once again: you can have multiple licenses on a collective work. Not if one of the licenses prohibits it. And this has nothing to do with a collective work -- libc is *one* work for purposes of this issue. This one work is licensed under the LGPL. That license says you can convert to GPL, but then it is no longer under the LGPL. Are you being intentionally obtuse? > > However, I looked at the mod_perl license, > > which Debian also distributes (see > > http://www.debian.org/Packages/stable/web/libapache-mod-perl.html), > > and it does not have the GPL option (see the source code or > > http://cgi.debian.org/cgi-bin/get-copyright?package=libapache-mod-perl > > ). In fact many of the Perl add-ons are solely under the Artistic > > license. > > Ok. You might have something here. > > However, before I file a bug report: what conflict do you see with the > Artistic license? Is there anything other than that you can't claim to > have written the package? Well, I don't see any conflict, but under your reading each of the following (quoted from the Apache license at http://www.apache.org/LICENSE.txt) provisions is an "additional requirement": * 3. All advertising materials mentioning features or use of this *software must display the following acknowledgment: *"This product includes software developed by the Apache Group *for use in the Apache HTTP server project (http://www.apache.org/)." * * 4. The names "Apache Server" and "Apache Group" must not be used to *endorse or promote products derived from this software without *prior written permission. For written permission, please contact *[EMAIL PROTECTED] * * 5. Products derived from this software may not be called "Apache" *nor may "Apache" appear in their names without prior written *permission of the Apache Group. * * 6. Redistributions of any form whatsoever must retain the following *acknowledgment: *"This product includes software developed by the Apache Group *for use in the Apache HTTP server project (http://www.apache.org/).": > > > The reason that this is considered unenforcable is that advertising > > > is not related to copying. If the advertisements themselves included > > > BSD copyrighted material, that would be a different story. > > > > There are lots of licensing conditions that do not relate to copying. > > E.g., Section 6 of the GPL has the "no additional restrictions" > > provision, which does not relate to copying or distribution, but > > relates to the rights of the person who receives a copy. Moreover, the > > GPL imposes restrictions/conditions on code that is written by third > > parties, which is also not related to copying or distributing the GPL > > code. Finally, there are obligations in the GPL (such as Section 2(c)) > > which relate to a user executing a work. > > My point about the advertising cla
Re: Licensing Problems with Debian Packages (Was Re: Copyright lawyers analysis of Andreas Pour's Interpretation)
On Feb 17, Andreas Pour wrote: [...] > > I don't see why, after you've gone to such pains to establish that the > > on a module license doesn't change when a module is linked with a GPLed > > program. Why have you decided that this is a necessary step for this > > case? > > B/c the LGPL says so. It says you can change the license to GPL, > but then it is no longer under the LGPL. Now you want to have it > both ways. However, the LGPL prohibits it. Apparently you can't read and/or comprehend English. I mailed this morning that just because something is put under the GPL once, that does not necessarily mean that everyone else has to use it under the GPL too. Your ignorance of this fact (and your not challenging it) imply that all you're doing is trolling. Besides which, this is irrelevant to your example of grep+libc, since in linking grep with libc you don't modify any of libc's code, nor do you patch libc with code that would make it come under the GPL. The LGPL permits you to make derivative works of the library under either the GPL or the LGPL. That does not mean that once you do this (which we haven't anyway), you can never make another derivative work under the LGPL, or even that you have to treat the original under the GPL for ever and in eternity (which is what you seem to imply in this paragraph). Go away. Find something else to do. Build your own damn distribution if you can't find something more constructive. We're tired of your bullshit and your inability to assimilate new ideas (for example, that you're wrong). Chris -- Chris Lawrence <[EMAIL PROTECTED]> Senior Research Assistant, SSRL Opinions and attitudes expressed herein are rarely shared by my employer.
Re: Licensing Problems with Debian Packages (Was Re: Copyright lawyers analysis of Andreas Pour's Interpretation)
> > You're claiming that since it's possible to replace the copyright on > > the library that it's necessary? On Thu, Feb 17, 2000 at 03:26:06PM -0500, Andreas Pour wrote: > You mean change the license? I'm just quoting from the LGPL, don't blame me. I blame you for failing to distinguish between a requirement and an option. The LGPL gives you the option of distributing libc as an independent work under the GPL. In this case you must change the copyright statements on libc. The GPL, in the context of grep (for instance) requires that you distribute the collective work represented by libc and grep under the GPL. In this case there's no requirement to change the copyright statements on libc -- the terms of the LGPL are fine, as is. You seem to consistently fail to understand that a copyright license grants you some rights. You don't have to exercise those rights. You can't exercise rights which have not been granted to you. In the case of the LGPL you have the right to relicense libc under the GPL, but we've already established that that's not a requirement for the case of distributing code under the GPL. Even if it was, the work grep+libc is a different work from apache+libc. If you don't understand this concept, I suggest you hire a copyright lawyer to have him explain it to you. [I'm going to delete a lot of quoted material from this letter which just rehashes this issue.] [Skipping down to mod-perl]: > > However, before I file a bug report: what conflict do you see with the > > Artistic license? Is there anything other than that you can't claim to > > have written the package? > > Well, I don't see any conflict, but under your reading each of the following > (quoted from the Apache license at http://www.apache.org/LICENSE.txt) > provisions > is an "additional requirement": > > * 3. All advertising materials mentioning features or use of this > *software must display the following acknowledgment: > *"This product includes software developed by the Apache Group > *for use in the Apache HTTP server project (http://www.apache.org/)." > * > * 4. The names "Apache Server" and "Apache Group" must not be used to > *endorse or promote products derived from this software without > *prior written permission. For written permission, please contact > *[EMAIL PROTECTED] > * > * 5. Products derived from this software may not be called "Apache" > *nor may "Apache" appear in their names without prior written > *permission of the Apache Group. > * > * 6. Redistributions of any form whatsoever must retain the following > *acknowledgment: > *"This product includes software developed by the Apache Group > *for use in the Apache HTTP server project (http://www.apache.org/).": You've not yet established that the GPL is relevant in this context. > > My point about the advertising clause -- especially the one where > > possessing a BSD license doesn't represent an endorsement by the BSD > > Regents, is that it doesn't have anything to do with modification or > > redistribution. > > Just to be clear, there are two advertisement-related provisions in the BSD > license: > > (1) All advertising materials mentioning features or use of this > software must display the following acknowledgement: > > This product includes software developed by the University > of California, Berkeley and its contributors. > > (2) Neither the name of the University nor the names of its > contributors may be used to endorse or promote products derived > from this software without specific prior written permission. > > If you are referring to the second one, it is a bit different than what you > imply > above. It looks to me like what you label (2) is a clarification that what you label (1) does not represent an endorsement. Which merely means that this copyright doesn't grant the right to claim an endorsement. Certainly it doesn't say that if you commit fraud and claim to be endorsed when you haven't been that you lose the right do distribute BSD licensed code. And it shouldn't have to -- there is already adequate legal coverage of that issue outside of copyright law. > > You already aren't endorsed by the BSD Regents before you get a copy > > of some BSD software, why should it make a difference that you're not > > endorsed afterwards? What's the restriction? > > The restriction is in clauses (1) and (2) above. I don't see analogous > ones in the GPL. What you label (1) is analogous to the requirement in Section (1) of the GPL that an appropriate copyright notice be conspicuously and appropriately published. After all, the notice is a part of that BSD copyright statement. Anyways, the Regents of UC Berkeley have withdrawn that clause from the license and material which has been issued since then do not have that clause. And, since they're the copyright holders, they're entitled to do that. Perhaps you're sugge
Re: Licensing Problems with Debian Packages (Was Re: Copyright lawyers analysis of Andreas Pour's Interpretation)
Raul Miller wrote: > > > You're claiming that since it's possible to replace the copyright on > > > the library that it's necessary? > > On Thu, Feb 17, 2000 at 03:26:06PM -0500, Andreas Pour wrote: > > You mean change the license? I'm just quoting from the LGPL, don't blame > > me. [ double-think, confusion and inconsistencies snipped ] I think all the issues have been adequately aired. I will turn to other things. Ciao, Andeas
Re: Licensing Problems with Debian Packages (Was Re: Copyright lawyers analysis of Andreas Pour's Interpretation)
On Thu, Feb 17, 2000 at 10:32:26PM -0500, Andreas Pour wrote: > [ double-think, confusion and inconsistencies snipped ] > > I think all the issues have been adequately aired. I will turn to > other things. I agree that the issues have been adequately aired, but that's no call for flamage. -- Raul
Re: Licensing Problems with Debian Packages (Was Re: Copyright lawyers analysis of Andreas Pour's Interpretation)
Raul Miller wrote: > On Thu, Feb 17, 2000 at 10:32:26PM -0500, Andreas Pour wrote: > > [ double-think, confusion and inconsistencies snipped ] > > > > I think all the issues have been adequately aired. I will turn to > > other things. > > I agree that the issues have been adequately aired, but that's > no call for flamage. You are right, I apologize, I should have left out the bracketed part. I note, though, there were some flames in the part I snipped as well. Ciao, Andreas
Re: Licensing Problems with Debian Packages (Was Re: Copyright lawyers analysis of Andreas Pour's Interpretation)
On Fri, Feb 18, 2000 at 12:35:55AM -0500, Andreas Pour wrote: > You are right, I apologize, I should have left out the bracketed part. Thank you. > I note, though, there were some flames in the part I snipped as well. Hm... Rereading my message, I see that I referred to you in an ironic or sarcastic way on more than one occasion. I apologize for the personal and critical nature of these remarks. -- Raul
Re: Licensing Problems with Debian Packages (Was Re: Copyright lawyers analysis of Andreas Pour's Interpretation)
Chris Lawrence wrote: > On Feb 17, Andreas Pour wrote: > [...] > > > I don't see why, after you've gone to such pains to establish that the > > > on a module license doesn't change when a module is linked with a GPLed > > > program. Why have you decided that this is a necessary step for this > > > case? > > > > B/c the LGPL says so. It says you can change the license to GPL, > > but then it is no longer under the LGPL. Now you want to have it > > both ways. However, the LGPL prohibits it. > > Apparently you can't read and/or comprehend English. That's obvious, isn't it? I can't speak or write it, either. > I mailed this > morning that just because something is put under the GPL once, that > does not necessarily mean that everyone else has to use it under the > GPL too. Your ignorance of this fact (and your not challenging it) > imply that all you're doing is trolling. Let's test my English comprehension, shall we? A good place to start is the actual LGPL language, wouldn't you agree? Section 3 states: Section 3. You may opt to apply the terms of the ordinary GNU General Public License instead of this License to a given copy of the Library. To do this, you must alter all the notices that refer to this License, so that they refer to the ordinary GNU General Public License, version 2 instead of to this License. (If a newer version than version 2 of the ordinary GNU General Public License has appeared, then you can specify that version instead if you wish.) Do not make any other change in these notices. Once this change is made in a given copy, it is irreversible for that copy, so the ordinary GNU General Public License applies to all subsequent copies and derivative works made from that copy. This option is useful when you wish to copy part of the code of the Library into a program that is not a library. Now, let's look at it sentence by sentence, so even I can comprehend it. You may opt to apply the terms of the ordinary GNU General Public License instead of this License to a given copy of the Library. OK, so this means I can use the GPL with the LGPL-licensed code, like libc. To do this, you must alter all the notices that refer to this License, so that they refer to the ordinary GNU General Public License, version 2 instead of to this License. OK, so I must change *all* the notices that refer to the LGPL to refer to the GPL. That means there no longer is *any* notice that the library is licensed under the LGPL; each notice refers to the GPL. It's not like the Perl license, which says you can apply either Artistic or GPL (or in this case LGPL or GPL); no, the only license referred to is now the GPL. The next sentence is not relevant to my point. Do not make any other change in these notices. OK, I cannot change the notices in any other way. That means I cannot, for example, add a new notice that refers to the LGPL. Once this change is made in a given copy, it is irreversible for that copy, so the ordinary GNU General Public License applies to all subsequent copies and derivative works made from that copy. Now look. My change is "irreversible". Now the GPL applies to *all* subsequent copies and derivative works thereof. Notably, the LGPL does not apply to it. If both licenses were to apply to it, it would say something like, Please show my where I made my reading and comprehension errors, kind teacher. > Besides which, this is irrelevant to your example of grep+libc, since > in linking grep with libc you don't modify any of libc's code, nor do > you patch libc with code that would make it come under the GPL. First of all, as I have pointed out, libc does in fact *contain* GPL code -- namely, libio. Secondly, the point is quite relevant to some people's arguments (of which you may or may not be one, I don't know). Some people have argued that Section 2(b) requires that when you link GPL'd code with a library, then that library *must* be licensed under the GPL (the argument is based on Section 3(a) requiring the "complete source code" to an executable to be distributed under the terms of Section 2). Since grep is GPL'd, and it links with libc, the obvious conclusion, for those who make the argument, is that libc must be licensed under the GPL. > The LGPL permits you to make derivative works of the library under > either the GPL or the LGPL. That does not mean that once you do this > (which we haven't anyway), you can never make another derivative work > under the LGPL Have you, perchance, read the LGPL? Or does your superior knowledge of English reading and comprehension permit you to dispense with such formalities? > , or even that you have to treat the original under the > GPL for ever and in eternity (which is what you seem to imply in this > paragraph). Perhaps my English problems are causing me to misunderstand the term "irreversible" in the LGPL. Could you kindly explain to me
Re: Licensing Problems with Debian Packages (Was Re: Copyright lawyers analysis of Andreas Pour's Interpretation)
On Sun, Feb 20, 2000 at 07:50:31PM -0500, Andreas Pour wrote: > Section 3. You may opt to apply the terms of the ordinary GNU > General Public License instead of this License to a given copy of > the Library. To do this, you must alter all the notices that refer > to this License, so that they refer to the ordinary GNU General > Public License, version 2 instead of to this License. (If a newer > version than version 2 of the ordinary GNU General Public License > has appeared, then you can specify that version instead if you > wish.) Do not make any other change in these notices. > > Once this change is made in a given copy, it is irreversible for > that copy, so the ordinary GNU General Public License applies to > all subsequent copies and derivative works made from that copy. > > This option is useful when you wish to copy part of the code of > the Library into a program that is not a library. > > Now, let's look at it sentence by sentence, so even I can comprehend it. Excuse me. Your "sentence by sentence" treatment managed to completely ignore that third paragraph of section 3. What do you think it means? -- Raul
Re: Licensing Problems with Debian Packages (Was Re: Copyright lawyers analysis of Andreas Pour's Interpretation)
Raul Miller wrote: > > On Sun, Feb 20, 2000 at 07:50:31PM -0500, Andreas Pour wrote: > > Section 3. You may opt to apply the terms of the ordinary GNU > > General Public License instead of this License to a given copy of > > the Library. To do this, you must alter all the notices that refer > > to this License, so that they refer to the ordinary GNU General > > Public License, version 2 instead of to this License. (If a newer > > version than version 2 of the ordinary GNU General Public License > > has appeared, then you can specify that version instead if you > > wish.) Do not make any other change in these notices. > > > > Once this change is made in a given copy, it is irreversible for > > that copy, so the ordinary GNU General Public License applies to > > all subsequent copies and derivative works made from that copy. > > > > This option is useful when you wish to copy part of the code of > > the Library into a program that is not a library. > > > > Now, let's look at it sentence by sentence, so even I can comprehend it. > > Excuse me. > > Your "sentence by sentence" treatment managed to completely ignore that > third paragraph of section 3. Well, it's clearly not a requirement, it's a suggestion/commentary, so not especially relevant in determining one's obligations under the LGPL. > > What do you think it means? Let's see, I think it suggests that you might want to do this "irreversible" conversion if "you wish to copy part of the code of the Library into a program that is not a library." I also think it suggests that the authors of the LGPL did not agree with the interpretation that requires the "complete source code" to be licensed under the GPL (esp. when considered with the preamble language which states "in a textual and legal sense, the linked executable is a combined work, a derivative of the original library, and the ordinary General Public License treats it as such", which does signal the belief that the "complete source code" for purposes of Section 3(a) of the GPL would include the library), though I would not rely on one license to interpret a different one. I suppose that since you think I "ignored" this suggestive sentence that you think somehow it changes the meaning of the preceding paragraphs? Ciao, Andreas
Re: Licensing Problems with Debian Packages (Was Re: Copyright lawyers analysis of Andreas Pour's Interpretation)
> > On Sun, Feb 20, 2000 at 07:50:31PM -0500, Andreas Pour wrote: > > > Section 3. You may opt to apply the terms of the ordinary GNU > > > General Public License instead of this License to a given copy of > > > the Library. To do this, you must alter all the notices that refer > > > to this License, so that they refer to the ordinary GNU General > > > Public License, version 2 instead of to this License. (If a newer > > > version than version 2 of the ordinary GNU General Public License > > > has appeared, then you can specify that version instead if you > > > wish.) Do not make any other change in these notices. > > > > > > Once this change is made in a given copy, it is irreversible for > > > that copy, so the ordinary GNU General Public License applies to > > > all subsequent copies and derivative works made from that copy. > > > > > > This option is useful when you wish to copy part of the code of > > > the Library into a program that is not a library. > > > > > > Now, let's look at it sentence by sentence, so even I can comprehend it. Raul Miller wrote: > > Excuse me. > > > > Your "sentence by sentence" treatment managed to completely ignore that > > third paragraph of section 3. On Sun, Feb 20, 2000 at 08:31:42PM -0500, Andreas Pour wrote: > Well, it's clearly not a requirement, it's a suggestion/commentary, > so not especially relevant in determining one's obligations under the > LGPL. I disagree with your suggestion that it's not relevant. I'd even go so far as to say that commentary which is included in the license is more relevant than what you or I have to say. > > What do you think it means? > > Let's see, I think it suggests that you might want to do this > "irreversible" conversion if "you wish to copy part of the code of the > Library into a program that is not a library." Ok. > I also think it suggests that the authors of the LGPL did not agree > with the interpretation that requires the "complete source code" to > be licensed under the GPL (esp. when considered with the preamble > language which states "in a textual and legal sense, the linked > executable is a combined work, a derivative of the original library, > and the ordinary General Public License treats it as such", which does > signal the belief that the "complete source code" for purposes of > Section 3(a) of the GPL would include the library), though I would not > rely on one license to interpret a different one. > > I suppose that since you think I "ignored" this suggestive sentence > that you think somehow it changes the meaning of the preceding > paragraphs? I think it points at a flaw in what you've been stating. You've been implying that the irreversible change mentioned in Section 3 is a requirement for cases where libc is used as a Library. But this third paragraph clearly indicates that Section 3 is optional. That the use of Section 3 is for cases where the code (for example, the lgpled libc code) would not be not used as a library. [For that matter, the first sentence of the first paragraph also clearly indicates that Section 3 is optional, but the third paragraph has the advantage of showing why the option is available.] To use a phrasing similar to what you've been using in other contexts: a Library need not be a Program. -- Raul
Re: Licensing Problems with Debian Packages (Was Re: Copyright lawyers analysis of Andreas Pour's Interpretation)
Raul Miller wrote: > > > > On Sun, Feb 20, 2000 at 07:50:31PM -0500, Andreas Pour wrote: > > > > Section 3. You may opt to apply the terms of the ordinary GNU > > > > General Public License instead of this License to a given copy of > > > > the Library. To do this, you must alter all the notices that refer > > > > to this License, so that they refer to the ordinary GNU General > > > > Public License, version 2 instead of to this License. (If a newer > > > > version than version 2 of the ordinary GNU General Public License > > > > has appeared, then you can specify that version instead if you > > > > wish.) Do not make any other change in these notices. > > > > > > > > Once this change is made in a given copy, it is irreversible for > > > > that copy, so the ordinary GNU General Public License applies to > > > > all subsequent copies and derivative works made from that copy. > > > > > > > > This option is useful when you wish to copy part of the code of > > > > the Library into a program that is not a library. > > > > > > > > Now, let's look at it sentence by sentence, so even I can comprehend it. > > Raul Miller wrote: > > > Excuse me. > > > > > > Your "sentence by sentence" treatment managed to completely ignore that > > > third paragraph of section 3. > > On Sun, Feb 20, 2000 at 08:31:42PM -0500, Andreas Pour wrote: > > Well, it's clearly not a requirement, it's a suggestion/commentary, > > so not especially relevant in determining one's obligations under the > > LGPL. > > I disagree with your suggestion that it's not relevant. > > I'd even go so far as to say that commentary which is included in the > license is more relevant than what you or I have to say. > > > > What do you think it means? > > > > Let's see, I think it suggests that you might want to do this > > "irreversible" conversion if "you wish to copy part of the code of the > > Library into a program that is not a library." > > Ok. > > > I also think it suggests that the authors of the LGPL did not agree > > with the interpretation that requires the "complete source code" to > > be licensed under the GPL (esp. when considered with the preamble > > language which states "in a textual and legal sense, the linked > > executable is a combined work, a derivative of the original library, > > and the ordinary General Public License treats it as such", which does > > signal the belief that the "complete source code" for purposes of > > Section 3(a) of the GPL would include the library), though I would not > > rely on one license to interpret a different one. > > > > I suppose that since you think I "ignored" this suggestive sentence > > that you think somehow it changes the meaning of the preceding > > paragraphs? > > I think it points at a flaw in what you've been stating. But of course you do :-). > You've been implying that the irreversible change mentioned in Section > 3 is a requirement for cases where libc is used as a Library. Well, it seems you misquoting me is becoming an annoying ritual. What I said is that under the interpretation -- an interpretation that obviously is not mine -- that Section 3(a)/Section 2(b) of the GPL require the "complete source code" -- including library source code (like qt) -- to be licensed under the GPL, libc would have to be licensed under the GPL. The next step in the reasoning is that if libc has to be licensed under the GPL, you have to go through the Section 3 (LGPL) conversion. > > But this third paragraph clearly indicates that Section 3 is optional. > That the use of Section 3 is for cases where the code (for example, the > lgpled libc code) would not be not used as a library. It's just an example. Anyway, I don't think libc has to be licensed under the GPL when linked with a GPL Program, for the very same reason I don't think Qt has to be licensed under the GPL when linked with a GPL Program. > [For that matter, > the first sentence of the first paragraph also clearly indicates that > Section 3 is optional, but the third paragraph has the advantage of > showing why the option is available.] > > To use a phrasing similar to what you've been using in other contexts: > a Library need not be a Program. Good. So you now agree that the "complete source code" of Section 3(a) of the GPL does not have to be licensed under the GPL. But no, of course you don't. What I find fascinating is that after all these e-mails debating with you, I really don't know what you think. And that, my friend, means I really should not be debating with you anymore. Ciao, Andreas
Re: Licensing Problems with Debian Packages (Was Re: Copyright lawyers analysis of Andreas Pour's Interpretation)
Raul Miller wrote: > > You've been implying that the irreversible change mentioned in Section > > 3 is a requirement for cases where libc is used as a Library. On Mon, Feb 21, 2000 at 12:27:45AM -0500, Andreas Pour wrote: > Well, it seems you misquoting me is becoming an annoying ritual. What > I said is that under the interpretation -- an interpretation that > obviously is not mine -- that Section 3(a)/Section 2(b) of the GPL > require the "complete source code" -- including library source code > (like qt) -- to be licensed under the GPL, libc would have to be > licensed under the GPL. The next step in the reasoning is that if libc > has to be licensed under the GPL, you have to go through the Section 3 > (LGPL) conversion. Except that libc (or any other LGPLed library) is not the complete source code for grep (or any other GPLed program which might use libc or some other LGPLed library). You do realize that, I hope. When applying the GPL when multiple licenses are involved means that the work as a whole is a collective work, and the individual licenses remain. > > But this third paragraph clearly indicates that Section 3 is > > optional. That the use of Section 3 is for cases where the code (for > > example, the lgpled libc code) would not be not used as a library. > > It's just an example. Anyway, I don't think libc has to be licensed > under the GPL when linked with a GPL Program, for the very same reason > I don't think Qt has to be licensed under the GPL when linked with a > GPL Program. It's statements like this that make me think you don't understand collective copyrights. Why else would you bother making such assertions? > > [For that matter, the first sentence of the first paragraph also > > clearly indicates that Section 3 is optional, but the third > > paragraph has the advantage of showing why the option is available.] > > > > To use a phrasing similar to what you've been using in other > > contexts: a Library need not be a Program. > > Good. So you now agree that the "complete source code" of Section 3(a) > of the GPL does not have to be licensed under the GPL. But no, of > course you don't. Once again, libc is not the complete source code. In some examples, it's a part of the complete source code, but the individual parts get to retain their own licenses. > What I find fascinating is that after all these e-mails debating with > you, I really don't know what you think. And that, my friend, means I > really should not be debating with you anymore. What I find mystifying is not that we disagree, but that when I try to pin down the point on which we disagree -- when I try to re-state it in my own words -- that you disagree with me on what issue it is that we're disagreeing on. It's as if you really agree with me on all the issues, but you've simply chosen to disagree with me on general principles. -- Raul
Re: Licensing Problems with Debian Packages (Was Re: Copyright lawyers analysis of Andreas Pour's Interpretation)
Raul Miller wrote: > > Raul Miller wrote: > > > You've been implying that the irreversible change mentioned in Section > > > 3 is a requirement for cases where libc is used as a Library. > > On Mon, Feb 21, 2000 at 12:27:45AM -0500, Andreas Pour wrote: > > Well, it seems you misquoting me is becoming an annoying ritual. What > > I said is that under the interpretation -- an interpretation that > > obviously is not mine -- that Section 3(a)/Section 2(b) of the GPL > > require the "complete source code" -- including library source code > > (like qt) -- to be licensed under the GPL, libc would have to be > > licensed under the GPL. The next step in the reasoning is that if libc > > has to be licensed under the GPL, you have to go through the Section 3 > > (LGPL) conversion. > > Except that libc (or any other LGPLed library) is not the complete source > code for grep (or any other GPLed program which might use libc or some > other LGPLed library). You do realize that, I hope. > > When applying the GPL when multiple licenses are involved means that the > work as a whole is a collective work, and the individual licenses remain. OK, perhaps we are making progress after all. It appears that you have now abandoned the argument that Qt itself must be licensed under the GPL. So if that is true, all you require is that the collective work in kghostview/Qt be licensed under the GPL, with "collective work" having the meaning provided in the Copyright Act. Please clarify/correct any mistake in the above summary, and we can proceed from there. > > > > But this third paragraph clearly indicates that Section 3 is > > > optional. That the use of Section 3 is for cases where the code (for > > > example, the lgpled libc code) would not be not used as a library. > > > > It's just an example. Anyway, I don't think libc has to be licensed > > under the GPL when linked with a GPL Program, for the very same reason > > I don't think Qt has to be licensed under the GPL when linked with a > > GPL Program. > > It's statements like this that make me think you don't understand > collective copyrights. Why else would you bother making such assertions? I find this statement puzzling. Is it not your position that libc is not part of the "complete source code"? You stated that above. If that is true, then Qt must also not be part of the "complete source code". If you disagree with this, please explain why libc is not, and Qt is, part of the complete source code, for purposes of Section 3(a) of the GPL. > > > > [For that matter, the first sentence of the first paragraph also > > > clearly indicates that Section 3 is optional, but the third > > > paragraph has the advantage of showing why the option is available.] > > > > > > To use a phrasing similar to what you've been using in other > > > contexts: a Library need not be a Program. > > > > Good. So you now agree that the "complete source code" of Section 3(a) > > of the GPL does not have to be licensed under the GPL. But no, of > > course you don't. > > Once again, libc is not the complete source code. In some examples, > it's a part of the complete source code, but the individual parts get > to retain their own licenses. By some examples you mean if you take some libc source code and use it in a GPL'd program. I am referring strictly to the case of dynamic linking. In that situation, do you see libc/Qt being part of the complete source code for purposes of GPL Section 3(a), or not? A simple "Yes I do"/"No I don't, for the following reasons . . . ." answer would be nice :-). Ciao, Andreas
Re: Licensing Problems with Debian Packages (Was Re: Copyright lawyers analysis of Andreas Pour's Interpretation)
On Mon, Feb 21, 2000 at 02:23:59PM -0500, Andreas Pour wrote: > OK, perhaps we are making progress after all. It appears that you have > now abandoned the argument that Qt itself must be licensed under the > GPL. So if that is true, all you require is that the collective work > in kghostview/Qt be licensed under the GPL, with "collective work" > having the meaning provided in the Copyright Act. > > Please clarify/correct any mistake in the above summary, and we can > proceed from there. I'm not sure what kind of distinction you're trying to draw. The way I see it, if every right granted by the GPL would also granted by the QPL then there would be no conflict between the two licenses. But, because the QPL does not grant all rights granted by the GPL, the GPL forbids distribution of a collective work which is comprised of GPLed code plus QPLed code. > > > > But this third paragraph clearly indicates that Section 3 is > > > > optional. That the use of Section 3 is for cases where the code (for > > > > example, the lgpled libc code) would not be not used as a library. > > > > > > It's just an example. Anyway, I don't think libc has to be licensed > > > under the GPL when linked with a GPL Program, for the very same reason > > > I don't think Qt has to be licensed under the GPL when linked with a > > > GPL Program. > > > > It's statements like this that make me think you don't understand > > collective copyrights. Why else would you bother making such assertions? > > I find this statement puzzling. Is it not your position that libc is > not part of the "complete source code"? You stated that above. If that > is true, then Qt must also not be part of the "complete source code". > If you disagree with this, please explain why libc is not, and Qt is, > part of the complete source code, for purposes of Section 3(a) of the > GPL. I agree that libc is part of the complete source code for programs like grep on a Debian system. Yet it is not the complete source code for those programs. This doesn't seem to me to be a very puzzling idea.. would you think that libc represents the complete source code for grep? Furthermore, I agree that libqt would also be a part of the complete source code for programs like kghostview. The difference between libc and kghostview is that while libc has a license which grants all the rights required by the GPL for grep, libqt doesn't have a license which grants all the rights required by the GPL for kghostview. [The bsd advertising clause may be an issue for grep+libc -- if we can show that there is some part of libc that grep uses which doesn't have GPL compatible rights on it then we've got a libc bug which needs to be fixed.] > > > > [For that matter, the first sentence of the first paragraph also > > > > clearly indicates that Section 3 is optional, but the third > > > > paragraph has the advantage of showing why the option is available.] > > > > > > > > To use a phrasing similar to what you've been using in other > > > > contexts: a Library need not be a Program. > > > > > > Good. So you now agree that the "complete source code" of Section 3(a) > > > of the GPL does not have to be licensed under the GPL. But no, of > > > course you don't. > > > > Once again, libc is not the complete source code. In some examples, > > it's a part of the complete source code, but the individual parts get > > to retain their own licenses. > > By some examples you mean if you take some libc source code and use it > in a GPL'd program. I am referring strictly to the case of > dynamic linking. In that situation, do you see libc/Qt being part of > the complete source code for purposes of GPL Section 3(a), or not? A > simple "Yes I do"/"No I don't, for the following reasons . . . ." > answer would be nice :-). I do see it as being a part of the complete source code -- however, I do not see it as representing the complete source code. Which is to say that I consider the GPL relevant as a collective copyright which applies to the library for that case. I'll also add that dynamic linking is an issue for the LGPL but not for the GPL. -- Raul
Re: Licensing Problems with Debian Packages (Was Re: Copyright lawyers analysis of Andreas Pour's Interpretation)
Raul Miller wrote: > > On Mon, Feb 21, 2000 at 02:23:59PM -0500, Andreas Pour wrote: > > OK, perhaps we are making progress after all. It appears that you have > > now abandoned the argument that Qt itself must be licensed under the > > GPL. So if that is true, all you require is that the collective work > > in kghostview/Qt be licensed under the GPL, with "collective work" > > having the meaning provided in the Copyright Act. > > > > Please clarify/correct any mistake in the above summary, and we can > > proceed from there. > > I'm not sure what kind of distinction you're trying to draw. I'm asking a very straight-forward question: if you link a dynamic library to a GPL Program, does the source code of the library have to be licensed under the GPL? I think you are really waffling on this issue. Please give a straight answer to this question. [ . . . ] > > > > I find this statement puzzling. Is it not your position that libc is > > not part of the "complete source code"? You stated that above. If that > > is true, then Qt must also not be part of the "complete source code". > > If you disagree with this, please explain why libc is not, and Qt is, > > part of the complete source code, for purposes of Section 3(a) of the > > GPL. > > I agree that libc is part of the complete source code for programs like > grep on a Debian system. Yet it is not the complete source code for those > programs. This doesn't seem to me to be a very puzzling idea.. would > you think that libc represents the complete source code for grep? > > Furthermore, I agree that libqt would also be a part of the complete > source code for programs like kghostview. The difference between libc > and kghostview is that while libc has a license which grants all the > rights required by the GPL for grep, libqt doesn't have a license which > grants all the rights required by the GPL for kghostview. I know the licenses are different. The question is still, does the "complete source code" to a GPL program have to be licensed under the GPL? In particular, if grep links to libc, does libc have to be licensed under the GPL, under your reading of Sections 3(a)/2(b) of the GPL? [ ... ] > > By some examples you mean if you take some libc source code and use it > > in a GPL'd program. I am referring strictly to the case of > > dynamic linking. In that situation, do you see libc/Qt being part of > > the complete source code for purposes of GPL Section 3(a), or not? A > > simple "Yes I do"/"No I don't, for the following reasons . . . ." > > answer would be nice :-). > > I do see it as being a part of the complete source code -- however, > I do not see it as representing the complete source code. Which is to > say that I consider the GPL relevant as a collective copyright which > applies to the library for that case. Please explain what that means. How does the collective copyright apply to a component of the collective work? When I read the Copyright Act it is clear to me that a collective copyright is separate from the component works. Ciao, Andreas
Re: Licensing Problems with Debian Packages (Was Re: Copyright lawyers analysis of Andreas Pour's Interpretation)
On Mon, Feb 21, 2000 at 02:23:59PM -0500, Andreas Pour wrote: > > > OK, perhaps we are making progress after all. It appears that you have > > > now abandoned the argument that Qt itself must be licensed under the > > > GPL. So if that is true, all you require is that the collective work > > > in kghostview/Qt be licensed under the GPL, with "collective work" > > > having the meaning provided in the Copyright Act. > > > > > > Please clarify/correct any mistake in the above summary, and we can > > > proceed from there. Raul Miller wrote: > > I'm not sure what kind of distinction you're trying to draw. On Mon, Feb 21, 2000 at 03:39:47PM -0500, Andreas Pour wrote: > I'm asking a very straight-forward question: if you link a dynamic > library to a GPL Program, does the source code of the library have to > be licensed under the GPL? I think you are really waffling on this > issue. Please give a straight answer to this question. Let me ask you a "straightforward" question: if you dissolve sugar in water, can you make the sugar boil? [Seems to me that while you can make the sugar water boil, the sugar itself does not. There might be some rather exceptional conditions where you could make sugar boil, but they have very little to do with the conditions where sugar water boils.] Similarly, the program, which includes the library, has to be license under the GPL while the library -- considered as an entity unto itself -- does not. If this doesn't make sense to you then I'd say that your question is, in fact, not at all straightforward. > > > I find this statement puzzling. Is it not your position that libc is > > > not part of the "complete source code"? You stated that above. If that > > > is true, then Qt must also not be part of the "complete source code". > > > If you disagree with this, please explain why libc is not, and Qt is, > > > part of the complete source code, for purposes of Section 3(a) of the > > > GPL. > > > > I agree that libc is part of the complete source code for programs like > > grep on a Debian system. Yet it is not the complete source code for those > > programs. This doesn't seem to me to be a very puzzling idea.. would > > you think that libc represents the complete source code for grep? > > > > Furthermore, I agree that libqt would also be a part of the complete > > source code for programs like kghostview. The difference between libc > > and kghostview is that while libc has a license which grants all the > > rights required by the GPL for grep, libqt doesn't have a license which > > grants all the rights required by the GPL for kghostview. > > I know the licenses are different. The question is still, does the > "complete source code" to a GPL program have to be licensed under > the GPL? In particular, if grep links to libc, does libc have to be > licensed under the GPL, under your reading of Sections 3(a)/2(b) of > the GPL? The library (using LGPL terminology) has to grant permission to be included in the collective work (the "Program", using GPL terminology), and the work as a whole is distributed under the terms of the collective license. So: the complete source code has to be licensed under the GPL, but some of the individual elements of it do not. > > > By some examples you mean if you take some libc source code and use it > > > in a GPL'd program. I am referring strictly to the case of > > > dynamic linking. In that situation, do you see libc/Qt being part of > > > the complete source code for purposes of GPL Section 3(a), or not? A > > > simple "Yes I do"/"No I don't, for the following reasons . . . ." > > > answer would be nice :-). > > > > I do see it as being a part of the complete source code -- however, > > I do not see it as representing the complete source code. Which is to > > say that I consider the GPL relevant as a collective copyright which > > applies to the library for that case. > > Please explain what that means. How does the collective copyright > apply to a component of the collective work? When I read the Copyright > Act it is clear to me that a collective copyright is separate from the > component works. The collective copyright is a separate license from that which is applied to some of the component works. The collective copyright applies to the work as a whole. The work as a whole is distributed under the terms of the collective copyright. Where individual copyrights apply (which are different from the collective copyright) they must make it legal for those individual parts to be distributed under the collective copyright. I don't understand what part of this isn't clear to you. In earlier messages I thought you indicated you understood these concepts and agreed with them. -- Raul
Re: Licensing Problems with Debian Packages (Was Re: Copyright lawyers analysis of Andreas Pour's Interpretation)
Raul Miller wrote: [ ... ] > On Mon, Feb 21, 2000 at 03:39:47PM -0500, Andreas Pour wrote: > > I'm asking a very straight-forward question: if you link a dynamic > > library to a GPL Program, does the source code of the library have to > > be licensed under the GPL? I think you are really waffling on this > > issue. Please give a straight answer to this question. > > Let me ask you a "straightforward" question: if you dissolve sugar in > water, can you make the sugar boil? > > [Seems to me that while you can make the sugar water boil, the sugar > itself does not. There might be some rather exceptional conditions > where you could make sugar boil, but they have very little to do with > the conditions where sugar water boils.] > > Similarly, the program, which includes the library, has to be license > under the GPL while the library -- considered as an entity unto itself -- > does not. > > If this doesn't make sense to you then I'd say that your question is, > in fact, not at all straightforward. [ ... ] > > I know the licenses are different. The question is still, does the > > "complete source code" to a GPL program have to be licensed under > > the GPL? In particular, if grep links to libc, does libc have to be > > licensed under the GPL, under your reading of Sections 3(a)/2(b) of > > the GPL? > > The library (using LGPL terminology) has to grant permission to be > included in the collective work (the "Program", using GPL terminology), > and the work as a whole is distributed under the terms of the collective > license. > > So: the complete source code has to be licensed under the GPL, but > some of the individual elements of it do not. [ ... ] > > Please explain what that means. How does the collective copyright > > apply to a component of the collective work? When I read the Copyright > > Act it is clear to me that a collective copyright is separate from the > > component works. > > The collective copyright is a separate license from that which is applied > to some of the component works. The collective copyright applies to the > work as a whole. The work as a whole is distributed under the terms of > the collective copyright. Where individual copyrights apply (which are > different from the collective copyright) they must make it legal for > those individual parts to be distributed under the collective copyright. > > I don't understand what part of this isn't clear to you. In earlier > messages I thought you indicated you understood these concepts and agreed > with them. I have concluded that you don't understand the relevant principles of copyright law. As it seems you feel the same way about me, any further discussion is pointless. Ciao, Andreas
Re: Licensing Problems with Debian Packages (Was Re: Copyright lawyers analysis of Andreas Pour's Interpretation)
> > Let me ask you a "straightforward" question: if you dissolve sugar in > > water, can you make the sugar boil? > > > > [Seems to me that while you can make the sugar water boil, the sugar > > itself does not. There might be some rather exceptional conditions > > where you could make sugar boil, but they have very little to do with > > the conditions where sugar water boils.] > > > > Similarly, the program, which includes the library, has to be license > > under the GPL while the library -- considered as an entity unto itself -- > > does not. > > > > If this doesn't make sense to you then I'd say that your question is, > > in fact, not at all straightforward. [ ... ] On Mon, Feb 21, 2000 at 05:31:19PM -0500, Andreas Pour wrote: > I have concluded that you don't understand the relevant principles of > copyright law. Please be specific. Which principles are you refering to? What is specific point of law on which we disagree? -- Raul
Re: Licensing Problems with Debian Packages (Was Re: Copyright lawyers analysis of Andreas Pour's Interpretation)
Raul Miller wrote: > > > > Let me ask you a "straightforward" question: if you dissolve sugar in > > > water, can you make the sugar boil? > > > > > > [Seems to me that while you can make the sugar water boil, the sugar > > > itself does not. There might be some rather exceptional conditions > > > where you could make sugar boil, but they have very little to do with > > > the conditions where sugar water boils.] > > > > > > Similarly, the program, which includes the library, has to be license > > > under the GPL while the library -- considered as an entity unto itself -- > > > does not. > > > > > > If this doesn't make sense to you then I'd say that your question is, > > > in fact, not at all straightforward. > > [ ... ] > > On Mon, Feb 21, 2000 at 05:31:19PM -0500, Andreas Pour wrote: > > I have concluded that you don't understand the relevant principles of > > copyright law. > > Please be specific. Which principles are you refering to? > > What is specific point of law on which we disagree? > The part where you stated: > So: the complete source code has to be licensed under the GPL, but > some of the individual elements of it do not. Also, from various statements I can't bother to cull together, I don't think you understand what a copyright in a collective work consists of, or what it applies to and what it does not apply to. Ciao, Andreas
Re: Licensing Problems with Debian Packages (Was Re: Copyright lawyers analysis of Andreas Pour's Interpretation)
> > What is specific point of law on which we disagree? ... > The part where you stated: > > > So: the complete source code has to be licensed under the GPL, but > > some of the individual elements of it do not. > > Also, from various statements I can't bother to cull together, I don't > think you understand what a copyright in a collective work consists > of, or what it applies to and what it does not apply to. This isn't a point of law, this is a statement of mine. If I try to translate my statement into a point of law, I'd say that the point of law is something like this: For derivative works where pre-existing material is covered by copyright (where it's lawful for the copyright on the derivative work to extend to the pre-existing material), the existence of a copyright on the derivative work does not imply any exclusive right to the preexisting material. Are you saying that this is the point on which we disagree? -- Raul
