Response to Troll Tech on Qt, KDE, and the QPL
 by J. J. Ramsey, in Editorials - Sat, Jul 15th 2000 23:59 UTC

This editorial by James Ramsey "attempts to counter Troll Tech's apparent misconceptions about the QPL/GPL controversy, and attempts to walk through the GPL to explain why it conflicts with the QPL."

QPL 2.0 is coming. In my opinion, this is a great development that will hopefully end this whole messy controversy with the QPL and the GPL. Why, then, am I even bothering to write this?

There are two reasons. First, I've being following the QPL/GPL controversy for a while, trying to sort out what exactly is going on. It has taken me some time to sift through all the discussion and the flames, and one thing I've noticed is that there hasn't been a point-by-point explanation of why the QPL and GPL supposedly conflict. Second, I think Troll Tech only halfway understands why the QPL and GPL supposedly conflict, and if it doesn't fully understand the reasons for the conflict, it may only turn the QPL from one possibly GPL-incompatible license to another. The editorial that Eirik Eng from Troll Tech posted, in my opinion, seemed to indicate a very partial understanding on Troll Tech's part. While I agree with its conclusions that the "patch clause" and clause 6c of the QPL should be nixed, I found that it did a poor job of rebutting the arguments claiming that the QPL and GPL conflict. It seemed to me that Eirik Eng, at least, was rebutting some of the noise surrounding the QPL/GPL controversy, rather than dealing with the crux of the controversy itself. Therefore, I'm going to go out on a limb and try to detail the argument of why the QPL and GPL conflict, based on what I've observed from the various discussions, flamewars, etc.

Troll Tech's Objections

Here are the objections Eirik Eng came up with to rebut the claims that the QPL and GPL conflict:

"It all comes down to how the terms 'Program' and 'Derivative Work' under copyright law are to be interpreted in the GPL.

For the 'Program' case, it has been claimed that when a program uses the Qt API, Qt becomes a part of that program. We, and lawyers we have consulted, cannot see how this can be the case. And if it is, which version of Qt? Windows, X11, or Qt/Embedded? All? Does this also apply to other things? Does the X server become a part of a program that uses X? Does the Qt/Embedded server become a part of a program that uses Qt/Embedded?

When we first released Qt there was already de-facto acceptance in the community that one could make GPLed programs using Motif, even before Lesstiff [sic] came along. Motif was a proprietary and non-free library with a much stricter license than Qt.

Now, for the 'Derivative work' case, it has been claimed that a program using Qt is a derivative work of Qt, or vice versa. Since it is programs that use Qt that use the GPL, only the latter case is relevant in license discussions. The GPL only talks about programs that are derivative works of the GPLed program, not the other way around. Some people have seriously claimed that Qt is a derivative work of KDE. Quite frankly, we found such a notion to be ridiculous, Qt existed long before KDE came along."

I will thoroughly agree that the "Derivative work" case is ridiculous. It also does not correspond to anything seriously argued by Debian. The argument to the "Program" case is actually somewhat closer to what Debian seems to be arguing. However, the problem is not with the meaning of "Program" in the GPL, but rather appears to be with the meanings of the terms "source code" and "module" in the GPL.

What follows is my attempt to sort what I've read on the mailing lists of Debian and kde-licensing into some semblance of a coherent point-by-point explanation of Debian's objection to linking QPLed and GPLed software.

The Argument for the GPL and QPL Conflicting

I'll start with the first part of Section 3 of the GPL:

--begin quote--

3. You may copy and distribute the Program (or a work based on it, under Section 2) in object code or executable form under the terms of Sections 1 and 2 above provided that you also do one of the following:
   1. Accompany it with the complete corresponding machine-readable source code, which must be distributed under the terms of Sections 1 and 2 above on a medium customarily used for software interchange; or,
   2. Accompany it with a written offer, valid for at least three years, to give any third party, for a charge no more than your cost of physically performing source distribution, a complete machine-readable copy of the corresponding source code, to be distributed under the terms of Sections 1 and 2 above on a medium customarily used for software interchange; or,
   3. Accompany it with the information you received as to the offer to distribute corresponding source code. (This alternative is allowed only for noncommercial distribution and only if you received the program in object code or executable form with such an offer, in accord with Subsection b above.)

--end quote--

Note that, in subsections 3a and 3b, the source code must be distributed under Sections 1 and 2 of the GPL. Even in subsection 3c, the source code would have had to have been distributed under Sections 1 and 2 of the GPL, since the recipient of the code would have obtained it from someone who distributed it under subsection 3b, which requires the source code to be distributed under Sections 1 and 2.

Section 1 of the GPL is fairly innocuous. In short, what it says is that one may copy and distribute the source code verbatim so long as all the copyright notices and notices referring to the GPL are left intact. The clincher is in Section 2, which states

--begin quote--

2. You may modify your copy or copies of the Program or any portion of it, thus forming a work based on the Program, and copy and distribute such modifications or work under the terms of Section 1 above, provided that you also meet all of these conditions:
   1. You must cause the modified files to carry prominent notices stating that you changed the files and the date of any change.
   2. You must cause any work that you distribute or publish, that in whole or in part contains or is derived from the Program or any part thereof, to be licensed as a whole at no charge to all third parties under the terms of this License.
   3. If the modified program normally reads commands interactively when run, you must cause it, when started running for such interactive use in the most ordinary way, to print or display an announcement including an appropriate copyright notice and a notice that there is no warranty (or else, saying that you provide a warranty) and that users may redistribute the program under these conditions, and telling the user how to view a copy of this License. (Exception: if the Program itself is interactive but does not normally print such an announcement, your work based on the Program is not required to print an announcement.)

--end quote--

The significant part is subsection 2b. In order to be able to modify the source code, one must be able to license the source code as a whole under the terms of the GPL. This means that the various parts of the source code must have licenses that either 1) allow relicensing under the GPL or 2) have no restrictions above and beyond what the GPL requires, so that the conjunction of the terms of the GPL and the terms of the licenses of the various parts of the GPL is the GPL itself. (Think of the term "conjunction" in a mathematical sense. The conjunction of the sets {1, 2, 3} and {1, 2, 3, 4, 5, 6} is {1, 2, 3, 4, 5, 6}.)

So why would this effect the QPL? If a QPLed work is considered to be part of the "source code" to the work, then for subsection 2b to be satisfied, the QPL would have to 1) allow relicensing under the GPL or 2) have no restrictions above and beyond what the GPL requires. Now the big question is, would the source code to a QPLed library, such as Qt, linked to a GPLed work, be considered to be part of the source code of the GPLed work? This is the crux of the controversy.

Here is the part of the GPL that defines what the "source code" to a work is.

--begin quote--

The source code for a work means the preferred form of the work for making modifications to it. For an executable work, complete source code means all the source code for all modules it contains, plus any associated interface definition files, plus the scripts used to control compilation and installation of the executable. However, as a special exception, the source code distributed need not include anything that is normally distributed (in either source or binary form) with the major components (compiler, kernel, and so on) of the operating system on which the executable runs, unless that component itself accompanies the executable.

--end quote--

Is a QPLed library a "module" of whatever binary links to it? I could argue that a library is an off-the-shelf piece of software to be used as a component of other software, and when it is used as such, it becomes a part of that other software, or a module of that software. I'll leave it at that for now. If the QPLed library is considered a module of the software, then unless said QPLed library is normally distributed with the operating system that the executable is supposed to run on, the source code for the library has to be distributable under Sections 1 and 2 of the GPL.

Does the "special exception" apply? The special exception states that "the source code distributed need not include anything that is normally distributed (in either source or binary form) with the major components (compiler, kernel, and so on) of the operating system on which the executable runs, unless that component itself accompanies the executable." First off, is Qt "normally distributed with the operating system that the executable supposed to run on"? Many Linux distributions distribute Qt as part of the distribution. However, the main reason they do is so that KDE can run, and the exception for components applies "unless that component itself accompanies the executable" (emphasis mine). Well, Qt accompanies the GPLed KDE executable on the CD of many a Linux distribution, so the special exception doesn't apply.

Does the QPL allow software licensed under it to be relicensed under the GPL? No. Does the QPL have restrictions above what the GPL imposes? Yes. There are two that have been the most discussed. First, there's the so-called "patch clause," which requires that modifications must be made in a form that is separate from the Software, such as patches. Second, there is clause 6c, which says that "If the items are not available to the general public, and the initial developer of the Software requests a copy of the items, then you must supply one." (Note that "the Software" refers to Qt, or whatever is the QPLed software "the items" depend on.) Since there are restrictions that the QPL has that are above and beyond what the GPL requires, the source code as a whole cannot be licensed as a whole under the GPL, and so section 2b of the GPL cannot be satisfied. Thus, if a QPLed library is linked to by a GPLed work, and the QPLed library is considered to be a "module" of the GPLed work, then the GPL and QPL come into conflict.

The Core Issue of the Argument: "What is a module?"

The "source code" for an executable work includes all modules that the executable work contains. "Module" can mean a lot of things, and it is not defined in the GPL itself. How do we figure out what "module" is supposed to mean?

The GPL is the brainchild of GNU, so it may be helpful to see how the GNU folks interpret their own terms. The pages of the GNU Web site offer some clues: Their page on what do to in case of violations to the GPL mentions that when checking the facts regarding a possible GPL violation, one should find the answer to the question "Is the available source code complete, or is it designed to for linking in other non-free modules?" The licenses page also refers to linking modules together. It appears from the reference to linking that "module" is almost another word for "library", with the main difference being that "module" is perhaps a bit more general. Further, in the page where RMS argues against using the LGPL for new GNU libraries, he says, "If we amass a collection of powerful GPL-covered libraries that have no parallel available to proprietary software, they will provide a range of useful modules to serve as building blocks in new free programs." Here the terms "module" and the term "library" are used almost as synonyms. Clearly, the people behind GNU, the authors of the GPL, consider libraries to be "modules."

It would be wise, though, in the next version of the GPL, to more carefully define "module" rather than rely on the intent of the GPL's authors.

Response to Troll Tech and Its Objections

Troll Tech is partly right when they say that "it has been claimed that when a program uses the Qt API, Qt becomes a part of that program." The issue is whether the Qt library is considered a module of a Qt-based executable work. Where Troll Tech misses the point is in the phrase "when a program uses the Qt API." The issue hinges on what is going on with the binary, the executable work, and whether the libraries the executable work links to are considered "modules", not per se whether the program is written using the Qt API (although a program must use the Qt API to link to Qt). The answer to the question of "which version of Qt? Windows, X11, or Qt/Embedded? All?" is quite simply "Whatever Qt binary the executable work actually links to." As for the question "Does this also apply to other things? Does the X server become a part of a program that uses X?", the answer may very well be "No, but libX11 does become a module of the program." The intention of GNU seems to be to try to prevent GPLed software from depending on anything less free than the GPL.

Eirik Eng also mentioned "de-facto acceptance in the community that one could make GPLed programs using Motif, even before Lesstiff [sic] came along". However, Motif, at least on proprietary Unix, certainly falls under the special exception that "the source code distributed need not include anything that is normally distributed (in either source or binary form) with the major components (compiler, kernel, and so on) of the operating system on which the executable runs, unless that component itself accompanies the executable." Motif is most certainly standard equipment on proprietary Unix; its whole reason for existence is to be the standard GUI on Unix. Further, Motif is not distributed along with any GPLed software based on Motif. Binary distributions of Motif-based GPLed software for Linux, though, may be problematical, since Motif is not normally distributed with most Linux-based distributions, and it would be considered a "module" of said GPLed software. In any case, "de facto acceptance" of a practice does not prove that practice is correct, only that it is commonplace.

That said, Troll Tech is on the right track so far with its plans for QPL 2.0. Removing the "patch clause" and clause 6c of the QPL is a good start. However, if Troll Tech does not know why they are doing what they are doing, it may either not go far enough or may introduce new problems with their next version of the QPL.

J. J. Ramsey <jjramsey_6x9eq42@yahoo.com> is a contract program student at Pacific Christian College taking courses toward a Mechanical Engineering major at California State University Fullerton. As is almost needless to say, he is not a lawyer.

T-Shirts and Fame!

[Comments are disabled]

Referenced categories License License :: OSI Approved :: GNU General Public License (GPL) License :: OSI Approved :: Q Public License (QPL) Topic :: Desktop Environment :: K Desktop Environment (KDE)

Referenced projects KDE - A powerful graphical desktop environment for Unix workstations. Qt - A cross-platform development framework/toolkit.

 Comments

[»] GPL vs. QPL vs. xPL
by Black Adder - Jul 24th 2000 17:54:56

Can't we all just get along? :)

[reply] [top]

[»] Note from Richard Stallman
by jeff covey - Jul 20th 2000 21:39:43

Mr. Stallman asked me to post this comment for him:

"I appreciated your clear article explaining why the QPL and the GPL do conflict. I would like to correct one small point in the article, with the effect of making the argument stronger. You pose this question:

First off, is Qt "normally distributed with the operating system that the executable supposed to run on"?

But that is not quite the right question, because the words of the GPL are slightly different:

...normally distributed (in either source or binary form) with the major components (compiler, kernel, and so on) of the operating system...

Some distributions of the GNU/Linux operating system do include Qt, but that is not what these words are concerned with. They are concerned with whether Qt is normally distributed with one of the system's major components.

Qt is not normally distributed with the compiler, GCC, or with the kernel, Linux, or with the window system, XFree86, or with any other major component of the GNU/Linux system. So Qt does not qualify for this exception.

I hope that Troll Tech will make the QPL compatible with the GPL, and removing the patch requirement is a big step in that direction, but it is not entirely enough. We've had some discussions about this, on and off, and I hope that eventually the QPL can become compatible with the GPL, but we can't be sure what the future will bring."

--
vs lbh pna ernq guvf, lbh'er n trrx.

[reply] [top]

[»] Linking is non-issue
by Tero Pulkkinen - Jul 19th 2000 19:03:50

It does not matter how the different pieces of code were separated from each other -- Only how large groups of code they're distributed in.

To enable communication between software modules, there's 3 entities involved. 2 entities being the receiver and sender of the communication and there's 3rd entity being the mechanism that enables communication.

Similarly with licenses, you can divide software modules to 3 pieces:
A) Code that is under GPL
B) Code that is not under GPL and does not allow to be converted to GPL
C) Code that enables communication between GPL and non-GPL.

If you distribute all 3 pieces in one package, there is good chance you're
distributing GPL and non-GPL code "as whole".

GPL's nicest feature is that it forces users to make explicit choice to
mix GPL'd and non-GPL'd code! Users will be forced to download C separately! (even if A and B were distributed togeather) This is why combination of qt and kde might not be compatible with GPL preventing kde's distribution! Users do not need to make explicit choice to download qt - there are many places where you can get the whole kde - qt included... (Unfortunately A and C are combined in kde -> the only ways to distribute kde/qt is by AC|B or ABC... And when distributing ABC, one must be much more careful with reading license terms of GPL and B...) Thus it is risky to include them to same media!

You can always distribute code A and code B in same package -- but only if you do NOT distribute code C!

[reply] [top]

[»] Re: "What is a module?"
by J. J. Ramsey - Jul 16th 2000 19:17:07

"Well, it is completely obvious to me that a dynamically-linked library is not "contained" in the executable work."

You are presuming that "contains" necessarily means a spatial proximity, that the bits of the modules of the executable work have to be physically near each other.

"In any event, if in fact the library did have to be licensed under the GPL, one could not link against libc, for example."

You forget the "special exception." On just about any Unix-like system, libc "is normally distributed (in either source or binary
form) with the major components (compiler, kernel, and so on) of the
operating system" so the special exeception applies, whether libc is LGPL'd or proprietary.

"The fact that non-lawyers are doing the debating leads to one of the most common mis-interpretations of legal language, repeated by Jeff: he states that "to be licensed as a whole at no charge to all third parties under the terms of [the GPL]" means "under terms no more restrictive" than the GPL. This interpretation is totally implausible."

One, "to be licensed as a whole at no charge to all third parties under the terms of [the GPL]" means that the *individual pieces* can be licensed under terms no more restrictive that the GPL. When the terms of the licenses of the individual pieces get conjuncted with the GPL itself, the result is effectively the GPL itself. This hardly seems "totally implausible."

[reply] [top]

[»] Re: Perspective
by J. J. Ramsey - Jul 16th 2000 18:06:12

"What is unstated in the GPL itself, but which is the stated goal by GPL advocates is the Zeroeth rule: to provide freedom for developers. "

I'm not so sure that's true. The GPL was meant to be anti-proprietary at nearly all costs. It is intended to make it almost impossible to encumber free software with anything proprietary. Remember who brought the GPL into being in the first place--Richard Stallman. This guy is not exactly known for compromise, and he considers proprietary software to be evil. I'm sure that if you were to ask him, freedom for developers would *not* include the freedom to link to an arbitrary library, dynamically or otherwise, since that would open up a loophole in the GPL that could be used to infringe upon the users' "rights" to copy, modify, and redistribute the software.

For example, say a vendor modifies a GPL'd application so that a sufficiently significant portion of its functionality now comes from libraries that the vendor wrote *from scratch*, and that the vendor makes these libraries proprietary, so that the application, though technically GPL'd, is effectively encumbered by the proprietary license of the vendor's libraries. This is the sort of loophole that would occur if linking to arbitrary libraries were allowed.

The GPL is, in a sense, a paranoid license that tries to block all possible ways of encumbering free software with proprietary restrictions, even at the cost of frustrating developers.

[reply] [top]

[»] "What is a module?"
by DrDre - Jul 16th 2000 17:32:17

It seems that Jeff's long section on "what is a module" misses a rather obvious point. As he quotes, the GPL defines source code as follow:

"For an executable work, complete source code means all the source code for all modules it contains,"

Well, it is completely obvious to me that a dynamically-linked library is not "contained" in the executable work. Hence the "source code" does not cover the dynamically-linked library source code.
In any event, if in fact the library did have to be licensed under the GPL, one could not link against libc, for example. Ahh, but someone will say, libc can be re-licensed under the GPL. But, AFAIK, this is never done, whether by Debian or others. The LGPL specifies a specific set of crieteria that must be followed to accomplish this relicensing, which nobody follows. And the re-licensing is a one-way street: once licensed under the GPL, libc would no longer be under the LGPL. Thus, to permit proprietary software on such a system (or, under the strict reading, to permit any non-GPL'd app to link against the library), one would need to distribute 2 copies of libc, and somehow be able to control which libc a program links to, depending on the program is licensed under the GPL. Nobody AFAIK does this.

Then someone will say, who cares, this is only a technical issue. It is possible to do this, it just takes some more work.

To this I say: it is also possible, though it takes some technical work, to distribute KDE/Qt under even the most restrictive GPL reading. One only has to not compile the KDE programs when doing the distribution -- just distribute the source code to the KDE programs (in which case Section 3 does not apply) and have the install program compile the KDE programs "on the fly" (in fact, one can make good arguments even under the strictest GPL reading that the distributor could go all the way to creating all the .o files for KDE, as these are not in any way linked to Qt, which then only have to be linked at install time). Yes, this is somewhat inconvenient, but not much more inconvenient than having two libc's and having each program link to the correct one. It is possible.

There are many more issues I could raise, and at other times have raised on the kde-licensing mailing lists. I will not rehash them here.

But one thing I can say is: it's pointless for non-lawyers to debate endlessly the meaning of the GPL. The fact that non-lawyers are doing the debating leads to one of the most common mis-interpretations of legal language, repeated by Jeff: he states that "to be licensed as a whole at no charge to all third parties under the terms of [the GPL]" means "under terms no more restrictive" than the GPL. This interpretation is totally implausible. Either the language means that the entire program (including all modules) must be licensed under the GPL -- which would pose huge problems for programs which are BSD or X licensed (and for this practical reason even the Debian folks don't seriously push this reading) -- or it means, as I have analyzed elsewhere, that only two requirements of the GPL apply to it: 1) that the source code be distributed, and 2) that the program be redistributable without charge.

[reply] [top]

[»] A modest proposal...
by Stormbringer - Jul 16th 2000 16:00:38

Will the lawyers for TrollTech PLEASE establish communications with the lawyers for FSF (and Lineo too, if need be) to get these interpretations resolved and merged into the license tree? Apparently they're the critical nodes in a by-now very destructive discrepancy.
Everybody involved here is trying to do what's right, but only a few have the required write-access to the source (contract legalese) to be able to resolve the contention. Those people have to merge their diffs.

[reply] [top]

[»] GPL, QPL, WhateverL
by H. Aurag - Jul 16th 2000 15:59:47

I am really tired of this thing. Everybody has the right to use ANY license they like to distribute their stuff.

You want GPL, QPL, MyL, YourL or maybe MSPL (a hypothetical Microsoft Public License)? Great do it. I don't have to buy it, download or install it.

I have listened at length to GPL defenders of the truth. Truth to tell, their world is not free. The real free world is one where people have choice between all those different licenses .... And let people choose.

The greatest benefit of simultaneous existence of GPL, QPL, BSD, Python, MyL ... Microsoft Eula other Eula's is the fact that it gives people choice. As much as I hate having a MS Eula only world, I'd also not appreciate GPL only world.

It makes sense to go with GPL for some things, with LGPL for libraries or even BSD in this case, with completely closed EULA's with stuff like Quake III or UT (after all these guys live off licensing the source to their engines more than by selling games).

My problem however is when people try to turn this into a moral issue! This is insane.

Saying that GPL is certainly better than MS EULA's is of course normal. Saying GPL is The Good, MS EULA's THE Bad, QPL The Ugly and BSD The Bastard, and turn it into some sect like thing means one thing to me. You need to go see a doctor.

I can't believe there are people who'd actually refuse to legally redistribute software because it's QPL.

But again, they are free to do so. So if you find Debian people to be insane about that, please go get something else that suits you more. Heck I don't care if you even buy Windows 98, or Millenium.

It's each one's choice, period. And no one is ever going to tell me what I should do or not. THIS IS FREEDOM.

[reply] [top]

[»] Confusing the means with the end
by Richard Moore - Jul 16th 2000 15:57:40

I think a lot of this debate comes down to people confusing the aim of the GPL with the text of the license itself. A lot of the arguments have been very dogmatic, with people making out the GPL is the 'one true license'. The QPL has very similar aims, but tries to achieve them through different means. For example the 'What if Troll Tech got bought out' argument has been used time and again, but this is solved by the Free Qt Foundation. Just because something isn't GPL doesn't necessarily make it any less free or useful as some would like to think.

[reply] [top]

[»] there's a need of realism
by Raphaël Bauduin - Jul 16th 2000 14:46:29

I see GPL extremism as a danger for the future of free software. I don't mean there's no problems with the QPL, but I sometimes feel GPL integrists denigrate other licence wihtout real reasons. I'm from Belgium and we are used to compromis over here. I think you never can get exactly what you want, unless you're asocial, egoist and stupid. Don't forget your freedom stops where the other one's begins. I don't want to loose time discussing this license problem, because I don't have the background. I just hope the FSF will put its time where it's the most important. Fighting software patents in Europe e.g...... We don't hear a lot about that from the FSF by the way..... I'm not a great coder, neither a big free software contributor, but I try to be active in the community and I think spending time on serious and immediate threats to free software is much more important(cf freepatents ) I heard some people prefer Hurd over Linux because Hurd is coming from GNU. If we begin thinking like that, free software is lost. Remember that a lot of free software users chose it over commercial software for pragmatic and philosophical reasons. This should still be the case I think. And we shouldn't loose time on little details that aren't worth it......

[reply] [top]

[»] Perspective
by Sean Russell - Jul 16th 2000 13:46:46

Caveat: I'm Just A User

It seems to me that the intent of the GPL is to provide for three forms of protection:

1. Protection for programmers, so that they can create and distribute software, without the fear that a third party will benefit from the original programmer's work without due compensation. Basically, to stop leaches and opportunists.
2. Protection for software, so that "modules" on which the software depends can not be arbitrarily withdrawn. This provides a sort of insurance against blackmail.
3. Protection for users, so that by providing access to the sourcecode, software has a life beyond that of the author.

Perhaps I'm missing something in the GPL, but these seem to be the issues the GPL is trying to get at in its (typical for legal documents) convoluted way. What is unstated in the GPL itself, but which is the stated goal by GPL advocates is the Zeroeth rule: to provide freedom for developers.

To me, these are two seperate "domains" of issues. The first point is a sort of moral protection; few people want others to benefit from their hard work without some form of compensation. The second two are practical issues, dealing more with protecting people from blackmail of the sort Unisys employed with the LZW patent, and from the "disappearing author" scenario: where do you go if you depend on a piece of software and the author is killed in a motorcycle accident, and you don't have access to the source?

I don't know how the QPL addresses any of these issues, although I think that if it provided the same three basic forms of protection, the FSF's position against it would be fatally weakened. The letter of the law is important for resolving disputes, but the *intent* of the law is what is most important in the grand scheme of things. If the letter of the law does not provide for the intent of the law, then the letter is flawed -- not vice-versa.

If the GPL, as it appears to my lay perception, restricts a product from *dynamically* linking to an arbitrary library, then the GPL is flawed, because it undermines the zeroeth goal. The GPL *must* restrict dynamically linking to a non-GPL'ed library to protect software from cases (2) and (3), and this is where I have trouble with the GPL -- who is being restricted? Not the proprietary library, but the software developer who wants to use the library.

(2) and (3) are important, but it is my belief that the way they are represented in the GPL makes the GPL overly restrictive, which violates the Prime Directive: freedom for programmers.

--

[reply] [top]

[»] Re: Re: Re: Re: Re: Re: Response by ....
by Matthias Ettrich - Jul 16th 2000 12:36:17

"hmm, definitely interesting. Even if the GPL were "fixed", though, it might not be a wise idea to release Qt Free Edition under the GPL. For one thing, this would likely mean that the only free software that could link to Qt would be software licensed under the GPL, since the GPL would most likely still be "viral". This would shut out the possibility of BSD-licensed software linking to Qt, or even LGPL'd software, which would throw another monkey wrench into KDE's licensing, since the libs of KDE are LGPL'd so that proprietary software developers could use them. "

The solution to that is an extended QPL that has one additional paragraph. Something along the lines of "if you want to, you can relicense the code under the terms of the GPL V3".

Ok, that's it for me. For further questions, don't hesitate to send me an email, Jeff.

btw: you were right with the typo, I meant "GPL" not "QPL". No such typo in this comment, though.

[reply] [top]

[»] Re: Re: Re: Re: Response by ....
by Jörg Rathlev - Jul 16th 2000 12:09:40

"It only sounds like it? That was what I was saying. And not only me. Did you look at the Lineo webpage I was referring to?"

I've just read the Lineo web page. I especially liked the following: "a program which uses a library is generally not a derivative work of that library". I don't think this is right. You probably know the LGPL. The main point in which it differs from the GPL is that you may include code from header files within your program without any restrictions.

I don't think that a program which uses a library is a derivative work of the whole library - even if the GPL somewhat implies this, it's simply ridicolous. The program is however clearly a derivative work of the library's header files. It makes use of the types, classes etc. defined in the header files.

If you'd write a complex class hierarchy (no implementation) and someone copied it, would you call this copyright infringement? If the answer is yes (and I guess it will be), you may not copy (or use) it without a license from the copyright holder. If that license happens to conflict with the GPL, well, that's your problem, you can't use the GPL. If that license happens to be the GPL, that's your problem, your program has to be GPLed as well.

What you're saying is basically that copyright law does not apply to header files. This is ridiculous, and it doesn't become less ridiculous because Lineo is saying it, too.

Besides, if you insist on that position, may I please use Qt Free Edition to write proprietary software? If the program I write is not a derivative work of Qt, I don't need any license from TrollTech, do I?

[reply] [top]

[»] Re: That's eGNoUgh pompousness, thank you.
by J. J. Ramsey - Jul 16th 2000 11:10:04

"James Ramsey: You actually imply that Mattias made a typo with his use of "GPLed"? So, you (and other RMS disciples) think that all software should be "GPL'd" (GNU Public License'd)? Picky, picky, picky. This mentality seems to sum up the personae of the GPL zealots. It's not [sic] -- it's sick. "

Um, the reason that I added "[sic?]" to Mattias' quote was because he began the paragraph with "Imagine - just for a second - that Qt Free Edition was a GPLed library". Given that, it is not unreasonable to presume that in that paragraph that "QPL" was indeed a typo. Interesting that you presume that I'm a GPL zealot and an RMS disciple because I was trying to guess whether something was a typo.

[reply] [top]

[»] Re: The problem is GPL, not QPL
by J. J. Ramsey - Jul 16th 2000 10:32:18

"IANAL, but I seriously doubt the infection conditions in GPL will ever stand up in a court of law. I can GPL a program that uses a non-GPL library/module/code snippet/whatever and thereby force the vendor to give the world the source and to give up all future compensation for their work?"

No, you wouldn't force the vendor to do anything. You'd just simply make your *own* code undistributable, at least under the FSF's interpretation.

"If a programmer chooses to put their program under GPL, yet uses a non-GPL component, the GPL should not extend to that component, no matter whether the component is called a "module", "library", "standard OS piece" or "throat-warbler mangrove". "

The GPL wouldn't extend to that component anyway. The program would just be undistributable when compiled to use the non-GPL'd module.

The GPL is viral, but not the way that you described.

[reply] [top]

[»] Re: Re: Re: Re: Re: Response by ....
by J. J. Ramsey - Jul 16th 2000 10:16:51

>It sounds like what you are saying is that despite the FSF's
>protestations, a GPL'd library *can* be used to
>create proprietary works because all the module stuff the GPL refers to
>is nonsense.

"It only sounds like it? That was what I was saying."

Now we're getting somewhere. So Troll Tech thinks that the module stuff really is legal nonsense (at least as the FSF interprets it)? Whoa. If this is the case, then Troll Tech's laywers should definitely contact the FSF's lawyers and give their objections, presuming that they haven't already. This is fiery stuff.

>I'm not sure, but it sounds like what you are saying is that Troll Tech
>would be willing to relicense Qt under the GPL, if it was clear that the
>GPL would actually prevent the Qt Free Edition from being used for
>proprietary software. Am I getting closer or more and more off base?

"No, you are getting closer."

