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 additional restrictions to copying or
distributing. So perhaps you are saying Section 6 is unenforceable as well?
> 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).
> 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.
> > 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.
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.
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
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.
> > > > 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.
> > > > 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).
> > 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.
> > > 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.
> > 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 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.
> > (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 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.
[ ... ]
> > 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.
> 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.
Ciao,
Andreas
Reply to: