(please don't drop debian-legal from the Cc list)
On Sun, Feb 13, 2000 at 08:39:13PM +1100, Don Sanders wrote:
> On Sun, 13 Feb 2000, Anthony Towns wrote:
> > > Third, I challenge you to find a relevant case that says a program is the
> > > same "work", for copyright purposes, with a dynamically loaded library
> > > when it is not running.
> > *shrug* So show me some precedents for considering them separately. This is
> > pretty much a null argument.
> MS windows programming is a good example of that. Programming on Windows
> requires linking to MS dlls.
Note that `MS windows programming' is not a court case.
And again this is completely irrelevant: it's not an issue for the GPL
because the GPL exempts these as being distributed with major components
of the OS; and it's not an issue for anyone writing software for Windows
because Microsoft specifically gives you permission to redistribute it.
> > > Of
> > > course, if that were the case, then every single MS Windows program would
> > > be a derived work of MS Windows dlls and would require the consent of
> > > Microsoft to be distributed.
And just to clarify: whether Microsoft's consent is required or not doesn't
particularly matter: Microsoft have *given* their consent.
> > > > That is, it didn't differentiate between statically linked executables
> > > > (which clearly makes a combined work under copyright law), and
> > > > dynamically linked binaries (which is less clear).
> > I should add: and as such, there's probably a reasonable chance that a
> > court would be willing to extrapolate the existing terms to cover a new
> > possibility that wasn't considered explicitly.
> No comment. But see the list archives.
Let me guess: Andreas Pour thinks differently, and as a KDE supporter is
an authority in the matter?
Please, feel free to cite a case (a court case, not a kde-licensing
debate) where it was ruled that a license that didn't consider a
technique or technology that became common a few years later, but had
considerations for a somewhat analogous technique or technology could
not be extrapolated. It doesn't have to be related to computers at all.
Anything will be fine.
> > > > Now with dynamically liked GPL software we have three cases:
> > > > (c) A GPLed binary linked against a GPL-incompatible library
> > > > (dynamic linking in all cases)
> > > >
> > > > We'll note that in no case is the library a derived work (in any sense)
> > > > based on the binary (it doesn't include any code from the binary, it's
> > > > perfectly usable without the binary having ever been written, and so
> > > > on).
> > > >
> > > > The final case, (c), which is what KDE fits under, doesn't have as
> > > > "easy" an out, though.
> > >
> > > This assumes that Qt is GPL-incompatible. I may or may not agree with
> > > that, it could really mean a wide range of things.
> >
> > It means that it can't be distributed under the terms of sections 1 and
> > 2 of the GPL. It means you can't make a statically linked binary linking
> > to it and distribute it. Etc.
> The important question is when applying the GPL to a KDE application is QT
> part of the Program (and please see the definition of the Program given in
> Section 0). If is then QT can't be distributed under the terms of sections 1
> and 2. If QT isn't part of the Program then it can and must (if you believe
> QT is as part of the complete source) be distributed under the terms of
> Sections 1 and 2.
Erm, what? ``If Qt isn't part of the Program then it can and must be
distributed under the terms of Sections 1 and 2'' ?
Are you trying to say that since Qt doesn't have `GPLed' labelled on it
somewhere, then it's not the Program and since terms 1 and 2 only apply
to the Program, they don't apply to Qt, even when term 3 says it does
apply?
ie, are you trying to say that section 3a is technically meaningless,
because the complete source code won't be labelled GPLed, and hence won't
be distributable under sections 1 and 2? And because it's technically
meaningless it can be completely struck at and conveniently ignored?
Or am I reading too much into a typo somewhere?
Qt *cannot* be distributed under terms 1 and 2 of the GPL: term 2 gives
your more freedom in how you make your modifications than the QPL permits.
Only Troll have the right to give that extra permission, no one else does.
If the GPL *requires* you to distribute Qt under terms 1 and 2 of the
GPL in order to do something (distribute binaries, eg), then you *can't*
do that someting because you *can't* distribute Qt under terms 1 and 2
of the GPL.
> See also the Xfree license issue. It's highly relevant.
There is no `Xfree license issue'. I'm allowed to distribute a program
using code under both licenses as long as I:
* conspicuously and appropriately put an appropriate copyright notice
and disclaimer of warranty somewhere
* keep the GPL and disclaimer of warranty intact
* i may charge a fee
* if i modify it, i have to add notices
* i have to make sure everyone can use it according to the GPL
(according to the GPL)
* include the Xfree86 copyright and permission notice
(according to the Xfree/MIT license)
You'll note that the last point is implied by the first. If you're worried
by the ambiguity in the term "appropriate" you'll note its spelt out for
you by the Xfree86 people.
If it's just the term "relicense" that's worrying you: ignore it. It
doesn't mean what it says (and it's not in the GPL either, you'll notice).
The viral property of the GPL (if you make a derived work based on some
GPLed software and some other software, then *all* of it must be able to
be distributed under the terms of the GPL: to distribute program G+B,
you have to distribute the source to both, even though the author of
module B never said anything about that) has similar properties to
relicensing in most situations is all.
> > > This interpretation is a little tenuous, depending on whether
> > > > interpreting `all modules it contains, plus any associated interface
> > > > definitions files, plus the scripts used to control compilation and
> > > > installation' as not exhaustive is reasonable or not. I'm inclined to
> > > > think it is.
> > > Of course its exhaustive. It doesn't say "such as" or "including without
> > > limitation". It has a list, and that's all there's to it.
> > Then please respond to the Emacs/DVD hypothetical. Those weren't rhetorical
> > questions.
> I don't think Andreas' is a big fan of the legal draftmanship of the GPL. I'm
> not to sure why you expect him to defend it.
It's perfectly permissable to answer "No, the GPL sucks, the DVD people
would be allowed to do this, what's your point?". I'd just like to know
if he's consistently interpreting this clause, or if he's special-casing
it to make KDE legitimate.
> I would guess that in your hypothetical case the Program would be derivative
> work of the compiler. It seems like a FAQ I would search the net before
> asking here.
Of course it's a derivative of the compiler. But being as generous as I am,
I don't mind you making a derivative work of the compiler.
> > > > Let me put this another way. Suppose one day you think to yourself
> > > > "Hey, this whole DVD on Linux thing is pretty trendy, I think I'll add
> > > > *licensed* DVD support to Emacs! That'll be so cool!" So off you go and
> > > > get a key and a license and whatever else from Sata^H^H^H^Hthe MPAA,
> > > > and design some suitably funky decryption code that's utterly painful
> > > > to reverse engineer. Next, you code a little compiler that as well
> > > > as compiling your bitblitting stuff much better than gcc ever could,
> > > > adds your really funky decryption code in at the appropriate place. You
> > > > then get your emacs binary, and distribute it. Someone asks you for
> > > > the source, under GPL clause 3, and you give them everything but your
> > > > homespun-compiler thing, along with a little note "I'm not distributing
> > > > the add_dvd binary to you, since I don't want to and it's not a module
> > > > contained in emacs, nor an interface definition file, nor a script. So
> > > > nyeah."
> > > >
> > > > Do the Emacs authors have a right to a certain righteous wrath? Do they
> > > > have a legal leg to stand on? Is the GPL thus forever doomed?
> > I await your response.
> See mine above.
And that is `no, they don't have a legal leg to stand on' ?
So, basically, if someone wants to add something to a GPLed program,
and not release the source to it, they can just write a special compiler
for it, and claim it's not part of the `complete source'? And add a note
saying `if you want my special compiler, send me $1000. if you want the
source, $50000'?
So this is what we should tell the people who're writing enhancements to
the linux kernel and don't want to release source?
And you /really/ think this'll stand up in court happily?
You /really/ think that Debian shouldn't have any qualms at all about
blithely supporting an analogous situation? (Although with orders of
magnitude better intentions on all parts)
> > > A lot of problems come up if you take the general view that anything
> > > linked is a derived work. In a sense everything is linked to the kernel,
> > > since it jumps into and out of executing code; same can be said for the
> > > loader, which makes the initial jump into each programs "main()". So if
> > > you think that by linking you become a derived work, you obviously end up
> > > in absurdity.
> > Of course, the GPL specifically excludes the kernel, and in any case, on
> > GNU/Linux (or GNU/Hurd) systems we can distribute the kernel under terms
> > 1 and 2 of the GPL anyway. Which doesn't strike me as particularly absurd.
> See the MS Windows dll example.
Which specifically grants you permission anyway.
> > > > Erm, you're really arguing that if you make a derived work, `foo', from
> > > > `bar', and `quux'; then whenever you distribute `foo', you'll find
> > > > `quux' accompanying it?
> Is this particular argument really important?
I've no idea. Andreas brought it up.
Cheers,
aj
--
Anthony Towns <aj@humbug.org.au> <http://azure.humbug.org.au/~aj/>
I don't speak for anyone save myself. GPG encrypted mail preferred.
``The thing is: trying to be too generic is EVIL. It's stupid, it
results in slower code, and it results in more bugs.''
-- Linus Torvalds
Attachment:
pgpN0pFKx8Fki.pgp
Description: PGP signature