Hmm, definitely interesting. Even if the GPL were "fixed", though, it might not be a wise idea to release Qt Free Edition under the GPL. For one thing, this would likely mean that the only free software that could link to Qt would be software licensed under the GPL, since the GPL would most likely still be "viral". This would shut out the possibility of BSD-licensed software linking to Qt, or even LGPL'd software, which would throw another monkey wrench into KDE's licensing, since the libs of KDE are LGPL'd so that proprietary software developers could use them.

"You just repeated what Eirik Eng wrote in his Freshmeat editorial and what I tried to explain twice today."

Yeah, so I'm slow. ;-)

[reply] [top]

[»] Re: Not Again - Matthias
by John Califf - Jul 16th 2000 04:25:16

Thanks for the clarification. The distinction between free beer and free speech was not clear to me in the QPL after several readings. Maybe it should be made clear there.
QPL only refers to use for "free" software.

I don't think many other developers who are not close to the scene understand that in this sense the QPL is like GPL either, becasue it is not explicitly spelled out. Any misunderstanding on this will cost you, in terms of losing developers, who may think that Qt can't be used for "commercial" projects even when source is provided with the Free Edition and that they must purchase a license.

Regarding my other point, I fail to see the arguments of those claiming that Qt and Kde can't be part of a linux distro. These arguments seem far-fetched. Sometimes I can glimpse what they might be referring to, but then it all fades away into absurdity. Clearly, the work or module being linked to is not affected by linking, and neither is derivative of the other. If these arguments were vaild then a linux distro could include nothing but GPL'd works. Everything depends on everything else (can't ANY app cause linux to crash?). There are an extremely large number of possible combinations and permutations of dependency, and one could argue that every node on a network is dependent on every other just as well. But being interdependent is not being a derivative. Compartmentalize when it is convenient for an argument and generalize when it is inconvenient. I wish those making such accusations would think a little about why they are doing so and be more up front about their motivations.

I am glad to see you responding, as you represent both Qt and Kde to many people, unofficially. A point by point explanation of exactly what the problem might be with the QPL license was asked for, and now that it has been laid out the whole objection seems very weak. I think the issue is dying down - people are tired of being forced to take sides. At the same time the need for changes in both the QPL and GPL have been acknowledged by parties on both sides, and changes can occur sooner if the parties can do so without appearing to be pressured into making changes.

The dispute is certainly not over, but I am now convinced that it will lead to good results. The biggest hurdle was the appearance that Troll Tech would never respond to the accusations or explain its position on open source in a personal way, like parties on the other side have done. Now that Erik Eng has done that you are finding far more positive posts than negative one at Slashdot and other forums regarded to be hostile or suspicious in the past. Also, Kde developers who may have something to contribute to public forums (I know they are busy) should not hesitate to do so on topics or stories that interest them, not necessarily this dispute. That could break down even more barriers.

[reply] [top]

[»] The exception of OS modules
by structure - Jul 16th 2000 02:49:16

I'll express a thought about the following paragraph from the article:

"Does the "special exception" apply? The special exception states that "the source code distributed need not include anything that is normally distributed (in either source or binary form) with the major components (compiler, kernel, and so on) of the operating system on which the executable runs, unless that component itself accompanies the executable." First off, is Qt "normally distributed with the operating system that the executable supposed to run on"? Many Linux distributions distribute Qt as part of the distribution. However, the main reason they do is so that KDE can run, and the exception for components applies "unless that component itself accompanies the executable" (emphasis mine). Well, Qt accompanies the GPLed KDE executable on the CD of many a Linux distribution, so the special exception doesn't apply."

It was said that "the main reason they [include QT libraries] is. . ." and this is understandable wording. It is hard, if not impossible, to assume that KDE as a desktop environment is the only possible motivation for including QT in the OS. Perhaps other apps or utilities included in the OS use QT; perhaps it is included so that potential programs will have it to use. In either case, the article continues on as if KDE is the only reason for the inclusion for QT. For the last sentence doesn't say, "the special exception doesn't apply in the case of KDE per se, at least." It is said not to apply, period. So that does not seem well proven.

As far as I can tell, the looseness of the term Operating System in this setting, and the resulting ability of a distribution creator and user(s) to define what necessary or unnecessary components are included therein makes it possible to satisfy the exception in the GNU license.

Your thoughts?

[reply] [top]

[»] A copyright can only apply to the work of the author
by Troy Roberts - Jul 16th 2000 02:01:38

These arguements are purely wrong. You have not consluted a lawyer and it shows. GPL can only be applied to source code that is in fact under the GPL. It does so, because the author of said program copyrighted the program under the GPL. Troll Tech has not licensed their work under the GPL. So, are not bound by the GPL. As an author of a deriviative work of a GPL program, I must license my work as GPL, but I can not impose any licensing on to another authors work.

Simply the question of what is a module is of no consequence, becuase the QT libs are not part of the copyrighted program.

[reply] [top]

[»] That's eGNoUgh pompousness, thank you.
by dino - Jul 16th 2000 01:53:00

Most of us are tired of this license shit. Unfortunately, some people thrive on conflict and finger-pointing. Forget baseball, the national pastime in the USA is finding fault in others.

James Ramsey: You actually imply that Mattias made a typo with his use of "GPLed"? So, you (and other RMS disciples) think that all software should be "GPL'd" (GNU Public License'd)? Picky, picky, picky. This mentality seems to sum up the personae of the GPL zealots. It's not [sic] -- it's sick.

Like the Xemacs split, this GPL vs QPL dispute is a blackmark on the whole RMS/GNU/FSF/Debian cartel. Thank you all so much for your contributions and for making the Linux community possible -- but it's high-time for a compromise in the GPL. How hard can it be to meet TrollTech halfway? Principles are one thing, but there is nothing virtuous in being stubborn.

If a KDE app is free, linked to a GPLed library and all the source is made available by the developer(s) then please change the GPL in such a way that the KDE app can 'legally' be GPLed (or GPL'd if you prefer).

[reply] [top]

[»] The BSD License
by elleron - Jul 15th 2000 23:17:59

I'll agree that the BSD/MIT licenses are preferable to the GPL, but please don't use the BSD version with the ad clause. As the FSF has correctly pointed out, that's a real nightmare for people who distribute collections of software.

[reply] [top]

[»] Whats the point?
by Open Systems Inc. - Jul 15th 2000 22:56:59

You would think no one in their right mind would waste this much effort on such a complex, and viral license. Just release the thing under a BSDL and BE DONE WITH IT! I mean for crying out loud how long has this been an issue?! I have to wonder about a company who wastes this much time on a less free license IMO than the BSDL. Its their choice, but I mean just how long are they going to waste on this issue. *boggle*

[reply] [top]

[»] Re: GPL and libraries
by lordsutch - Jul 15th 2000 22:13:52

The FSF clearly intended that GPLed libraries would not be usable to make proprietary programs. That is why they created the LGPL originally-- to allow libraries to be used outside of the Free-Software environment. If lawyers claim that the language of the GPL does not make this apparent, then it is a serious flaw in the GPL, and the FSF needs to update the GPL to make that particular point clear.

And since the GPL was also written by lawyers, we have two sets of lawyers with differing interpretations of the law. It sounds like we need a court case to settle this, once and for all.

[reply] [top]

[»] GPL and libraries.
by Eugene Weiss - Jul 15th 2000 21:57:22

The FSF clearly intended that GPLed libraries would not be usable to make proprietary programs. That is why they created the LGPL originally-- to allow libraries to be used outside of the Free-Software environment. If lawyers claim that the language of the GPL does not make this apparent, then it is a serious flaw in the GPL, and the FSF needs to update the GPL to make that particular point clear.

[reply] [top]

[»] Is it all academic?
by dito - Jul 15th 2000 21:45:58

There's been lots of arguing about interpretations and meanings etc. but what does it all mean in practical terms? I'm not going to try and add to either side of the argument, I'm just curious about what will happen when one side or the other is proverd correct. As far as I can see, no matter who is right, we can continue to distribute these apps. There are 2/3 implications that I can see depending on who's arguments are correct:

1 - Mattias etc. is right and there is no conflict, in which case everyone can continue distributing KDE apps with no worries. This would probably be the most convenient result.

2 - Debian is right and there is a conflict in which case we have an interesting problem. There is no question about whether the QPL is valid as TT have not based their code on other people's work so they don't have a problem. The problem now is that hundreds of KDE apps were released with a license that is not valid. That is, the license contains terms that were broken by the author as soon as he declare the app to be GPLed and have been repeatedly broken by anyone who has since distributed it. I'm not sure where that leaves us in terms of contracts. I think (IANAL) that if a contract has an unenforcable term in it then that term becomes void but the rest of the contract remains in place. So we have 2 more possibilities:

2a - The KDE programs are still under the GPL but with several of the terms nullified in which case we can continue to distribute the apps as before just under a kind of weakened GPL.

2b - The whole license is invalidated (I'm pretty sure this isn't correct, but just in case...), in which case the apps were released without any license, does this make them public domain? I doubt it. Maybe it means that the authors are free to retrospectively choose a new license. In which case, assuming they still want to distribute their apps freely, they can (or must!) choose a license which will not conflict with the QPL. Either way the apps are once again free to use without any license worries.

To summarise:

1 - There is no conflict, keep doing what you're doing = happy days.
2a - There is a conflict, apps are forced into a weakened (less viral) version of the GPL = happy days (unless you're a big GPL fan, see below)
2b - There is a conflict, authors get to turn back time and release under a compatible license = happy days unless authors decide to be difficult. The only reason to believe this would happen is that section 7 of the GPL say that you may not release under the GPL unless you can satisfy it fully. If contract law works as in 2a then one could argue that section all of section 7 is invalid and never applied, including the bit about what happens if section 7 is invalidated (this is what you get when a lisp programmer write a license ;-). If not then the app was definitely never released under the GPL so I presume the original author can retroactively change the license to something which solves all problems.

Unless someone can explain why all of these 3 scenarios are incorrect and explain what the real situation is, the arguments as to whether the licenses conflict are academic. Whether they conflict or not, the software can be distributed safely. It was the original authors' faults for releasing the apps under contradictory licenses.

As an aside, there is reason to prefer that there is no conflict because, if 2a is the correct view then it may be possible to exploit the weakened GPL to use the source in a non-free way. If linking against proprietary libraries turns out to be OK then someone could write a library with their own proprietary extensions, keeping it closed source and then modify the original program to use this new proprietary library. In a way, they could turn the original code into a library and use all of it's features from their closed source code. Not a good result...

[reply] [top]

[»] Re: Re: Re: Re: Response by ....
by Matthias Ettrich - Jul 15th 2000 21:19:24

It sounds like what you are saying is that despite the FSF's protestations, a GPL'd library *can* be used to create proprietary works because all the module stuff the GPL refers to is nonsense.

It only sounds like it? That was what I was saying. And not only me. Did you look at the Lineo webpage I was referring to?

I'm not sure, but it sounds like what you are saying is that Troll Tech would be willing to relicense Qt under the GPL, if it was clear that the GPL would actually prevent the Qt Free Edition from being used for proprietary software. Am I getting closer or more and more off base?

No, you are getting closer. You just repeated what Eirik Eng wrote in his Freshmeat editorial and what I tried to explain twice today.

[reply] [top]

[»] RE: Not again
by Matthias Ettrich - Jul 15th 2000 21:09:20

"Free" in Qt Free Edition means free speech, not free beer. You don't have to write "charity ware", as you put it. As long as you GPL the code you are writing with Qt, you can sell it for all the money you get, without paying Trolltech a single cent.

The freedom part of it is that your customer can distribute your software freely, i.e. without paying you.

Actually GPL and QPL is exactly the same in this respect.

[reply] [top]

[»] Who chooses the licence?
by B!nej - Jul 15th 2000 21:03:57

Okay, you can solve this entire argument very easily. All you need to do is understand this:

The author chooses the licence for their own software. Not for anyone elses. The user does not get to choose a licence for the software produced by others. If you don't like someone else's choice, bad luck.

Okay, now what is the problem with this? Why do people think that QT must adopt the GPL?

People don't need to understand anything about the QPL, GPL or anything like it. The question is who did the work, and who has the right to determine how to distribute it. All you GPL puppies who think you can make this sort of demand from anyone should take a long hard look at what you think you're doing.

[reply] [top]

[»] Re: Re: Re: Response by a Troll ;-)
by J. J. Ramsey - Jul 15th 2000 20:50:18

"James, you keep mixing FSF or GPL terminology with legal terminology. Just assume for one second that not everything in the GPL is enforcable or does make sense and reread my answer to your editorial."

Ok, then. You wrote:

"As Eirik Eng pointed out in the statement on Freshmeat a few weeks ago, neither the GPL nor the LGPL legally protect libraries. There's no real legal basis for assuming that no proprietary software is written and distributed with a library under these licenses."

Let's see. The first sentence seems to say that the GPL is incapable of protecting libraries. (That would be consistent with presuming that not everything in the GPL is enforceable or makes sense.) The second sentence seems to make more sense if I replace "is" with "can be". How am I doing?

Now to wrangle with the rest of this. (Yikes!)

"Careful. A license like the GPL is purely based on copyright law. It can only put restrictions on copying the work or a derivative work. It may talk about modules and other things, but if those modules are legally independent, it's really just meaningless words."

AFAIK, copyright also controls distribution as well. The GPL can say that if a GPL'd executable work links to modules not under GPL-compatible terms, then the GPL'd work cannot be distributed. The GPL can't *change* the licenses of any modules, but it can control the terms of its own distribution, and simply say that one of the terms for the GPL'd work's distribution is that all modules that it links to must be under GPL-compatible terms, or else it can't be distributed at all. I don't know if that answers what you mean by "legally independent" or not. What do you mean by "legally independant" here?

"Imagine - just for a second - that Qt Free Edition was a GPLed library, ok? Now somebody writes a big proprietary application and starts selling and distributing it, without source code under a traditional commercial license. This application uses the QPLed [sic?] Qt Free Edition and they ship it together with the Qt Free Edition.

"Now the question is: Can they legally distribute their proprietary application or not? Debian and the FSF would say: they can't! Everybody else says "they can!." And why? Because the module stuff you were talking about seems to be legal nonsense. Now I'm not a lawyer and not at all an expert in international copyright law (and neither are you), but that's what we were told and what for example Lineo states on the mentioned web pages. "

It sounds like what you are saying is that despite the FSF's protestations, a GPL'd library *can* be used to create proprietary works because all the module stuff the GPL refers to is nonsense. Interesting, if I read you correctly.

"Can you see the problem now?"

I'm not sure. For one thing, this "modules" stuff may not be all that nonsensical, because the GPL is not attempting to alter the licenses of third-party stuff. Not to mention that the FSF has its own lawyers who have looked over this "modules" stuff, so it may be the opinion of Troll Tech's lawyers versus the opinion of the FSF's lawyers.

"Trolltech would like to end the arguing with the free software community by making it possible to relicense Qt under the terms of the GPL if the GPL really worked for libraries. What we need is a GPL V3 that fixes the bugs."

I'm not sure, but it sounds like what you are saying is that Troll Tech would be willing to relicense Qt under the GPL, if it was clear that the GPL would actually prevent the Qt Free Edition from being used for proprietary software. Am I getting closer or more and more off base?

[reply] [top]

[»] Re: Linking and licences
by J. J. Ramsey - Jul 15th 2000 19:48:38

"The source code for a work means the preferred form of the work for making modifications to it. For an executable work, complete source code means all the source code for all modules it contains, . . ."

"Reading this, it seems to me that if I write a program dynamically linked to the Qt libs, and distribute the source code without including the Qt libs, I can put my work under the GPL without conflict."

No, it means that the source code for the executable work *includes* the source code for the "all the modules it [the executable] work contains." If the source code for "all the modules" it contains cannot be made available under GPL-compatible terms, that is a GPL violation. Distributing the source code without the Qt libs won't help you, and dynamic linking makes no difference.

[reply] [top]

[»] Not again!
by John Califf - Jul 15th 2000 19:33:02

There are two different issues involved here. The first is the legality of including Qt in Linux distributions along with GPL works which link to them like Kde. The second issue is the wisdom of using Qt as a development environment.

Regarding the first issuse, I completely agree with Erick Eng and Matthias Ettrich and most Linux distros that there is no problem for free software like Kde. It is a very serious matter to call an activity "illegal" and such allegations usually result in some kind of lawsuit. But, in this case plaintiffs would probably get laughed out of court. If Debian doesn't want to include Kde and Qt let them go their own way, but to call an activity illegal without folowing through is like pointing a gun at someone. Don't do that unless you intend to shoot to kill. Such accusations may inspire others with less than charitable motivations to try use the issue to really damage open source.

The second issue is more complex, and while I have personally decided not to use Qt in my projects I have no problems with others doing so. It seems that one can't fork Qt even with the professional license and this lack of control over its development is not my style, especially for such an important class library. Not that I am ever likely to want to do that, but I would like to know that I can if I want to. Also, it appears that the Qt Free Edition is only for "free" projects even if source code is provided - you can't charge for it. Maybe I misunderstand that but I do not want to write charity ware. I want to write open source software which I can charge for if I want to and which others can charge for or not as they please, and use in their own projects, commercial or free, with the Free Qt license. Basically, I want no restrictions on use without paying a $1500+ license fee. There are no restrictions of this kind with several other toolkits and class libraries for unix guis. GPL explicitly forbids restrictions on use so that may be more my style.

I am very tired of this continual attack on Qt and Kde over licensing issues. It doesn't make the GNU organization look very good. Recently I have expressed some concerns to some parties involved in private email. Maybe that was not a good idea, but this may have helped someone much to my embarrassment. If it has not helped I apologize.

The relationship between Qt and other toolkits is a dynamic and positive one. Qt is very good and has inspired others to develop and improve their toolkits under the GPL license. In turn, the competition has spurred Troll Tech to modify its licensing and I regard the current licensing to be far from final. It will evolve, because Troll Tech is not stupid and wants to keep developers. GPL may also evolve and needs to get past the amoeba stage as well.

But please, enough of these allegations of "illegality". All this does is to hurt open source and hurt Linux and other free unixes. Most Linux distros and the BSD's will continue to include Qt and Kde. That is good. They also include Gnome and other desktops for those who want something different.

[reply] [top]

[»] Re: Re: Response by a Troll ;-)
by Matthias Ettrich - Jul 15th 2000 17:56:08

James, you keep mixing FSF or GPL terminology with legal terminology. Just assume for one second that not everything in the GPL is enforcable or does make sense and reread my answer to your editorial.

"true, it doesn't affect how one can distribute Qt; however, it *does* affect how or whether on can distribute the program itself."

Careful. A license like the GPL is purely based on copyright law. It can only put restrictions on copying the work or a derivative work. It may talk about modules and other things, but if those modules are legally independent, it's really just meaningless words.

"I'm not sure what this means. Maybe you could clarify? "

I thought I was clear enough (and that Eirik Eng was clear enough). Judging from the reactions, we probably were not. Ok, I try again.

Trolltech's business idea is to provide top-quality development tools for programmers. Free software developers on Unix should be able to use all our tools for free if they write free software. If they write proprietary commercial software, we want them to buy a license from us. Thus commercial software development immediately supports free software development and in return gets well-tested development tools with a broad developer base. It's really a win-win situation and it works pretty well.

Now, in order to make this possible, the Qt Free Edition needs a license that clearly states that it can only be used for free software development.

According to Debian or the FSF, the GPL is such a license. And many people were wondering why Trolltech didn't use the GPL for the Qt Free Edition, but rather a home-brewed license, the QPL. This I want to explain.

Imagine - just for a second - that Qt Free Edition was a GPLed library, ok? Now somebody writes a big proprietary application and starts selling and distributing it, without source code under a traditional commercial license. This application uses the QPLed Qt Free Edition and they ship it together with the Qt Free Edition.

Now the question is: Can they legally distribute their proprietary application or not? Debian and the FSF would say: they can't! Everybody else says "they can!". And why? Because the module stuff you were talking about seems to be legal nonsense. Now I'm not a lawyer and not at all an expert in international copyright law (and neither are you), but that's what we were told and what for example Lineo states on the mentioned web pages.

Can you see the problem now? Trolltech would like to end the arguing with the free software community by making it possible to relicense Qt under the terms of the GPL if the GPL really worked for libraries. What we need is a GPL V3 that fixes the bugs. This new version probably should also contain something like the QPL 6c, as this clause really helps forcing companies to contribute if they were using free software.

Ironic, isn't it? As it stands today, the QPL is a much better free software license than the GPL.

[reply] [top]

[»] Linking and licences
by Silver A - Jul 15th 2000 17:20:44

Much is made of what the Free Software Foundation intends the GPL to mean. However, what it actually says is more important, and the intent is only to be examined in the event of ambiguity. The GPL says

The source code for a work means the preferred form of the work for making modifications to it. For an executable work, complete source code means all the source code for all modules it contains, plus any associated interface definition files, plus the scripts used to control compilation and installation of the executable. However, as a special exception, the source code distributed need not include anything that is normally distributed (in either source or binary form) with the major components (compiler, kernel, and so on) of the operating system on which the executable runs, unless that component itself accompanies the executable.

Reading this, it seems to me that if I write a program dynamically linked to the Qt libs, and distribute the source code without including the Qt libs, I can put my work under the GPL without conflict.

[reply] [top]

[»] The GNU Public Virus
by L. Adrian Griffis - Jul 15th 2000 16:40:59

I have to agree with Mathias on this one. GPL's insistance on changing every licence over to itself is what first got it called the GNU Public Virus in the first place. I think what we are seeing here are the consequences of Richard Stallman's fanaticism. Don't get me wrong; The FSF has accomplished a great deal. But the real problem between QPL and GPL is that Stallman has never been able to accept even the slightest dissent from his own point of view.

If I understand correctly, the goals of QPL and GPL are very similar. The critical difference is Richard Stallman see's no room whatsoever for other points of view.

Think of it this way. We all have to ask ourselves if our way of live would make it hard for us to get along with other people that live the way we do. Then we should ask ourselves if there is a truely compelling justification for giving up on coexisting peacefully in the face of each viewpoint difference or lifestyle difference that we cannot accept. In other words, is it really healthy to demand that others see things exactly as we do, or should we attempt to coexist peacefully with other viewpoints and lifestyles whenever we can. All this is as important in the programming business as it is in life in general.

If Richard Stallman can't tollerate this slightly different way of encouraging free software, is it really QPL that has to change? What about the next slightly different point of view that comes along? Must we all tote exactly the same party line before Stallman will work with us? Again, I don't want to belittle what Richard Stallman and FSF have done for us; But, is it really necessary to squash all differences in point of view, no matter how small, to advance the cause of Free Software?

This message is in the Public Domain, and is NOT covered by the GPL.

Adrian

[reply] [top]

[»] Re: Response by a Troll ;-)
by J. J. Ramsey - Jul 15th 2000 16:30:13

"It may very well be that the GPL wants to include utilized libraries
into its understanding of a program or a work as a whole. But how is
it supposed to do that legally?"

Simple. One indicates that either the library must be under
GPL-compatible terms or must not be linked to at all. The GPL can't
change the terms of third-party libraries, of course, but it can be
selective about what libraries a GPL'd work is allowed to link to.

"Take a piece of code that's under the GPL and has nothing to do with
Qt. It's hardly a derivative work of Qt nor is Qt a derivative work of
this piece of code. Now you take this code and put it into a Qt
program. This program isn't a derivative work of Qt either nor is Qt a
derivative work of this program."

This is not relevant, although you should be careful here. If
"derivative work" is interpreted in the way the FSF treats the term,
the program *is* a derivative work of Qt. (This is why the LGPL
exists.) This isn't relevant because the QPL isn't "viral"; it doesn't
require derivative works of QPL'd works to be under the QPL. In
general, though, "derivative work" is not the crux of the argument,
but rather whether a QPL'd library is considered a "module" of a GPL'd
work that links to Qt.

"How can the license of this piece of code then have any influence on
how you have to distribute Qt? In fact it can't."

True, it doesn't affect how one can distribute Qt; however, it *does*
affect how or whether on can distribute the program itself.

"As Eirik Eng pointed out in the statement on Freshmeat a few weeks
ago, neither the GPL nor the LGPL legally protect libraries. There's
no real legal basis for assuming that no proprietary software is
written and distributed with a library under these licenses."

I'm not sure what this means. Maybe you could clarify?

"This conflicts with Debian's or the FSF's interpretation of the GPL,
however it is what all lawyers we talked with keep telling us. . . .
Again: if the GPL would do what Debian believes it does, Trolltech
would allow relicensing Qt under the terms of the GPL."

I apologize if I am misunderstanding what you write, but if I read you
correctly, than I'd say that you have misinterpreted the position of
Debian and the FSF. If the GPL would do what Debian believes it does,
than it would *forbid* linking to Qt, not make Qt to become GPL.

[reply] [top]

[»] BSD License
by Alex Queiroz - Jul 15th 2000 14:57:59

I don't use GPL for my code either, my license of choice is BSD. If they will use my code in proprietary software, it will be stated in the docs and I will know I produced a good piece of code. If they put nice features in it, I will reproduce it if I can, if not someone else will and the source will improve. Nobody's wrong in charging for code, it's their living, damn.

[reply] [top]

[»] Re: Dynamic linking
by J. J. Ramsey - Jul 15th 2000 14:46:51

"Thus, as long as you never distribute a binary, or source, which is made up of a GPLed work, and a non-GPLed one (e.g. a QPLed one), you are totally within the law. Thus, from what I understund, you are allowed to use non-GPLed library in a GPLed program, as long as the headerfiles of e.g. Qt, are GPLed, and the linking is either done at installation time, or at run-time, so that a derivative work is never distributed."

As far as I know, that is only partially right. One is not bound by the GPL so long as one does not distribute a GPL'd work. Distributing a "derivative work" is a non-issue, though. The issue is that according to the FSF's interpretation of the GPL, Qt is a module of whatever executable links to it--whether statically or dynamically; *it doesn't matter--and if the executable is GPL'd, the module had better be under GPL-compatible terms, that is, it must be under a license that has no terms that conflict with the GPL. That's the sticking point. Whether the linking is static or dynamic doesn't help you.

[reply] [top]

[»] A Solution
by jik- - Jul 15th 2000 13:58:40

Stop using the GPL as the licence to your new programs. Use something else, keep people from using your code in proprietery works if you have to, but don't try to keep them from using other free libraries with it. Otherwise the code is NOT free, it is restricted to what a few big mouthed brats think it should be....or what your high paid lawyer can prove.

It would just save us a lot of hassle if people just used something else besides GPL. Besides...maybe then they will alter the GPL to be less hindering to the distribution of free software like KDE.

Ever since this whole KDE/Qt vs. Debian/FSF and folks started I have refused to release my code under the GPL. I will continue to do so as long as they continue with this hypocritical bullshit.

[reply] [top]

[»] Hm, annoyed by Qt stuff
by Jacco van Koll - Jul 15th 2000 13:28:32

As a user i am very annoyed by the "fight" between QT and others about the implementing of their Licences. Ok, fight yourselves to death.... I don't care! I just care about good free software.

Get a life and get real. Get your ass in gear and make things happen for the users. Stop fussing around.

Because of this fuss, i stopped to use KDE. So i do not use QT as well anymore. Hurray for QT...... You won....

AND: I am just a user of software ......

[reply] [top]

[»] Response by a Troll ;-)
by Matthias Ettrich - Jul 15th 2000 12:49:52

