Re: On interpreting licences (was: KDE not in Debian?)
On Sun, 13 Feb 2000, Anthony Towns wrote:
> > (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.
I'm not going to cite a case, but there is a precedent. If linking a Windows
program to an MS dll makes the program a derived work of the MS dll then all
3rd part application vendors on the MS platform are guilty of copyright
violation. (As they distribute those derived works without permission from
MS).
> 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.
Wrong. Microsoft are very choosy about which dlls they allow 3rd part
application developers to distribute. 3rd party MS windows developers can
only distribute a few MS dlls that MS chooses. There are dlls that MS allows
developers to link against but not to distribute.
But this argument wasn't about distribution it was about whether linking a
program to a library makes the program a derived work of the library. These
are seperate issues.
> > > > > 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.
Which portions of KDE were written when dynamic linking was not common.
If there are none then I don't think this is relevant. *But I could be wrong*.
> > > > > 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'' ?
Yes, because Qt is part of the complete source code, section 3 requires the
complete source code to be distributed under the terms of Sections 1 and 2
(of the GPL).
> 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?
You're almost there. distributing the complete source code under Sections 1
and 2 of the GPL does not magically change the definition of the Program.
> 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?
No section 3 requires the complete source code to be distributed, this
includes Qt. That's a pretty powerful condition, and section 3 has even more
conditions depending on whether the distributor elects to comply with 3 a, b
or c. (For instance 3 b requires supplying the source at no more than the
cost of physically performing source distribution).
> Or am I reading too much into a typo somewhere?
No you're just not reading the archives.
See http://lists.kde.org/?/=kde-licensing&m=94950776505266&w=2
> 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.
I disagree.
> 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.
I still disagree even when you repeat yourself.
> > See also the Xfree license issue. It's highly relevant.
>
> There is no `Xfree license issue'.
See http://lists.kde.org/?/=kde-licensing&m=94950776505271&w=2
> 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
To paraphrase AP:
The Xfree license says "any person" can deal with the Software "without
restriction". This is incompatible with the GPL, under your reading of the
GPL, since the GPL does add restrictions to the X code.
Read the Xfree license.
>
> (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.
<offtopic stuff that doesn't belong on kde-licensing cut>
<even more stuff cut>
BFN,
Don.
Reply to: