Re: LICENSES [was: Re: Have you seen this?]
In my opinion, Qt is not a section of KDE, it is not derived from the KDE and it must be considered independent and separate from the KDE. In other words: The KDE's usage of the GPL does not cause the GPL, and its terms, to apply to Qt. Indeed Qt is not part of the problem indeed But when you distribute the same sections as part of a whole which is a work based on the Program, the distribution of the whole must be on the terms of this License, whose permissions for other licensees extend to the entire whole, and thus to each and every part regardless of who wrote it. Qt is not distributed as part of KDE. It is distributed as part of various distributions that also include the KDE, but only by mere aggregation [...] on a volume of a storage or distribution medium which the GPL okays elsewhere in the text. It is not a mere aggregation. If I remove Qt KDE is unusable. I note here, a point that most ppl probably know: It is certainly not the fault of the Qt ppl that KDE would be unusable without Qt's presence. Qt is not owned by the KDE ppl, so Qt folx should not be affected by KDE's decision to use KDE. If, on the other hand, Qt decides to say that they like (whatever that means, and in whatever form it comes) KDE's use of Qt, then at that point, they are possibly in it together. For example, if Qt does anything to facilitate KDE's success in its present (with-Qt) state, then I would take on the opinion that they are both in the situation together, and responsible for the results thereof. (Like my opinion means anything :) KDE requires Qt currently. So KDE is non free. _No_. This does not necessarily follow, even if both statements may both be true. KDE simply depends on something that is non-free. If KDE itself can be (1) obtained in source, (2) altered and then (3) redistributed in its altered form and (4) have all these with the only restriction being that further restriction cannot be applied, it is free. If it presently depends on something that is non-free, we know the drill: the source is available. Therefore, anyone can fix it. Similarly Linus does not distribute KDE with the kernel so its not in the base distribution. I see your point here as KDE does not come with the linux os (that being the kernel) therefore the clause in the GPL, making an exception for a piece of software included with an OS, does not apply. I would agree, however we should watch this MicroSoft lawsuit carefully: it might redefine what can be considered part of an OS. (Of course, it won't change what Linus distributes.) I would make the same observation about Qt: Linus doesn't distribute Qt with the kernel either. So KDE would have a reason to not assume the exception in the GPL wrt Qt. On Solaris KDE is shipped even though no Sun product includes Qt. So the case there is even more blatant Could you elaborate a bit here, if only addressing the elaboration to me? why is this more blatent? -Jim
Re: LICENSES [was: Re: Have you seen this?]
However, the license for that derived work (I'll call it A) claims that the whole of A must be GPL'd. However, Qt is not part of A (the GPL says section of). Qt provides services to A, and A depends on those services: A very different thing. Qt is part of the derived work. It is linked to it and the work A does not function without it. It is also not a public API and your message to Preston concerning possible legal action against harmony makes it clear you regard the item as actively protected IPR not an open API I understood the meaning of is derived from to be using the source code to make a derivative of as opposed to using the services of. If I use libc, I don't think I am creating a libc. Unless I am, I'm not deriving, I think. If I use libc, I simply use the services. Hence, libc is a section of the thing I am making, and does not derive from it. How is this wrong? Is it strategic to look at sections as derivations? -Jim
Re: LICENSES [was: Re: Have you seen this?]
If I use libc, I don't think I am creating a libc. Unless I am, I'm not deriving, I think. If I use libc, I simply use the services. Hence, libc is a section of the thing I am making, and does not derive from it. Your program derives from libc by being linked with it. This is precisely why an LGPL has to exist. Alan
Re: LICENSES [was: Re: Have you seen this?]
On Mon, 12 Oct 1998, Alan Cox wrote: If I use libc, I don't think I am creating a libc. Unless I am, I'm not deriving, I think. If I use libc, I simply use the services. Hence, libc is a section of the thing I am making, and does not derive from it. Your program derives from libc by being linked with it. This is precisely why an LGPL has to exist. true. more precisely: when you compile your program, the binary is a combined work which is derived from both your source code and libc. that derived work may only be distributed if ALL of it's parts (i.e. your source AND the libc) may be distributed under the terms of the GPL. note that there is also an exemption for libraries which normally come with the operating system - and libc definitely qualifies there...but that is a specific exemption which doesn't affect the general rule above. libc is a potentially confusing example, so s/libc/libFOO/ in my first paragraph above. craig -- craig sanders
Re: LICENSES [was: Re: Have you seen this?]
If I use libc, I don't think I am creating a libc. Unless I am, I'm not deriving, I think. If I use libc, I simply use the services. Hence, libc is a section of the thing I am making, and does not derive from it. Your program derives from libc by being linked with it. This is precisely why an LGPL has to exist. So this isn't derivative in the sense of the OOP idiom IS-A... and you're saying that all I have to do to derive from something, is to include it unmodified or modified? -Jim
Re: LICENSES [was: Re: Have you seen this?]
Craig Sanders [EMAIL PROTECTED] wrote: note that there is also an exemption for libraries which normally come with the operating system - and libc definitely qualifies there... Nope. Some of the time, libc would qualify for that special excemption. But it doesn't qualify for anything shipped with the OS (which includes, at a minimum, the kernel and libc). -- Raul
Re: LICENSES [was: Re: Have you seen this?]
Alan Cox [EMAIL PROTECTED] wrote: KDE requires Qt currently. So KDE is non free. [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: _No_. This does not necessarily follow, even if both statements may both be true. KDE simply depends on something that is non-free. Except that KDE programs have been written (or modified) to require Qt, to not work without Qt, and everybody that uses it lives with this design aspect. -- Raul
Re: LICENSES [was: Re: Have you seen this?]
Jim writes: So this isn't derivative in the sense of the OOP idiom IS-A... and you're saying that all I have to do to derive from something, is to include it unmodified or modified? In copyright law is a derivative of means contains a copy of all or part of. Copyright is about making copies. -- John HaslerThis posting is in the public domain. [EMAIL PROTECTED] Do with it what you will. Dancing Horse Hill Make money from it if you can; I don't mind. Elmwood, Wisconsin Do not send email advertisements to this address.
Re: LICENSES [was: Re: Have you seen this?]
On Sat, 10 Oct 1998, Alan Cox wrote: [..] And lots of people haven't kicked stuff back. Why doesn't *BSD run on an SGI Indy - its because the BSD license didnt force all the neat stuff to be contributed back. And there are thousands of other examples like it. I fail to see how this is all that much different from the GPL perhaps scaring off a comercial entity from contributing code. Of course I don't have a specific example off the top of my head :) Your the world outside of GPL is evil attitude is quite bogus. I don't know where you got that from. But its not my attitude. I get that feeling from this whole thread, but perhaps that's just me. - alex
Re: LICENSES [was: Re: Have you seen this?]
And lots of people haven't kicked stuff back. Why doesn't *BSD run on an SGI Indy - its because the BSD license didnt force all the neat stuff to be contributed back. And there are thousands of other examples like it. I fail to see how this is all that much different from the GPL perhaps scaring off a comercial entity from contributing code. Of course I don't have a specific example off the top of my head :) Im sure there are plenty. They are different ideas about 'free'. Fortunately the non advertising BSD copyright appears to be fully GPL compliant and lots of people are happy to dual license things so that both visions of 'free' can use the same stuff. Linux BSD share several drivers, some sync ppp code and other things like pieces of the Mac booter. So such arrangements do work.
Re: LICENSES [was: Re: Have you seen this?]
On Sun, Oct 11, 1998 at 12:25:27PM -0700, Alex wrote: [..] And lots of people haven't kicked stuff back. Why doesn't *BSD run on an SGI Indy - its because the BSD license didnt force all the neat stuff to be contributed back. And there are thousands of other examples like it. I fail to see how this is all that much different from the GPL perhaps scaring off a comercial entity from contributing code. Of course I don't have a specific example off the top of my head :) The GPL has a feature that with the exception of essential system type libraries (which is IMO far too vague to be terribly useful) any work derived from the GPL must also be under the terms of the GPL. Not necessarily GPL, but the same terms. The other stuff can allow more (LGPL for example) but not less (Motif for example). Of course, Motif was a really hairy example because some places like Solaris, Motif is considered a system library! So you can use Motif some places and not others with GPL code? Essentially yeah. The GPL feature that all derived works must be pure is quite frustrating and only the GPL has that feature. What happens when GPL code is written for use with something not under those terms then? Much of KDE is written from scratch, after all---as is lyx and a few (dozen) other programs I could probably think of with some time. According to the letter of the GPL, when combined with these things the software is undistributable. Certainly that's not what the authors want, so it's been generally assumed that they did want you to distribute things linked together like that or they wouldn't do it themselves. It seems that because of the way things are working out, that's not going to be enough anymore. = It wasn't really enough before, but now clearly it's not. Of course, it's Debian's position that just because that permission is implied with things like lyx for example, things that were otherwise free like ghostview don't have that implied permission. That's the biggest reason I was part of the consensus that said we needed KDE to clarify the license or we couldn't distribute it after the license issue was reported as a bug. Stephan Kulow was going to bring it up with everyone else and try and get some resolution out of it. No resolution happened. So months later, we decided that we had probably no other choice than to remove it until the license was at least addressed. Well you can see where that's gone. It's made a BIGGER mess of everything and it's no closer to getting the right things done like asking the ghostview people if it's okay to use their GPL code with Qt. FWIW, I'm not certain still if that feature in the GPL is good or not. It was put there with good intentions, but it's clear there's a reason the GPL is the only license that requires these hoops be jumped through. Your the world outside of GPL is evil attitude is quite bogus. I don't know where you got that from. But its not my attitude. I get that feeling from this whole thread, but perhaps that's just me. The whole thread is proof what a mess this whole thing is. I'm glad at least Stephan will continue to make debian packages, but that's not the way I wanted this to end. Most of Debian does not believe KDE is inherently evil (though I won't lie to you and claim that I don't believe at this point that a few of the KDE developers simply don't WANT any resolution) though I'll admit a few of the Debian users and at least one or two developers have had nothing but nasty things to say about KDE itself. I probably would have given up on the whole KDE project if I didn't believe that at least a few developers (more than a couple of which have contacted me by email in response to my slashdot postings) are at least concerned by this. As far as I am concerned, the majority of KDE which is written by KDE completely has no problem--you'd not have written it for Qt if you didn't intend it to be used with Qt. (duh, how did I ever arrive at that conclusion? Those who haven't make me wonder...) But the included parts of other GPL applications, that's more an issue. I know nobody really wants to go around asking everyone hey, you mind if we use your code with Qt? especially when in a majority of cases the answer is going to probably be I don't give a rip as long as my name stays on it. I have offered before (many times now) and offer still to help if my help is at all desired. Course Harmony would fix the whole problem without asking anyone for anything, but I don't see that has happening real soon. pgpIAmz4IFk35.pgp Description: PGP signature
Re: LICENSES [was: Re: Have you seen this?]
Joseph Carter [EMAIL PROTECTED] wrote: The GPL has a feature that with the exception of essential system type libraries (which is IMO far too vague to be terribly useful) any work derived from the GPL must also be under the terms of the GPL. That's not really what it says, which is probably why you think it is vague. Not necessarily GPL, but the same terms. This, however, is pretty accurate... [skipping down] FWIW, I'm not certain still if that feature in the GPL is good or not. It was put there with good intentions, but it's clear there's a reason the GPL is the only license that requires these hoops be jumped through. If the hoop had been jumped through, we'd be seeing development snapshots of Qt which take advantage of enlightenment's various features. Instead that development effort is going into Gnome. That Gnome and KDE are two separate projects is complete a result of this licensing issue. That the GNU folks haven't pursued legal action is an indication of the good nature of those folks and does not indicate that they lack the legal right to such action. The whole thread is proof what a mess this whole thing is. I'm glad at least Stephan will continue to make debian packages, but that's not the way I wanted this to end. It's not over yet. [Though the tendancy that Matthias has -- to resort to ad hominem, and claim he doesn't have time when he can't address the issues through reason -- does kind of stall things.] -- Raul
Re: LICENSES [was: Re: Have you seen this?]
On Fri, 9 Oct 1998, Matthias Ettrich wrote: [snip] This GPL argument if taken to it's logical conclusion would prevent all GPL'ed code from running on any non-GPL'ed OS, as the applications have to link with the platform libraries, and are resultantly dependant on the non-GPL'ed OS. Indeed. If you read the GPL word for word you will find that a binary distribution requires ALL libraries to be distributed under the GPL. Debian cheats and claims the GPL is happy with so-called compatible licenses, but that's not true: The GPL explicitely requires GPL. That means, Debian has licensing problems whenever they ship something that links to the libc or glibs (because it's not GPL, but LGPL) or - even worse! - whenever something links against X11, because Xlib is clearly neither GPL nor LGPL. once again, you demonstrate your profound lack of understanding of the GPL. the GPL explicitly makes an exception for libraries which are included with the operating system itself. This includes LGPL libraries distributed with free operating systems, and it includes non-free libraries distributed with non-free operating systems (e.g. win32 on windows, motif on solaris) i suggest that you read the GPL. It might prove instructive. But that is not the point. Debian sometimes is strict, sometimes not. They clearly treat KDE in a different way. yes, we have granted KDE the benefit of the doubt for over a year while trying to get you guys to do something about your licensing problems. KDE has consistently failed to do anything at all to resolve these problems. In fact, you have consistently refused to acknowledge that there is a problem. There *IS* a problem, and pretending it doesn't exist will not make it go away. now we are treating KDE the same as we treat any other program with a questionable license. Debian on the other hand does not want to encourage people to write more free software based on KDE. They probably dislike the basic idea of a user- and developer-friendly framework for linux on its own Combined with a commercial product they hate it so much, that they don't even want to encourage people to work on harmony (what they would do if they shipped KDE). What dissapoints me is that they cannot say this in public. If they said: Debian does not want to encourage people to write software with the KDE libraries, so we remove the packages they would at least be honest. But they are not honest. Instead, they claim that KDE has a mess of a license that forbids them to do what they would like to do: distributing it. This is such a childish excuse, even more since the KDE libraries do not contain any so-called 3rd party code at all. (3rd party code, the word alone is a shame! Are we KDE Incorporated or a bunch of hackers writing free software?!). your paranoid rant barely deserves a reply. all i can say is that if you think we are bullshitting about the license issue then CALL OUR BLUFF. Fix what we claim are your license problems, what we are asking you to do is add an explicit permission in your licenses to link to Qt. How difficult can that be? The hardest part will be that you will have to seek permission from some upstream authors whose code you have used. if you fix all your license problems and debian still refuses to distribute KDE binaries then you have proved your point and demonstrated to the world that debian are a pack of bastards who are out to get KDE. if you fix your license problems and debian does distribute KDE binaries then you are proven to be wrong, BUT on the bright side your software gets more widely distributed and easier for users to install. This is a WIN-WIN situation. You have nothing to lose by fixing your license problems (except maybe a little temporary embarassment, which is nowhere near as important as the software). Debian's claim is pointless. If it was not pointless they could at least come up with one single author of at least one single line of so-called 3rd party GPLed code in a KDE application who actually shares their opinion and states in public: I do not want my line of code to be distributed as binary, that's why I put it under the GPL. Source is ok, though. license permissions are exclusive, not inclusive. any permission not explicitly granted is denied. this is the nature of software licenses and copyright law. what this means is that an author doesn't have to declare no Qt linking any more than they have to declare no illegal copying or no stealing my work. These declarations are implicit in the copyright itself. Until an author of a GPLed work grants permission to link with Qt and distribute the result, NOBODY (except the author) HAS ANY RIGHT TO DO SO. DISCLAIMER: i am a debian developer, but i am speaking for myself, not debian. craig -- craig sanders
Re: LICENSES [was: Re: Have you seen this?]
On Fri, Oct 09, 1998 at 11:59:37AM +0200, Matthias Ettrich wrote: and enduser support, not for discussing home-brewed licensing problems of niche distributions. Enough said, I think. Hamish -- Hamish Moffatt VK3TYD [EMAIL PROTECTED], [EMAIL PROTECTED] Latest Debian packages at ftp://ftp.rising.com.au/pub/hamish. PGP#EFA6B9D5 CCs of replies from mailing lists are welcome. http://hamish.home.ml.org
Re: LICENSES [was: Re: Have you seen this?]
Craig Sanders [EMAIL PROTECTED] the GPL explicitly makes an exception for libraries which are included with the operating system itself. Not quite so - it makes an exception for binaries that are NOT included with that operating system itself. Debian ships a large number of GPL'd binaries that are linked against LGPL'd libraries (chiefly libc). This practice is not compatible with what Debian says in the statement that started this thread - and I too think such incompatibility may reasonably be called cheating. (Not that it's really relevant, but IMHO Debian's practice is right and the statement wrong.) --Arnt
Re: LICENSES [was: Re: Have you seen this?]
On 10 Oct 1998, Arnt Gulbrandsen wrote: Craig Sanders [EMAIL PROTECTED] the GPL explicitly makes an exception for libraries which are included with the operating system itself. Not quite so - it makes an exception for binaries that are NOT included with that operating system itself. that's almost the exact opposite of what the GPL says. from clause 3 of the GPL: 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. the last sentence, from However, as a special exception is particularly relevant here. Debian ships a large number of GPL'd binaries that are linked against LGPL'd libraries (chiefly libc). This practice is not compatible with what Debian says in the statement that started this thread - and I too think such incompatibility may reasonably be called cheating. (Not that it's really relevant, but IMHO Debian's practice is right and the statement wrong.) read the GPL. think about it. read it again. think some more. repeat until all is clear. craig -- craig sanders
Re: LICENSES [was: Re: Have you seen this?]
On Sat, 10 Oct 1998 11:33:15 +1000 (EST), Craig Sanders wrote: the last sentence, from However, as a special exception is particularly relevant here. So, if Qt were disttributed with the OS then it would fall under the special exception? :) -- Steve C. Lamb | I'm your priest, I'm your shrink, I'm your ICQ: 5107343 | main connection to the switchboard of souls. ---+-
Re: LICENSES [was: Re: Have you seen this?]
Craig Sanders [EMAIL PROTECTED] that's almost the exact opposite of what the GPL says. from clause 3 of the GPL: I've read clause three, thank you. I'll upper-case the bit you must have missed: 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. the last sentence, from However, as a special exception is particularly relevant here. It's clear that (e.g.) libc accompanies (e.g.) /bin/ls in Debian: They are both in main, and the package maintainer makes sure you get libc when you get /bin/ls. If you also think that libc is a section of (see section two) /bin/ls and so on, then the conclusion is clear: You're in contravention of the GPL as you read it. read the GPL. think about it. read it again. think some more. repeat until all is clear. Physician, heal thyself. --Arnt
Re: LICENSES [was: Re: Have you seen this?]
Steve Lamb [EMAIL PROTECTED] So, if Qt were disttributed with the OS then it would fall under the special exception? :) That's what he says. That still, however, would not permit applications distributed with the OS to use Qt. In other words, if thar paragraph were the big issue, you could -use- Qt in a GPL'd program, but in doing so you would refuse all linux distributors the right to include your program in their distributions. The key is in an earleir paragraph. These requirements apply to the modified work as a whole. If identifiable sections of that work are not derived from the Program, and can be reasonably considered independent and separate works in themselves, then this License, and its terms, do not apply to those sections when you distribute them as separate works. In my opinion, Qt is not a section of KDE, it is not derived from the KDE and it must be considered independent and separate from the KDE. In other words: The KDE's usage of the GPL does not cause the GPL, and its terms, to apply to Qt. But when you distribute the same sections as part of a whole which is a work based on the Program, the distribution of the whole must be on the terms of this License, whose permissions for other licensees extend to the entire whole, and thus to each and every part regardless of who wrote it. Qt is not distributed as part of KDE. It is distributed as part of various distributions that also include the KDE, but only by mere aggregation [...] on a volume of a storage or distribution medium which the GPL okays elsewhere in the text. --Arnt
Re: LICENSES [was: Re: Have you seen this?]
On Fri, 9 Oct 1998, Steve Lamb wrote: On Sat, 10 Oct 1998 11:33:15 +1000 (EST), Craig Sanders wrote: the last sentence, from However, as a special exception is particularly relevant here. So, if Qt were disttributed with the OS then it would fall under the special exception? :) yes. however the point is moot. Qt is not, and can not, be distributed with debian. it is non-free, it fails the DFSG (Debian Free Software Guidelines) test. if Qt ever becomes DFSG free, then it can be included in debian, but i do not think that is likely to happen. (TrollTech have every right to license their software in the way that they choose, and they choose a non-free license. Neither I, nor anyone sensible, has any argument with TT's license...it's their software, they can do what they like with it.) craig -- craig sanders
Re: LICENSES [was: Re: Have you seen this?]
On 10 Oct 1998, Arnt Gulbrandsen wrote: In my opinion, Qt is not a section of KDE, it is not derived from the KDE and it must be considered independent and separate from the KDE. In other words: The KDE's usage of the GPL does not cause the GPL, and its terms, to apply to Qt. if you link a GPL-ed program and Qt, you are creating a work which is derived from both. Since Qt's license is incompatible with the GPL as far as distribution goes, you may not distribute that derived work without additional permission being granted by the author (unless, of course, you are the author). note that the GPL does not distinguish between static and dynamic linking. RMS, the author of the GPL (whose opinion, therefore, is just more authoritative on this subject than yours), has pointed this out on numerous occasions. note also, that this license conflict is only with regard to distribution of the derived work. what you do on your own machine is your concern. the GPL does not restrict usage or modification in any way, it only restricts re-distribution in order to preserve the free status of GPLed software. All this is just splitting hairs, though. The real question is what is KDE's problem with just adding that additional permission to their license? How does it hurt them to do that? it's not difficult to do, and it would solve the problem for everyone. it would clarify their apparent intention, without harming them in any way. it would give debian (and others) the legal permission they seek to distribute the KDE software. craig -- craig sanders
Re: LICENSES [was: Re: Have you seen this?]
Matthias Ettrich [EMAIL PROTECTED] writes: Indeed. If you read the GPL word for word you will find that a binary distribution requires ALL libraries to be distributed under the GPL. Interesting that you do not even quote the GPL to try and back up your non-arguments. Martin.
Re: LICENSES [was: Re: Have you seen this?]
On Sat, Oct 10, 1998 at 12:45:35PM +1000, Craig Sanders wrote: All this is just splitting hairs, though. The real question is what is KDE's problem with just adding that additional permission to their license? How does it hurt them to do that? it's not difficult to do, and it would solve the problem for everyone. it would clarify their apparent intention, without harming them in any way. it would give debian (and others) the legal permission they seek to distribute the KDE software. Let me try to make some qualified guess about this: If KDE would add the permission note, they would admit that there is a license problem, and they had to stop sucking in GPL'ed third party code without explicit permission by the authors. Seems that KDE has either an attitude problem or they are scared that there wouldn't be too much support for them if they had to ask for permission to link with a non-free library each time they incorporate foreign code. Marcus Disclaimer: My views are my own. -- Rhubarb is no Egyptian god.Debian GNU/Linuxfinger brinkmd@ Marcus Brinkmann http://www.debian.orgmaster.debian.org [EMAIL PROTECTED]for public PGP Key http://homepage.ruhr-uni-bochum.de/Marcus.Brinkmann/ PGP Key ID 36E7CD09
Re: LICENSES [was: Re: Have you seen this?]
On Fri, Oct 09, 1998 at 06:36:12PM -0700, Steve Lamb wrote: On Sat, 10 Oct 1998 11:33:15 +1000 (EST), Craig Sanders wrote: the last sentence, from However, as a special exception is particularly relevant here. So, if Qt were disttributed with the OS then it would fall under the special exception? :) Yes, and apparently SuSE do this. Of course, it ain't going to happen with Debian because not of the system stuff is not DFSG-free nor could it ever be. Hamish -- Hamish Moffatt VK3TYD [EMAIL PROTECTED], [EMAIL PROTECTED] Latest Debian packages at ftp://ftp.rising.com.au/pub/hamish. PGP#EFA6B9D5 CCs of replies from mailing lists are welcome. http://hamish.home.ml.org
Re: LICENSES [was: Re: Have you seen this?]
Craig Sanders [EMAIL PROTECTED] if you link a GPL-ed program and Qt, you are creating a work which is derived from both. Since Qt's license is incompatible with the GPL as far as distribution goes, you may not distribute that derived work without additional permission being granted by the author (unless, of course, you are the author). However, the license for that derived work (I'll call it A) claims that the whole of A must be GPL'd. However, Qt is not part of A (the GPL says section of). Qt provides services to A, and A depends on those services: A very different thing. note that the GPL does not distinguish between static and dynamic linking. It distinguishes between separate distribution and distribution as part of A. Not entirely the same thing, but not terribly different either. RMS, the author of the GPL (whose opinion, therefore, is just more authoritative on this subject than yours), has pointed this out on numerous occasions. rms, you and I are all simple persons and speak with the same authority. Only a court speaks with special authority. All this is just splitting hairs, though. The real question is what is KDE's problem with just adding that additional permission to their license? How does it hurt them to do that? Is that really not obvious to you? --Arnt
Re: LICENSES [was: Re: Have you seen this?]
On 10 Oct 1998, Arnt Gulbrandsen wrote: All this is just splitting hairs, though. The real question is what is KDE's problem with just adding that additional permission to their license? How does it hurt them to do that? Is that really not obvious to you? Craig Sanders and some debian people wanted to play simple tricks ;-) Yours, -- martin P.S.: Please move that discussion away from [EMAIL PROTECTED] Thank you!! // Martin Konold, Herrenbergerstr. 14, 72070 Tuebingen, Germany // // Email: [EMAIL PROTECTED] // Anybody who's comfortable using KDE should use it. Anyone who wants to tell other people what they should be using can go to work for Microsoft. [EMAIL PROTECTED]: BCPL gave birth to B, and the child of B was of course C, since the ancestor of X is W, so the sucessor to X must be K.
Re: LICENSES [was: Re: Have you seen this?]
Sorry, I must be too tired. I misread a paragraph of yours, so some of my previous message probably don't make much sense. You say that linking constitutes making a derived works of the object files and libraries being linked together. Does that mean that you think Debian should convert libc and so on from the LGPL to the GPL in order to comply with the license of the GPL'd applications in main? --Arnt
Re: LICENSES [was: Re: Have you seen this?]
On 10 Oct 1998, Arnt Gulbrandsen wrote: Craig Sanders [EMAIL PROTECTED] if you link a GPL-ed program and Qt, you are creating a work which is derived from both. Since Qt's license is incompatible with the GPL as far as distribution goes, you may not distribute that derived work without additional permission being granted by the author (unless, of course, you are the author). However, the license for that derived work (I'll call it A) claims that the whole of A must be GPL'd. However, Qt is not part of A (the GPL says section of). Qt provides services to A, and A depends on those services: A very different thing. you miss the point. linking the two creates a work which is derived from both. note that the GPL does not distinguish between static and dynamic linking. It distinguishes between separate distribution and distribution as part of A. Not entirely the same thing, but not terribly different either. they are quite different. rms, you and I are all simple persons and speak with the same authority. Only a court speaks with special authority. the author of a work generally has a damn good idea of what his intentions were when he wrote it. Intent is a very important factor when it comes time to interpret a document (or an action, for that matter) in a court of law, especially when the author has repeatedly gone to great lengths to clarify his intentions. case in point: KDE developers *appear* to intend that their software be linked with Qt and redistributed. But whenever they are asked to clarify their intentions, they ignore the question and try to side-step the issue. Why? All that is being asked of them is to clearly state their intention by explicitly granting the permission to link with Qt and distribute. All this is just splitting hairs, though. The real question is what is KDE's problem with just adding that additional permission to their license? How does it hurt them to do that? Is that really not obvious to you? no, it's not obvious. the only thing i can think of is that KDE developers are aware of the license problems but don't want to publicly admit to them because of the ramifications about the other GPLed code that they have used. i prefer to think of KDE developers as merely mistaken (and a bit clueless about licensing issues), rather than as deliberately disingenuous. I will continue to give them that benefit of the doubt until I see clear proof to the contrary. craig -- craig sanders
Re: LICENSES [was: Re: Have you seen this?]
On 10 Oct 1998, Arnt Gulbrandsen wrote: Sorry, I must be too tired. I misread a paragraph of yours, so some of my previous message probably don't make much sense. You say that linking constitutes making a derived works of the object files and libraries being linked together. Does that mean that you think Debian should convert libc and so on from the LGPL to the GPL in order to comply with the license of the GPL'd applications in main? as mentioned at least once before, glibc is distributed with the operating system. therefore the special exception applies. how many times do we have to chase this one around? this hair-splitting is just a distraction from the real question. see previous messages for details. craig -- craig sanders
Re: LICENSES [was: Re: Have you seen this?]
On Sat, Oct 10, 1998 at 05:17:55AM +0200, Arnt Gulbrandsen wrote: Sorry, I must be too tired. I misread a paragraph of yours, so some of my previous message probably don't make much sense. You say that linking constitutes making a derived works of the object files and libraries being linked together. Does that mean that you think Debian should convert libc and so on from the LGPL to the GPL in order to comply with the license of the GPL'd applications in main? The GPL'ed apps require that the work as a whole must be distributable under the terms of the GPL. Do you think that means that I have to re-license the individual parts? If I say, do what you want with my code, and you incorporate it in a GPL app, do you relicense my work? No, and you can't, because you're not the copyright holder. You license the whole work as GPL, but still anyone can take my code and do what he wants. The GPL is more restrictive than my Public Domain License, which is okay. Does this clear things up a bit? Marcus -- Rhubarb is no Egyptian god.Debian GNU/Linuxfinger brinkmd@ Marcus Brinkmann http://www.debian.orgmaster.debian.org [EMAIL PROTECTED]for public PGP Key http://homepage.ruhr-uni-bochum.de/Marcus.Brinkmann/ PGP Key ID 36E7CD09
Re: LICENSES [was: Re: Have you seen this?]
Marcus Brinkmann [EMAIL PROTECTED] The GPL'ed apps require that the work as a whole must be distributable under the terms of the GPL. No. It's stricter, it requires that the distribution of the whole must be on the terms of this License. That is, distribut_ed_, not distribut_able_. Big difference. Do you think that means that I have to re-license the individual parts? If the GPL said what you said in the first sentence, then I would not think so. ... The rest doesn't matter, really, what with this basic -ed/-able problem. I'm going home now. Too tired to write clearly. --Arnt
Re: LICENSES [was: Re: Have you seen this?]
Arnt Gulbrandsen [EMAIL PROTECTED] writes: Craig Sanders [EMAIL PROTECTED] that's almost the exact opposite of what the GPL says. from clause 3 of the GPL: I've read clause three, thank you. I'll upper-case the bit you must have missed: 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. the last sentence, from However, as a special exception is particularly relevant here. It's clear that (e.g.) libc accompanies (e.g.) /bin/ls in Debian: They Considering the size of the .deb for fileutils, I think you are mistaken. Otherwise .deb's are packed extremely well :-) In case you haven't caught the point yet, does accompany not cater for whats distributed on some media or other, but whats distributed as a whole. Just like you (normally) don't accompany people in other cars, but (again normally) those in the car you're driving. are both in main, and the package maintainer makes sure you get libc when you get /bin/ls. If you also think that libc is a section of (see section two) /bin/ls and so on, then the conclusion is clear: You're in contravention of the GPL as you read it. Grasping for straws? -- /Wegge
Re: LICENSES [was: Re: Have you seen this?]
Craig Sanders [EMAIL PROTECTED] as mentioned at least once before, glibc is distributed with the operating system. therefore the special exception applies. It applies to applications that are not distributed with the operating system (and to other applications that are distributed along with, in this example, glibc). how many times do we have to chase this one around? Until we agree on what accompany (the critical word in the GPL) means, I guess. Do you agree that glibc accompanies ls if both are distributed as part of, say, a Debian 2.0 CD? --Arnt
Re: LICENSES [was: Re: Have you seen this?]
On Sat, 10 Oct 1998, Marcus Brinkmann wrote: The GPL'ed apps require that the work as a whole must be distributable under the terms of the GPL. Do you think that means that I have to re-license the individual parts? Will Debian remove Motif linked XEmacs from their ftp server? According to several Debian developers Motif is not a part of the OS. Will Debian remove LyX from their ftp server? According to several Debian developers Xforms is not a DFSG compatible library. Yours, -- martin // Martin Konold, Herrenbergerstr. 14, 72070 Tuebingen, Germany // // Email: [EMAIL PROTECTED] // Anybody who's comfortable using KDE should use it. Anyone who wants to tell other people what they should be using can go to work for Microsoft. [EMAIL PROTECTED]: BCPL gave birth to B, and the child of B was of course C, since the ancestor of X is W, so the sucessor to X must be K.
Re: LICENSES [was: Re: Have you seen this?]
Martin == Martin Konold [EMAIL PROTECTED] writes: Martin Will Debian remove Motif linked XEmacs from their ftp Martin server? According to several Debian developers Motif is Martin not a part of the OS. No. We don't link xemacs with Motif. Besides, since lesstif is a part of the OS, we can and do link any Motif applications we can with it. Martin Will Debian remove LyX from their ftp server? According to Martin several Debian developers Xforms is not a DFSG compatible Martin library. This is a harder one. :) xforms is in the non-free distribution of Debian, which technically makes it not part of the operating system. I'm not sure how that interacts with the GPL. Ben Gertzfield, Debian Developer -- Brought to you by the letters V and P and the number 9. If you turn both processors off, you will have to reboot. -- The Be Book Debian GNU/Linux -- where do you want to go tomorrow? http://www.debian.org/ I'm on FurryMUCK as Che, and EFNet and YiffNet IRC as Che_Fox.
Re: LICENSES [was: Re: Have you seen this?]
On 9 Oct 1998, Ben Gertzfield wrote: cheThis is a harder one. :) xforms is in the non-free distribution of cheDebian, which technically makes it not part of the operating chesystem. I'm not sure how that interacts with the GPL. People keep telling me that you can distribute it with the GPL if a caveat is included. Of course this GPL with a caveat is not quite the GPL . If you use plain-vanilla GPL, then you aren't talking sense. I have seen software other than KDE with this problem. I didn't check further, but some of them probably have other pieces of GPL code. To do it right, you need to get each copyright holder licensing her code under GPL to allow the code to be distributed under another license, ie, the GPL+caveat. If you have a lot of code and a lot of sources, this could be a PITA. John John Lapeyre [EMAIL PROTECTED] Tucson,AZ http://www.physics.arizona.edu/~lapeyre
Re: LICENSES [was: Re: Have you seen this?]
On Fri, Oct 09, 1998 at 06:36:12PM -0700, Steve Lamb wrote: the last sentence, from However, as a special exception is particularly relevant here. So, if Qt were disttributed with the OS then it would fall under the special exception? :) Some people argue that it would. RMS argues that to wouldn't in the case of Linux at least, however none of that matters since Debian does not and will not ever make Qt part of Debian. Personally, I would just like the KDE people to admit that at least in some cases, linking with Qt isn't going to work with the GPL. Some of the core developers and all of the Troll Tech people refuse to do this because they don't want to deal with asking for permission. Or rather, they refuse to admit they need to. Even if some sign was handed down from some divine power saying that KDE needed an exception to link with Qt, they would not admit it even then. Truth is, both Redhat and Debian say that KDE does need permission. Redhat won't distribute Qt because they don't like it. Debian won't distribute Qt because it's non-free. At least on both Redhat and Debian, according to Slashdot the two biggest distributions, won't include Qt as a standard part of their distributions. On those distributions, Qt is not a system library. It could be argued that it's not on SuSE or Caldera either, but I'm not going to touch that argument now since the point is that at least SOMEWHERE, KDE linked with Qt can't be distributed. Now, I won't install Qt even for the parts of KDE I like. (I don't like KDE as a whole integrated answer to life, the universe, and unix GUIs) If Troll Tech does something like make Qt compatible with the stock GPL when linked with the stock GPL, I'll consider it. However, they are under no obligation to do so, and I'm not one of those who advocate forcing them to give away Qt. If harmony ever manages to see the light of day and KDE does not intentionally break KDE with harmony any time there's a good excuse to do so, I'll probably use those parts of KDE I like with harmony. This is a long way off I suspect. If I could code worth a damn, I'd be helping harmony rather than writing these silly emails. Instead, I'd rather see KDE available to anyone who wants to use it, including Debian users. I've offered several times to help KDE get the permission it needs to link Qt on slashdot and a couple more times on irc. If KDE is willing to try and fix the problem, I'm willing to help them even if I won't use the results myself. Why would I do this? Because KDE is too big a project, too useful to too many people, and all around too important to be killed because of uncertainties in licenses and people's stubbornness. So far, none of the core KDE developers has been willing to admit there is even any controversy to the whole KDE/Qt thing with the exception of Stephan Kulow. Ignoring the controversy won't make it go away. It won't make KDE any better. It won't make KDE any more popular. In fact, it makes more people reject the whole KDE project because it seems pretty clear that the only thing we're hearing from any of the core developers is that there is no problem and if there is we're imagining it. I know that if any code of mine were ported to KDE without my permission, I would be extremely pissed off about it. Whether I'd give permission or not, not asking would anger me quite a bit. What's wrong with This software is Free Software and may be used according to the terms of the GNU General Public License version 2 or, at your option, any later version. Additionally, you may link this software with the Qt widget library written by Troll Tech AS, even for platforms on which use of the Qt library would normally be prohibited. That solves any question of whether or not you can link Qt. Of course, you'll still have to get permission for GPL programs which are ported to KDE, but I've already offered to help with that myself. pgpYGiqnRjjEW.pgp Description: PGP signature
Re: LICENSES [was: Re: Have you seen this?]
On Sat, Oct 10, 1998 at 04:56:23AM +0200, Marcus Brinkmann wrote: Let me try to make some qualified guess about this: If KDE would add the permission note, they would admit that there is a license problem, and they had to stop sucking in GPL'ed third party code without explicit permission by the authors. They'd have to admit that there is at least a possible situation in which a binary of a GPL program linked with the Qt library might undistributable under the terms of the GPL. Which is true---in at least some cases, there is a problem. Debian and Redhat are two such cases. Seems that KDE has either an attitude problem or they are scared that there wouldn't be too much support for them if they had to ask for permission to link with a non-free library each time they incorporate foreign code. The FSF at least, would deny such permission for certain. Most people who just released their code under the GPL because it's cool to GPL your code probably would not object to that exception however. The point being that it still needs to be asked for. If KDE is unwilling, all I can say is I hope harmony is usable soon, before a few of the core developers who want to be anal about it and pretend there is no problem at all kill their own project. To all of those who would simply say KDE sucks, just use Gnome, I say if I wanted someone else to tell me what I should or shouldn't use, I'd run windoze. The fact that I choose not to use Qt has no bearing on my right to choose it if I wanted to. However, I wouldn't pretend that there is no problem at all with using the GPL and Qt together. KDE has known about this problem for some time now. That they haven't even tried to address it saddens me a great deal. pgpiW38nastQu.pgp Description: PGP signature
Re: LICENSES [was: Re: Have you seen this?]
On Sat, Oct 10, 1998 at 05:14:19AM +0200, Martin Konold wrote: On 10 Oct 1998, Arnt Gulbrandsen wrote: All this is just splitting hairs, though. The real question is what is KDE's problem with just adding that additional permission to their license? How does it hurt them to do that? Is that really not obvious to you? Craig Sanders and some debian people wanted to play simple tricks ;-) No tricks, we see what we believe to be serious issues. We'd like those issues resolved. More than a few of us have nothing against KDE (I won't say none of us do because that would be a lie) but we still recognize the need to deal with what to us seems like a messy issue. The only way Debian could deal with it is by removing KDE from Debian. A few are not sad to see it go, a few are, and a good number figure that it doesn't matter since Debian packages are available elsewhere. I think it's too bad it had to be removed personally. I'd like to see it returned to the contrib section for now, and I'd even more like to see it in main. Contrib won't happen till the license problem is hashed out, even those who didn't want to see KDE go agreed that it had to because of those issues. Main won't happen as long as KDE depends on non-free software (Qt). KDE has said they wouldn't use a Qt replacement if it were given to them, already functional. We take this to mean KDE has no intention to remove the dependancy on Qt which is clearly non-free according the the DFSG. That KDE has known about the license problem for some time and does nothing had to finally be taken as KDE has no desire to try and fix the problem and in fact refuses to admit the problem is there because of what it would mean to them. It's really a shame KDE chose the GPL. Many BSD people will tell you the GPL is the most restrictive free software license there is. It's the only widely used free license that prohibits use with a library like Qt under any circumstances at all. No special exception for system libraries, but rather the code is free and use it how you want. pgp5EFT9k8HNN.pgp Description: PGP signature
Re: LICENSES [was: Re: Have you seen this?]
On Sat, Oct 10, 1998 at 12:35:31PM +1000, Craig Sanders wrote: non-free license. Neither I, nor anyone sensible, has any argument with TT's license...it's their software, they can do what they like with it.) That doesn't mean everyone else ise sensible. I've seen many people DEMAND Troll Tech release Qt under the GPL. I wanted to take a large cluebat to their heads for the reasons you cite above. pgpo9WU5R5bIr.pgp Description: PGP signature
Re: LICENSES [was: Re: Have you seen this?]
On Fri, 9 Oct 1998, Joseph Carter wrote: On Sat, Oct 10, 1998 at 12:35:31PM +1000, Craig Sanders wrote: non-free license. Neither I, nor anyone sensible, has any argument with TT's license...it's their software, they can do what they like with it.) That doesn't mean everyone else ise sensible. I've seen many people DEMAND Troll Tech release Qt under the GPL. I wanted to take a large cluebat to their heads for the reasons you cite above. i agree. people who bash Troll over Qt are missing the point. Worse, they are clouding the issue. IMO, Troll Tech are beyond reproach. they wrote a good library, and they allow people to use it for free in certain circumstances. while i would be happy to see it under an Open Source-compatible license, nobody has any right to demand that they do anythingthat's like demanding caviar from a good neighbour when they give you a sandwich. the only right you have here is to choose to accept their generosity or choose not to accept it. I personally choose not to accept it (the license isn't compatible with what i want to do with free software...also, I don't like C++ :), but i'm grateful for the offer all the same. craig -- craig sanders pgpjHZcwiFO6o.pgp Description: PGP signature
Re: LICENSES [was: Re: Have you seen this?]
Martin Konold [EMAIL PROTECTED] writes: Will Debian remove Motif linked XEmacs from their ftp server? I don't believe that Debian *has* a Motif-linked XEmacs on their ftp server, but if they do, then all it should take to get it removed is to file a bug report. That's what happened to KDE. Violations of policy (and law) are considered bugs. Some individual may have had a grudge against KDE which motivated them to file the bug report against KDE, but that doesn't mean that Debian is part of some anti-KDE conspiracy. Will Debian remove LyX from their ftp server? According to several Debian developers Xforms is not a DFSG compatible library. LyX is in contrib. I don't have it installed, but if it is licensed under the GPL, then you're probably right, and you're free to file a bug report against it. If you don't want to do so, then I'll check it out and file the bug report myself if needed. If you (or I) file a bug report against LyX and it *doesn't* get removed (or recompiled with a more appropriate library if possible), *then* you'll have a reason to complain that Debian is playing favorites. As it is, Debian is run by volunteers, who don't always have time to track down every nit in the system, which is why the bug reporting system exists. I'm not a free software fanatic (I use Debian because I like the packaging system and menu system), but I honestly do *not* understand why the KDE team objects to clarifying the KDE license to explicitly allow linking with Qt. Care to elaborate? -- Chris Waters [EMAIL PROTECTED] | I have a truly elegant proof of the or [EMAIL PROTECTED] | above, but it is too long to fit into http://www.dsp.net/xtifr | this .signature file.
Re: LICENSES [was: Re: Have you seen this?]
On Sat, Oct 10, 1998 at 05:17:55AM +0200, Arnt Gulbrandsen wrote: Sorry, I must be too tired. I misread a paragraph of yours, so some of my previous message probably don't make much sense. You say that linking constitutes making a derived works of the object files and libraries being linked together. Does that mean that you think Debian should convert libc and so on from the LGPL to the GPL in order to comply with the license of the GPL'd applications in main? Not at all, LGPL code is considered to be GPL'd when linked with other GPL code. However, X licensed code can also be linked with GPL'd code because its terms are more flexable than the GPL terms, so meeting the GPL's requirements is not an issue. The GPL is pretty much compatible with all the major Free Software licenses (Qt is not Free Software, nor do I argue that Troll Tech has any obligation to make it so) however it is the only Free Software license that is so totally incompatible with non-free software licenses. (By definitions of Free, I am using the DFSG) Other examples of Free licenses include BSD, Artistic (a personal favorite), X, LGPL, etc. From the FSF perspective, the GPL is more free' because it keeps software more pure. From the BSD camp, the BSD, X, and similar licenses are more free because they don't have the GPL's restrictions to keep them pure and you can literally use BSD/X license code in any way you want and with anything else you want. Of course, nobody says you can't license the code as GPL, but you can also ... In fact, that's one of the things that would put KDE back in Debian. Of course, you'd have to ask for example the people who wrote ghostview for permission to do the same with their code, but I have already offered to help with trying to get such permission of KDE wishes to make an effort to resolve this mess. Harmony would solve the whole damned problem, but it's hardly usable now for ANY purpose AFAICT, and I don't see that changing in the near future. = pgpgCgEQLiOqm.pgp Description: PGP signature
Re: LICENSES [was: Re: Have you seen this?]
On Fri, Oct 09, 1998 at 08:56:30PM -0700, Ben Gertzfield wrote: Martin Will Debian remove LyX from their ftp server? According to Martin several Debian developers Xforms is not a DFSG compatible Martin library. This is a harder one. :) xforms is in the non-free distribution of Debian, which technically makes it not part of the operating system. I'm not sure how that interacts with the GPL. Badly, as a matter of fact. This issue is being resolved with the lyx people and will probably result in GPL-but-you-can-also-link-xforms. The problem is not specific to KDE, nor do we pretend it is. However, so far only KDE has generally ignored us when we have tried to ask them about the license problems. Many of us took a wait-and-let-them-deal-with-it approach with all of these packages. KDE has opted NOT to deal with it, at least so far. Other projects have fortunately been easier to work with on this issue. pgpL2QEPkAU9F.pgp Description: PGP signature
Re: LICENSES [was: Re: Have you seen this?]
On Sat, Oct 10, 1998 at 05:42:53AM +0200, Arnt Gulbrandsen wrote: Marcus Brinkmann [EMAIL PROTECTED] The GPL'ed apps require that the work as a whole must be distributable under the terms of the GPL. No. It's stricter, it requires that the distribution of the whole must be on the terms of this License. That is, distribut_ed_, not distribut_able_. Big difference. So? What exactly is the difference, please explain it to me. Does it say you must license the whole and individual parts under the GPL? No. Does it say: All parts must be GPL'ed? No. If you have multiple parts of a whole, you can opnly distribute it (if at all) under the terms of the most restrictive license. The GPL text says, that no license is allowed to be more strict that the GPL. It does say Thus, it is not the intent of this section to claim rights or contest your rights to work written entirely by you; rather, the intent is to exercise the right to control the distribution of derivative or collective works based on the Program. So, why do you always quote out of context and try to narrow the issue to a single word? Is the full text of the GPL unavailable to you? I can send you a copy, if you want. If you mix GPL with Public Domain, the whole must be distributed under the terms of the GPL. But *nothing* and *nobody* claims that the PD part must be GPL'ed to do this, nor does it say that you can't rip the PD part out again and do with it what you want. As a side issue: The PD may not be the best example, as PD is explicitely not copyrighted at all. You may want to use BSD style licenses as a better example, or X license. Do you think that means that I have to re-license the individual parts? If the GPL said what you said in the first sentence, then I would not think so. The single word doesn't make the difference. Read again, and read also the paragraph that follows. Marcus -- Rhubarb is no Egyptian god.Debian GNU/Linuxfinger brinkmd@ Marcus Brinkmann http://www.debian.orgmaster.debian.org [EMAIL PROTECTED]for public PGP Key http://homepage.ruhr-uni-bochum.de/Marcus.Brinkmann/ PGP Key ID 36E7CD09
Re: LICENSES [was: Re: Have you seen this?]
Arnt Gulbrandsen wrote: The key is in an earleir paragraph. These requirements apply to the modified work as a whole. If identifiable sections of that work are not derived from the Program, and can be reasonably considered independent and separate works in themselves, then this License, and its terms, do not apply to those sections when you distribute them as separate works. In my opinion, Qt is not a section of KDE, it is not derived from the KDE and it must be considered independent and separate from the KDE. In other words: The KDE's usage of the GPL does not cause the GPL, and its terms, to apply to Qt. So, in your opinion, a library (QT) that is dynamically linked to an application (KDE) is not a part of that application? If I got you right why do your company state (on your QT Free Edition FAQ 5) that you can't link a non-GPL'ed application to a GPL'ed library? I think that is inconsistent, either the library is part of the application (both have to be GPL'ed) or it isn't (both don't have to be GPL'ed). From section 3 of GPL (i've capitalised the important part): 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. Doesn't that mean that if I distribute an executable dynamically linked with QT under GPL, I also have to distribute the QT header files under GPL. But maybe I can (I haven't read the QT Free Edition License), maybe you can enlighten me. So if I can't distribute QT header files under GPL, GPL'ed applications can't be linked with QT. Right? Mattias Evensson
Re: LICENSES [was: Re: Have you seen this?]
Arnt Gulbrandsen [EMAIL PROTECTED] writes: Craig Sanders [EMAIL PROTECTED] as mentioned at least once before, glibc is distributed with the operating system. therefore the special exception applies. It applies to applications that are not distributed with the operating system (and to other applications that are distributed along with, in this example, glibc). how many times do we have to chase this one around? Until we agree on what accompany (the critical word in the GPL) means, I guess. Do you agree that glibc accompanies ls if both are distributed as part of, say, a Debian 2.0 CD? No. That's a case of mere aggregation. It's possible, without any problems at all, to get either glibc or fileutils, without getting both. -- /Wegge
Re: LICENSES [was: Re: Have you seen this?]
It's clear that (e.g.) libc accompanies (e.g.) /bin/ls in Debian: They are both in main, and the package maintainer makes sure you get libc when you get /bin/ls. If you also think that libc is a section of (see section two) /bin/ls and so on, then the conclusion is clear: You're in contravention of the GPL as you read it. The LGPL is GPL compatible. You seem to be being deliberately vacuuous
Re: LICENSES [was: Re: Have you seen this?]
In my opinion, Qt is not a section of KDE, it is not derived from the KDE and it must be considered independent and separate from the KDE. In other words: The KDE's usage of the GPL does not cause the GPL, and its terms, to apply to Qt. Indeed Qt is not part of the problem But when you distribute the same sections as part of a whole which is a work based on the Program, the distribution of the whole must be on the terms of this License, whose permissions for other licensees extend to the entire whole, and thus to each and every part regardless of who wrote it. Qt is not distributed as part of KDE. It is distributed as part of various distributions that also include the KDE, but only by mere aggregation [...] on a volume of a storage or distribution medium which the GPL okays elsewhere in the text. It is not a mere aggregation. If I remove Qt KDE is unusable. Furthermore your discussion with Preston Brown re legal issues clearly shows you believe that the question of inline code is a matter of IPR and potential lawsuits therefore you clearly believe the inline C++ code linked by KDE from Qt code is a component KDE requires Qt currently. So KDE is non free. Similarly Linus does not distribute KDE with the kernel so its not in the base distribution. On Solaris KDE is shipped even though no Sun product includes Qt. So the case there is even more blatant
Re: LICENSES [was: Re: Have you seen this?]
If I say, do what you want with my code, and you incorporate it in a GPL app, do you relicense my work? No, and you can't, because you're not the Yes, you create a combined work bound by the GPL. And the GPL permits components of a GPL'd item to be freer than GPL (by the GPL definition of free) copyright holder. You license the whole work as GPL, but still anyone can take my code and do what he wants. The GPL is more restrictive than my Public Domain License, which is okay. Correct. Actually you should never ever use public domain. Even if you want something to be Do as you wish, because stating something is public domain in some jurisdictions does not exempt you from legal liability, and an exemption from legal liability clause means its not public domain Fun .. not
Re: LICENSES [was: Re: Have you seen this?]
files and libraries being linked together. Does that mean that you think Debian should convert libc and so on from the LGPL to the GPL in order to comply with the license of the GPL'd applications in main? Arnt if you stuck to using facts you might be able to have a sensible discussion The combined work is GPL. Who cares. The LGPL permits an LGPL work to be part of a GPL work, so from the view of a GPL'd ls, yes the dynamically linked ls is a GPL item, and the libc in it is binding to that license, but the libc on its own is not GPL its LGPL This is first year intellectual property law stuff
Re: LICENSES [was: Re: Have you seen this?]
The GPL'ed apps require that the work as a whole must be distributable under the terms of the GPL. Do you think that means that I have to re-license the individual parts? Will Debian remove Motif linked XEmacs from their ftp server? According to several Debian developers Motif is not a part of the OS. Will Debian remove LyX from their ftp server? According to several Debian developers Xforms is not a DFSG compatible library. Unless XForms and XEmacs work with Lesstif and the clone forms libraries then I'd agree
Re: LICENSES [was: Re: Have you seen this?]
However, the license for that derived work (I'll call it A) claims that the whole of A must be GPL'd. However, Qt is not part of A (the GPL says section of). Qt provides services to A, and A depends on those services: A very different thing. Qt is part of the derived work. It is linked to it and the work A does not function without it. It is also not a public API and your message to Preston concerning possible legal action against harmony makes it clear you regard the item as actively protected IPR not an open API
Re: LICENSES [was: Re: Have you seen this?]
It's really a shame KDE chose the GPL. Many BSD people will tell you the GPL is the most restrictive free software license there is. It's the only widely used free license that prohibits use with a library like Qt under any circumstances at all. No special exception for system libraries, but rather the code is free and use it how you want. A BSD license would have solved the problem nicely. No GPL code would have been available to be stolen (subject to your license viewpoint) and no GPL authors upset. And by now Sun would no doubt be shipping a binary only KDE that forbid you to redistribute it and contained fixes you couldnt get back off them
Re: LICENSES [was: Re: Have you seen this?]
On Sat, Oct 10, 1998 at 05:29:08PM +0100, Alan Cox wrote: In my opinion, Qt is not a section of KDE, it is not derived from the KDE and it must be considered independent and separate from the KDE. In other words: The KDE's usage of the GPL does not cause the GPL, and its terms, to apply to Qt. Indeed Qt is not part of the problem Thank you Alan, a few people still seem to believe otherwise. Care to borrow a few cluebats? You're going to need them. While Qt's license does not help matters much by saying that it may be used with GPL'd software, there is nothing wrong with it saying so, realizing of course that the GPL'd software in question must expressly permit its use since Qt is not available on every platform as part of the base system. Motif is on Solaris, but that's Motif and Solaris. The issue for Debian is Debian GNU/Linux and Qt, which by Debian's social contract will never be included as part of the base system. This means at least for Debian GNU/Linux, binaries cannot be distributed linked with Qt without express permission. That's why Debian had to remove KDE. Qt is not distributed as part of KDE. It is distributed as part of various distributions that also include the KDE, but only by mere aggregation [...] on a volume of a storage or distribution medium which the GPL okays elsewhere in the text. It is not a mere aggregation. If I remove Qt KDE is unusable. Furthermore your discussion with Preston Brown re legal issues clearly shows you believe that the question of inline code is a matter of IPR and potential lawsuits therefore you clearly believe the inline C++ code linked by KDE from Qt code is a component I really, truly, and honsetly believe the whole notion that the GPL does not apply to Qt because Qt is merely used by the program and not part of it is merely an attempt to find any possible justification for not fixing the problem in the KDE license--that the GPL prohibits someone to derive a work of another's program which is dependant on non-free software that is not an essential part of the system. Qt is clearly not an essential system library nor is it even a standard system library. It's a piece of non-free code owned by Troll Tech and licensed how Troll Tech chooses to license it, as is their right. Because the GPL does not by default allow people to do this, additional rights to link Qt are required. KDE is unwilling to admit that. If they are willing to admit that at least the possibility exists for Qt not to be a standard system library as it's clearly not in Debian's case, I have offered to help them get the permission they need from other sources. That offer stands, if they are willing to make an effort to fix the problem at all. KDE requires Qt currently. So KDE is non free. Similarly Linus does not distribute KDE with the kernel so its not in the base distribution. On Solaris KDE is shipped even though no Sun product includes Qt. So the case there is even more blatant This would place KDE in Debian's contrib section---not part of Debian, but it would be distributed as free-but-depends-on-non-free software. This is where KDE was, until KDE would not deal with the legitimate claim that there was at least a potential problem without giving permission to link Qt and geting it themselves for things they've ported. Debian feels that it's shaky ground for KDE to not give explicit permission to link Qt, especially since Debian does not include Qt. Debian feels that KDE refuses to fix the problem because they do not wish to get the permission the GPL code they have ported requires them to get, for fear they would not get that permission or that KDE would be considered to be non-free software. As for Sun, they don't earn my respect by further abusing the GPL. I think until I see differently I will consider them in line with Caldera and SuSE. Ie, they have no respect for the GPL or the code written by people who were not even asked if their code could be ported to a non-free library. And I can see that at least three or four of KDE's core developers have the same respect for the GPL, none. People who will not respect the GPL are its true enemies. M$? Big deal, they wouldn't touch GPL code because they wouldn't want to become dependant on something that could require them to rewrite massive amounts of their code or GPL code they had written. The enemy who says he is your enemy is always less dangerous than the enemy who claims to be your friend. And yet, I would help them do the right thing, if they were willing to do it at all, because that would show me they had either enough respect for the GPL to ask for the required permission--or at least realize that they have to ask for it if they wants support from Debian and most of those who DO respect the GPL. KDE would have been better off with the LGPL or with the Artistic license (a personal favorite) IMO. It wouldn't help them with problems like kghostview but it would at
Re: LICENSES [was: Re: Have you seen this?]
On Sat, 10 Oct 1998, Alan Cox wrote: [..] A BSD license would have solved the problem nicely. No GPL code would have been available to be stolen (subject to your license viewpoint) and no GPL authors upset. And we'd all probably be better off. And by now Sun would no doubt be shipping a binary only KDE that forbid you to redistribute it and contained fixes you couldnt get back off them Ehm, the world hasn't gone to hell because not everything is GPL. Take for instance companies using FreeBSD, such as Whistle and Best Internet Communications. Both have tweaked fbsd throughly, and kicked back quite a few fixes and their other changes, without being legally obligated to release all of their source. Keep in mind it would be in Sun's best interest to help the KDE developers, as taking a BSD licensed KDE and running with it themselves would take a lot more effort. Your the world outside of GPL is evil attitude is quite bogus. - alex
Re: LICENSES [was: Re: Have you seen this?]
And by now Sun would no doubt be shipping a binary only KDE that forbid you to redistribute it and contained fixes you couldnt get back off them Ehm, the world hasn't gone to hell because not everything is GPL. Take for instance companies using FreeBSD, such as Whistle and Best Internet Communications. Both have tweaked fbsd throughly, and kicked back quite a few fixes and their other changes, without being legally obligated to release all of their source. And lots of people haven't kicked stuff back. Why doesn't *BSD run on an SGI Indy - its because the BSD license didnt force all the neat stuff to be contributed back. And there are thousands of other examples like it. I've worked for big coporations, I was involved in a project using netbsd that died because the BSD advertising clauses for NetBSD were to obnoxious to be workable. Other than that I can assure you the project would have shipped, would have networking fixes that kicked the crap out of original netbsd and not one line of the code would ever have been contributed back Your the world outside of GPL is evil attitude is quite bogus. I don't know where you got that from. But its not my attitude.