It may very well be that the GPL wants to include utilized libraries into its understanding of a program or a work as a whole. But how is it supposed to do that legally? Take a piece of code that's under the GPL and has nothing to do with Qt. It's hardly a derivative work of Qt nor is Qt a derivative work of this piece of code. Now you take this code and put it into a Qt program. This program isn't a derivative work of Qt either nor is Qt a derivative work of this program. How can the license of this piece of code then have any influence on how you have to distribute Qt? In fact it can't.

Believe me that Trolltech spent a significant amount of time with the perceived licensing issue and is very aware of both Debian's and the FSF's position. That doesn't mean those positions are correct, though.

As Eirik Eng pointed out in the statement on Freshmeat a few weeks ago, neither the GPL nor the LGPL legally protect libraries. There's no real legal basis for assuming that no proprietary software is written and distributed with a library under these licenses. This conflicts with Debian's or the FSF's interpretation of the GPL, however it is what all lawyers we talked with keep telling us. Have a look at http://www.lineo.com/products/ for a second opinion. Again: if the GPL would do what Debian believes it does, Trolltech would allow relicensing Qt under the terms of the GPL.

But as you said, in the free software community it all boils down to intention and purpose. For me as a developer, the right to use software for free for free software development, the right to read the source code and to modify if required and the freedom to distribute my modifications are the most important ones. Qt gives a developer all those rights and thus I saw and I see it as a good choice to write free software with.

It doesn't reduce the amount of freedom in the world if somebody writes free software with Qt and it is for shure not a criminal act. In fact, KDE - within just two years - increased the amount of free source code by something like 2.500.000 lines of high quality C++ code. Code that would not have been possible without Qt. Code you can use in any free program, free of charge. And this code has indeed been reused. Take for instance the GTK html widget: it's a port of the original KDE html widget written with Qt.

To sum it up: All of KDE's code is part of the free software pool. There's really no reason to blame KDE for writing free code and there's no reason to keep users from using this code.

This is a personal statement made by me. It doesn't necessarily represent the position of my employer (Trolltech).

[reply] [top]

[»] What's a module? What's linking?
by Scott - Jul 15th 2000 12:03:35

I don't think it really matters what was intended when the GPL was written; for the most part, only the writing itself matters. So, "module" is still incompletely defined. In fact, it is not implausible that the definition was left intentionally vague to make it harder to circumvent. (If it was defined in detail, it might be possible to get around the letter of the GPL with minor cosmetic changes to source code.)

If we interpret "module" broadly, is it a violation of the GPL to view a web page containing a GPLed java applet using a non GPL compatible web browser? What about a page which contains GPLed javascript?

Is connecting ftp to ftpd with sockets linking? Is ftpd, a module of ftp? If so, is it a violation to use a GPLed ftp client to connect to a non-GPLed ftp daemon? If connecting two programs with sockets is not linking, than would making Qt a server and Qt applications clients make Qt GPL compatible?

[reply] [top]