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 issue -- though I don't have absolute proof of that.
> 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.
I'm not aware of any case law which defines "advertising materials"
in the context of copyright.
Anyways, the BSD folks have removed the advertising clause from their
current material. I believe that they intended this to be retroactive.
So I think that this is just a matter of updating some documents for
the case of BSD copyrighted material.
This might be an issue for apache, but I'm going to wait to see what
the response is on my libc advertising clause bug report before I
do much more in that direction.
[You might object that I'm not moving very quickly, but it's been at
least a couple years since I first filed a bug report on the kde copyright
issue, and I waited several months there before doing anything more than
report the bug.]
> 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).
In the case of BSD software, it's not a moral requirement. BSD has
retracted the advertising clause.
In the case of Apache, it would possibly be a moral requirement, but
it's not clear to me that Apache is linked with any GPLed code.
In the case of Perl modules, it might be an issue. But I'm going
to have to spend some time constructing a case where it's actually
an issue. [I don't agree with your argument that you must invoke
LGPL's "relicense entire library as GPLed software" to link LGPL
with GPLed programs.]
> > 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 additional restrictions
> to copying or distributing. So perhaps you are saying Section 6 is
> unenforceable as well?
My point was that the advertising clause doesn't restrict copying
distribution or modification. I would say that any clause is relevant
to Section 6 if it in some way restricts copying, distribution or
modification.
In the case of the QPL, distribution of modifications is restricted.
> > 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.
>
> It most certainly is related to distribution. Who would advertise the
> code if they are not distributing it? The restriction in the BSD-type
> license does not say you can't mention the copyright holder, it is
> limited to "advertisements and promotions", which are all activites
> closely tied to distribution (as much as say the requirement to "make
> available" source code when you distribute executables).
That's assuming that any relevant advertising material wouldn't already
have the appropriate text.
> > 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?
>
> I thought your position was that Section 2(b) of the GPL requires you
> to license the "complete source code" under the GPL.
Yes -- as a collective work. That does not require that individual
modules lose their prior copyrights.
> > > 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.
> >
> > The special libio exception does not require dynamic linking.
>
> The libio exception applies only to the *binary*. You are mixing GPL
> source code with LGPL source code. The combined work is then licensed
> under the LGPL. So you have converted GPL code to LGPL code.
Note that if no binary is being distributed then there's no requirement
that the complete source be distributed at all.
> To be clear, the libio exception states:
>
> As a special exception, if you link this library with files
> compiled with a GNU compiler to produce an executable, this does
> not cause the resulting executable to be covered by the GNU General
> Public License. This exception does not however invalidate any
> other reasons why the executable file might be covered by the GNU
> General Public License.
>
> So first off is someone uses a compiler other than the GNU compiler
> (like egcs 1.1.x or pgcc or the special compiliers used for embedded
> devices), the exception does not apply. Perhaps you should make a
> public announcement like you did with KDE saying that Linux-Mandrake
> and these embedded devices distributions are "illegal" b/c they do not
> use a GNU compiler to compile libc.
egcs is an instance of the gnu compiler.
Anyways, the Debian libc is built by a gnu compiler. That's sufficient
for the moment. I believe work is being done to replace libio, but I
don't know how it's progressing.
> Moreover, it says the executable is not covered by the GPL. This means
> that there is no permission to distribute libio -- the permission to
> redistribute coming only from the GPL. So, in other words, if you take
> the position that the executable is not covered by the GPL, then you
> have no right to distribute it. Of course, you could take the view
> that the reference to "the executable" in the last sentence of the
> exception applies to the executable sans libio, but in that case you
> are changing the clear language, something which you have repeatedly
> told cannot be done
Yep, it says that the resulting executable from linking isn't covered
by the GPL. So that would seem to mean that only libio considered in
isolation is a "Program", and that as long as the source code for libio
is distributed in accordance with the GPL there are no restrictions on
the rest of the program.
Rather weird, and less protection against proprietary use than the LGPL,
but I'm not the author and I don't get to dictate the terms (unless I
write a replacement libio).
> In addition, the exception only applies if you *link* with other
> executables; it therefor does not apply to libc, which is not *linked*
> with libio but in fact is added to it and they are compiled together.
> Accordingly, the libio exception does not even apply to the libc
> binary. Let me rephrase this so there is no misunderstanding. The
> exception says, "OK, I'm a GPL'd program, if you compile me and link
> me to another program, that other program does not thereby become
> subject to the GPL". That is not the case with libc -- libio is not
> linked to libc after compilation, it is part of libc.
No, because the GPL already allows mere aggregation.
> > > > > 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.
> > >
> > > Well, I thought that since Debian hasn't had an IPO, legal
> > > uncertainty is enough to prevent distribution ;-) ?
> >
> > In the case of KDE, it's obvious that there are >>authors<< of
> > some of the code (Troll, and the original authors of works behind
> > kghostview, kmidi, kscd, kdvi, ...) who could be upset if we
> > distributed kde executables under the terms of the GPL, and acted on
> > either of the licenses involved as if either of the licenses were
> > satisfied.
> >
> > I don't see how that's relevant to the BSD issues.
>
> But they would not be upset if you distributed them under the terms
> everyone else does. So what exactly is your concern?
>
> And face it, if someone was upset enough to sue, they would hardly
> select non-profit, no-money Debian as the entity to make an example
> of. They would pick someone with money -- like VA Linux, Caldera,
> RedHat or Corel.
So you claim that if I distributed modified Qt with a Qt+GPL license
that Troll would not object?
> > > > > 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.
> > >
> > > It's relevant b/c you cannot relicense Apache or Perl under the
> > > GPL, and, as you have claimed, linking with GPL works requires
> > > that to happen.
> >
> > Not for the case of libio, or any material which carries the libio
> > exception to the GPL.
>
> Covered above. But, to be clear, my understanding from your posts
> is that you believe if you modify a GPL'd work (like libio), the
> resulting entire work must be distributed under the GPL -- I'm not
> talking about linking in a separate module at run-time, I am talking
> about making modifications to the GPL code itself. Please do tell me
> if you disagree with this.
>
> Now, the libio exception does not apply to source code. So when you
> add libc code to it, the libc code must be licensed under the GPL. If
> that's not the case, I would really like to see your reasoning for
> this (and please don't bring up the libio exception b/c it applies
> *only* to binaries, not to the source code; and moreover only applies
> to *linking* rather than *combining*, and when you modify, under your
> reading, Section 2(b) requires the entire derived work to be licensed
> under the GPL).
In the case of libio it's pretty clear that the modified work would
still carry the libio exception.
This is different from the case where I'm bringing in code from some
author which doesn't have that exception.
> > > Moreover, I suspect you are ignoring the two types of advertising
> > > clauses at issue which make Apache and Perl incompatible with
> > > the GPL (under your curious reading of what makes something
> > > incompatible with the GPL -- this greater rights/lesser rights
> > > conception).
> >
> > There's a very tenuous possibility that we do need to pull Apache.
> > I'm not convinced yet. I don't see that even that ghost of a
> > possibility exists for Perl.
>
> I stand corrected on Perl; but do consider mod_perl and the other Perl
> add-ons.
Ok, so for those cases, what do you see as the problem?
> > > > libio is GPL + an exception, not just plain GPL.
> > >
> > > The exception not being relevant.
> >
> > What legal basis do you have for this claim?
>
> Again, the exception, by its terms, applies only to the binary, and
> there are certain other conditions to the exception applying which are
> not satisfied in the libc case.
The case where it's not linked isn't interesting because that would
be "mere aggregation" under the GPL.
> > > You say if you modify a GPL work (libio), you must license the
> > > entire result under the GPL. But someone has modified libio by
> > > adding libc to it and is now distributing it under the LGPL. If
> > > you think this is OK, then you should be able to take GPL code and
> > > add it to Qt; I don't see any difference.
> >
> > I don't see anything like the libio exception on the other GPLed
> >works.
>
> You have yet to explain whey the libio exception is relevant at all in
> the libc case.
I have now.
> > > > > 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.
> > >
> > > Sure, let me name a few before doing more research (once I see you
> > > are serious about removing these packages from Debian I will take
> > > the time to delve deeper):
> > >
> > > (1) Artistic license code, such as Perl, has advertising
> > > restrictions which are incompatible with Section 6 of the GPL;
> >
> > Advertising clause -- probably a bogus issue. I'm waiting to find
> > out more.
> >
> > > (2) Apache cannot be relicensed under the GPL and also has
> > > incompatible advertising restrictions and also an incompatible
> > > requirement to rename modified works (clause 5 of the license);
> >
> > Advertising clause -- probably a bogus issue. I'm waiting to find
> > out more.
> >
> > > (3) X cannot be relicensed under the GPL; and
> >
> > This is not a statement from the X license. Irrelevant.
>
> Yes, I know, you just choose to ignore the X license, since the GPL
> appears to be the only license that deserves to be observed.
No, we've already established that for a collective work you can
have multiple copyrights on the material. The X license seems to
grant some additional permissions, but you've made the claim that
those permissions are legally meaningless, and it's pretty clear
that they're not required.
> > > (4) libc (both your modified one and the FSF's) contains
> > > code which cannot be licensed under the GPL.
> >
> > This code has the libio exception. Irrelevant.
>
> The exception does not apply.
I believe I've shown that it does.
> I find it curious that you are able to get such far-reaching results
> from ambiguos langauge in the GPL, yet are willing to ignore quite
> clear language in other licenses.
I see nothing ambiguos about the langauge in the GPL.
> [ ... ]
>
> > > OK, I'll wait and see whether Debian really believes what it says
> > > or whether its just blowing smoke at KDE; I certainly don't have
> > > time to catalog license problems (under your reading of the GPL)
> > > when they will be ignored just b/c the program is popular with
> > > Debian developers.
> >
> > We believe there are authors involved in the creation of kde who
> > would be unhappy if we interpreted the licenses on KDE material as
> > if they were legally valid. We do not believe that's the case for
> > these other works.
>
> If you interpreted it like everyone else does, there would be no
> problem. The reason you have a problem is that you take an unnatural
> reading of the GPL, then apply it to KDE but not to other programs. If
> in fact you believe that Section 2(b) requires the "complete source
> code" , including DLLs, to be licensed under the GPL, then you must
> stop distributing anything linked to X or libc. If you don't think
> that, then linking to a DLL Qt is OK.
>
> I personally don't care which interpretation you pick; like I said,
> there is enough ambiguity that I don't think your reading of Section
> 2(b) is impossible. However, if you take that stand, please apply it
> consistently, not just to KDE.
I believe that my interpretation is consistent.
> > The worst problem is: If we took the GPL as literally true and
> > distributed modified Qt with GPLed modifications, would Troll be
> > happy with us?
>
> There is no reason to GPL modifications to Qt. QPL satisfies the "free
> software" criteria, so you can release your Qt modifications under the
> QPL.
>
> But, in fact, as I read the QPL
> (http://www.troll.no/qpl/plaintext.txt), you can GPL modifications
> (patches) to it. And if you are concerned that distributing the binary
> containing both GPL'd and QPL'd code would violate the GPL, just apply
> both the GPL and the QPL to the patch, like Perl applies both the
> Artistic license and the GPL.
3b of that license says that that the initial developer can change
the license on those patches to anything else. Which limits the
nature and scope of those patches (I can't include material where
I can't grant this right to the initial developer).
--
Raul
Reply to: