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
> * 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/).":
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 suggesting that if KDE gets its act together and publishes
kde software with an appropriate copyright that, even after years have
gone by, it's appropriate to pull the software if we find some files
which haven't been properly updated with the new license -- even for cases
where we have clear statements of intent from all of the relevant authors?
> > 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.
Redistribution of copyrighted material is a copyright issue, wouldn't
you say?
Use of terminology in the creation and distribution of material by an
independent author isn't properly a copyright issue. That would be a
valid trademark issue, but the laws for trademarks are very different
from the laws for copyrights.
> > 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.
If you're the copyright holder, sure.
> > 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".
The BSD license doesn't indicate any exchange of anything of value, so
it's not reasonable to interpret it as a contract.
> > 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.
Given that they can put any license they choose on Qt -- in principle,
this includes licenses which prevent the original author of the GPLed
code from accessing the modified work -- I don't see that your point
has much relevance.
> > 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?
It pertains to activities involving copyrighted material, so it's enforceable.
Furthermore, it's within the scope of the GPL (see the second paragraph
of section 0 before you fail to understand this, next time).
> > 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.
If a copyright notice says: you must pay $x for each copy you distribute,
that means that money has something to do with distribution for that case.
If a copyright notice says: everyone must always pay $x every friday,
that doesn't really have anything to do with distribution (however,
since it's traditional to deal with exchanges of money in the context of a
copyright notice, that particular statement would probably be interpreted
in court to mean "everyone who posesses a copy of the copyrighted material
must pay $x every friday" -- and I actually don't know if that would be
enforceable or not).
> I am not aware of any case law that says a copyright license cannot
> impose any restrictions unrelated to copying and distributing.
It's not clear that the BSD advertising clause is a restriction on copying
and distributing. It looks more like an attempt to use copyright law
in place of trademark law.
In any event, the copyright holders have retracted that clause.
> > 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.
They're the copyright holders. That gives them the right.
And you're right that they can't deny rights which have already been granted.
But since they're not denying anybody any rights which they've already granted,
I don't see that that is an issue.
> > 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).
The "contributors" issue is only an issue where there are many copyright
holders. In the case of BSD, there is a single copyright holder, so
it's not a big deal to get the copyright fixed.
> > 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.
Let me guess... you never saw that the GPL contains the following:
If identifiable sections of that work are not derived from the Program,
and can be reasonably considered independent and separate works in
themselves, then this License, and its terms, do not apply to those
sections when you distribute them as separate works.
> > 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?
libc can be reasonably considered an independent and separate work from
grep.
> > > > 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".
I'm talking about the requirement that Troll must be able to distribute
the modifications in a propritary fashion. This means that I can't
include other people's GPLed work if I modify that part of the Program.
However, I'll point out that the patch clause is material to some people.
[Apparently it's significant to Troll, for example.]
> > > 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?).
Ok, so I'm going to modify kghostview so that QTableView can be broken
into independent windows by user interaction. I'm going to use some
GPLed code from the GIMP to do this.
You claim that there's no problem with KDE/Qt, so that means that I
can modify the Qt part of kghostview and distribute the result, even
though I can't grant Troll the right to distribute the modified Qt
under their commercial license.
But hey, you don't see the problem so it must be legal, right?
> > 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 longe claim that this requires r
> the work to be licensed under the GPL, I accept you r view.
>
> But in that case, I don't see the problem w/ KDE/Qt either.
libc+libio either requires linking libio with libc (in which case the
libio exception kicks in) or it does not (in which case the GPL's
"mere aggregation" clause is sufficient).
> > 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.
GNU doesn't distribute anything. The FSF distributes software, but
that's different.
Anyways, egcs has a GNU copyright on it, last time I checked.
> > 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 this (albeit weird) case, the Program consists of only libio.
I agree that the libio exception is poorly written, but the consequence is
just that you have a Program which is embedded in a file which represents
part of some other work which is not a GPLed work. This is something
that the GPL is designed to prevent, but the libio exception is, after
all, an exception.
> > 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).
Are you saying that libio is linked to libc?
> > 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.
I said that the combined work must be licensed under the GPL, but that
individual works might have their own copyrights.
So for KDE+Qt to be distributable, I have to be able to take the entire
kdvi source code (which includes Qt) and modify any part of it --
without being required to give Troll a proprietary license to my mods,
and without having to follow the patch clause.
> > 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.
If you did that then the exception would be rather silly, I agree.
> > > 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.
Ok, so it's your "grep+libc" is the same copyrighted work as "perl+libc"
argument?
...
> > > 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 :-).
Just like you know that grep is perl...
> > 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!!!!
Ok, so I'll just go distribute my modified kghostscript (with integrated
Qt mods) as a flat GPLed tarball, and anyone can take that GPLed code
and do whatever they feel like, eh?
> > 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.
So why was Troll so hostile to the Harmony project (which would have
re-implemented these routines in a thread-safe manner)?
--
Raul
Reply to: