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
* apache@apache.org.
*
* 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 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.
> 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.
> 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 ...".
Oh, that's clever, are you now implying that you can put any restriction in the
copyright notice b/c of this sentence? What if the notice says you cannot
redistribute, is that OK too? I don't see the difference b/w that and the
advertising clause -- each is a requirement not found in the GPL.
> 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.
Well, I guess I can make a proprietary Linux kernel then just by adding
"appropriate" language to the copyright notice.
> 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.]
Well, I am not aware of any requirement that legal documents can only pertain to
one subject. If I say, "Raul, I will give you $100 if you agree not to put my
name in an advertisement", would you agree that's enforceable? I would assume
so. So what is the difference if I give you, instead of $100, free code that is
worth a lot more than that? I.e., I say, "Raul, I will give you all this free
code to do with as you please if you agree not to put my name in an
advertisement".
> 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?
TT does not gain copyright ownership -- they just get a license to redistribute
with the commercial version of their library.
> Are you claiming that there's no legal merit to Troll's clause?
No, but you seem to be, since the requirement does not pertain to the
distribution I guess you would say it's not enforceable?
> > 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.
It's not relevant anyway. Money has nothing to do with copying and distributing,
but yet obviously you can have a provision that says you can distribute only if
you pay $X for each copy you distribute.
I am not aware of any case law that says a copyright license cannot impose any
restrictions unrelated to copying and distributing.
> 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.
I don't see how it can be retroactive, and frankly I don't see how they can
change the license w/out the consent of each contributor. Hence, their change in
the license terms may well be invalid.
> 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.
Not according to http://www.gnu.org/manual/glibc-2.0.6/html_node/libc_524.html.
And anyway I am not sure they can do that -- the question is whether there were
any contributors to the code that own a copyright in it other than UCB, and if
each of these has given consent to the change; beyond that the issue is whether
the change is -- or even can be -- retroactive (since it is not clear who
licensed the code to FSF to use in libc; if not UCB, the intermediary would have
to agree to the change as well).
> 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.
Well, libc. As I recall, your arguments require libc to be licensed under the
GPL to link to GPL'd programs.
> 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.]
Why not?
> > > 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.
If you are talking about requring patches, that is totally immaterial. Patching
is an automated part of the build process, just like including header files or
configuring. Now I'm sure you will say, but it does not say "material
requirements", to which I respond, it also does not say "requirements relating to
copying, modifying or distributing".
> > > 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.
Well, good, I'm glad to hear that (if by "prior copyrights" you mean "prior
licenses"). In that case, I don't see the problem with KDE/Qt, really. It is
totally possible to license the Qt/KDE collective work under the GPL.
If that is the only issue left, let's focus on that one, and maybe we can reach a
consensus (scary thought, eh?).
> > > > 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.
Hmmm? Let's see. I take libio, a "Program" under Section 2, and modify it by
adding libc. I then want to distribute this modified libio. I have to do this
in compliance with Section 2, no? Well, let's look at Section 2. Section 2(b)
says that I have to cause that work "to be licensed as a whole at no charge to
all third parties under the terms of this License". I guess if you no longer
claim that this requires the work to be licensed under the GPL, I accept your
view.
But in that case, I don't see the problem w/ KDE/Qt either.
> > 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.
That's not what it says. It's a fork. Forks aren't included -- it must be the
GNU compiler. By GNU it means distributed by GNU, and egcs (until recently) was
not. Again curious how sometimes you can interpret ambiguous language very
strictly and other times you can ignore clear language.
> 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).
OK, I can accept this point for the binary. But the exception does not say that
the executable's source code is not covered by the GPL; only that the executable
is not (so the references to Sections 1 and 2 in the first sentence of Section 3
can be ignored). But when you distribute the "complete source code" to libio
under Section 3(a), you still must distribute the executable's source code under
Sections 1 and 2, no?
> > 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.
Now combining GPL code into the same source files and into the same library is a
"mere aggregation"? If that is so, why can't I "aggregate" Qt with KDE (in fact,
KDE is far more removed from Qt than libio is from libc -- libio 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.
>
> So you claim that if I distributed modified Qt with a Qt+GPL license
> that Troll would not object?
Not all of Qt, just the patch. Weren't you saying above that the entire source
code need not be licensed under the GPL? Yes you were. So why does Qt need to
be? According to your reasoning above (w/ libio), Qt is a mere aggregation and
thus is not covered by the GPL at all, and also only the KDE/Qt collective work,
not Qt itself, need be licensed under the GPL.
> > > > > > 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.
Such as the libc code? Remember, the libc code can be converted to GPL, but then
it does not have this 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?
Noted above.
> > > > > 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.
It's part of the same source code. It's like taking GPL'd code and adding it to
Qt itself. You consider this to be a "mere aggregation" and hence not restricted
by the GPL?
[ ... ]
> > 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.
Now I know you're lying :-).
[ ... ]
> > > 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.
So? It does not restrict your right to distribute/copy/modify, and I thought you
said above those are the only requirements that matter? Yes, in fact, you did
say that above (in context of the BSD advertising clause).
And you also said above (where I snipped) that you interpret the GPL
consistently!!!!
> 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).
And you can't patch GPL code if you can't grant GPL rights . . . . You can
always use your own code to patch it, just not someone else's; but the same holds
true for GPL'd works, no?
Let's look at this realistically anyway. Qt is a C++ library. You can patch it
just by overriding classes in your code. Perhaps you can provide an example
where this would pose a problem in real life, bearing in mind the ability to
patch, to strip functions from Qt (w/ a patch) and re-implement them in a library
you write (which is not an official part of Qt and hence does not fall under the
license-back provision), and to link with GPL code.
Ciao,
Andreas
Reply to: