Mhm? My understanding of the "field of endeavour" clause is that I'm not allowed to forbid (for example) it's use by the government (or doctors, or...)
Besides, if you used the GPL for a library it would force the SAME conditions on users (except for clause 6c of the QPL)
I attach an excerpt from the kde-licensing archive, to show that there are KDE people trying to mediate this conflict.
Personally I don't think that there's a conflict, as I don't see Qt as part of KDE or KDE programs.
List: kde-licensing Subject: Re: Liscencing Issue - Taking Action From: forge Date: 2000-06-14 2:43:36 Don Sanders wrote: > > > There is some misunderstanding about section 6, subsection 2 of the > > QPL. > > Yes, I've seen that. > > > Could it be made clear somehow that "distribution" means the same thing > > in the QPL as it dose in the GPL ? > > Well if you have a suggestion I'm listening, but I'm not to sure how much > more clearer than you can get than by using the same word, ie "distribution".
I mislabeled the offending section of the QPL. It's section 6c.
6. You may develop application programs, reusable components and other software items that link with the original or modified versions of the Software. These items, when distributed, are subject to the following requirements:
c. 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.
Section 6c is subject to section 6 which means it applies when your software is distriuted. If memory serves, it is for those times when the author redifines "distribute" to not include sending the software to 50,000 BETA testers or making it availeble "only" to members of the AMA or a none US afiliate. I wold fix it by stating it this way.
<Forge's 6c>
c. 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.
c1. As a special exemption, if your software is distributed under the GPL and you can demonstrate that your distribution dose not violate the GPL in any way you do not have to send us a copy of your software.
Note that by distributing your software under the terms of the GPL you agree that any holder of a copy may redistribute without fear of retribution.
This basically says hey, we are making demands but they don't apply if your stuff is under the GPL. However the GPL says you can't dismiss an employee for "redistributing" GPLed software. It's a bluff. Who wants to call it? Maybe that last paragraph doesn't belong in the actual license.
Don't forget that there's the Free-KDE-Qt-Foundation, so in the unlikely case that TT would stop updating the Free Edition of Qt, the last free version would automatically be released under the BSD license!
You've nicely described The Great KDE Conspiracy, could you now be so kind as to name the conspirators, or don't you dare because the would surely send their hitsquads for you if you did?
It started off as the Kool Desktop Environment, which obviously is a pun on CDE. Since Kool is rather uncool;) nowadays it's just "K Desktop Environment", although I'd prefer a recursive acronym "KDE Desktop Environment". Ah well, I guess it's just like eight megs and continually swapping... you just take what you like *g*
There is a styleguide, and it says that the label should be "OK" (although I seem to remember it called for the label to be "Close" in past editions *mhm*).
That doesn't mean that the styleguide can't be changed (after due review) if it is inconsistent or broken in some aspect (and some sections aren't finished yet).
Well, I can tell you from experience that a lot of things happening/being done in open source projects are NOT the result of conscious choices, but are rather done at 3am after having the 4th pot of coffee, if you you get my meaning;-)
Mistakes happen, style guides are not read before implementing a particular feature etc.
That's where someone like Linux QA from Corel comes in handy, if even if something WAS a conscious decision by one of developers, the bug report allows us to peer review that decision. Also not all developers have got the same level of knowledge regarding UI design, you've always got to remember that KDE developers come from all sorts of different backgrounds!
A user interface deficiency is a bug, plain and simple.
Now there's no chance a software will ever be completely bug-free, so shipping with a known deficiency may be ok, but that doesn't make it only a "wish".
Well, because kdelibs and qt are libraries that kmail depends on.
You won't have much luck with Mozilla either, if you haven't got gtk+ or libc.
As for "my original post was moderated up": my posts won't be moderated up because the story is too old, we all know what stories are actively moderated, and one two days old isn't among the likely list.
And what's the problem with downloading the tarball of the 1.1.2-kdenetwork? Sorry to say that, but to me you appear to be complaining for the sake of complaining.
And you don't HAVE to compile 6 apps, even if you don't use the nice "inst-app" file, you can still simply uncomment the other dirs in the Makefile after configure.
As for "fiddling with environment variables": yeah, you're completely right, setting two variables (KDEDIR and QTDIR) is just SOOOOO hard...
Sorry to say, but either you WANT it to be difficult, i.e. troll (though I don't think so really), or you construe things to be much more complicated than the really are.
Close, but no cigar. It has to be: KDE_1_2_STABLE CVS, and it has to be complemented with the individual apps also posted in simple tgz format. In addition, the individual apps in, for example, kdenetwork, should be available as individual tgz's. Why should you have to download and build 6 apps when you're only interested in one?
The branch is called KDE_1_1_BRANCH, that's the post 1.1.2 tree. I don't see why you've got a problem with that.
As for downloading 6 apps, well, you only have to do that once, and you NEVER have to compile every app. For KSysV development (meanwhile moved to KDE2), I never do that, I just compile kdeadmin/ksysv, and maybe kdeadmin/doc/ksysv.
The only thing I see getting in the way is core developers are not, at this point, willing to recognize that non-core developers have a big barrier to getting started - much bigger than most other open-source apps. Even mozilla is easier to download and compile than KDE, let alone individual KDE core apps which have to be dug out with considerable effort from a rather indimidating CVS tree.
Really, in what way is downloading & compiling KDE less easy than doing the same for Mozilla? There ARE snapshots of libs and app-packages available, and the next set of those will even contain CVS information, so you just need to update a specific directory from that on.
But why is it necessary to solve the problem by forcing a fork? Why not address the problem in the first place by having a well-defined fork a la the stable-vs-development strategy of the Linux kernel?
But there IS a KDE_1_1_STABLE branch in CVS! It's just that nobody used it after releasing 1.1.2 (besides some bug fixing).
Since KDE2 wasn't stable enough for me to develop KSysV, I continued to improve the 1.1.2 version. The result can be downloaded from here.
Now granted, I was the original author of KSysV and therefore had it a little easier, but it's not hard to grab KDE_1_1_BRANCH and make a standalone app out of some module.
I've got a Tyan Trinity 100 ATX (the new 1598S, with the MVP4 South(?)bridge) and a Matrox G400 (cheap OEM version without dual-head/TV-out), and I have had only one problem so far: under Win98, until the 5.40.x driver, if I had 256MB RAM installed and "AGP aperture size" set to anything above 8 MB, the machine would crash shortly after Windows came up (this hasn't happened with Linux, neither with NT 4).
With the new drivers, everything works fine, even with the aperture size set to 128MB (the current BIOS of the board doesn't allow for more).
Slashdot Mirror
Mhm? My understanding of the "field of endeavour" clause is that I'm not allowed to forbid (for example) it's use by the government (or doctors, or ...)
Besides, if you used the GPL for a library it would force the SAME conditions on users (except for clause 6c of the QPL)
Huh?
Do you think before you type?
I mean just because something was in a Slashback doesn't make it more true...
Or it could just mean that it's indeed a fact that Debian sees problems with licenses.
The quoted mail is ambiguous.
Hey, YOU claimed something, not I!
Besides, you haven't even named a single person, let alone everyone supposedly working on that sinister conspiracy against The Free World (TM).
You sure sound a bit too much like one of those "communists/aliens/black helicopters are lurking behind every tree" guys for me...
I attach an excerpt from the kde-licensing archive, to show that there are KDE people trying to mediate this conflict.
Personally I don't think that there's a conflict, as I don't see Qt as part of KDE or KDE programs.
Yes, that was an exhaustive list of names, really.
Don't forget that there's the Free-KDE-Qt-Foundation, so in the unlikely case that TT would stop updating the Free Edition of Qt, the last free version would automatically be released under the BSD license!
You've nicely described The Great KDE Conspiracy, could you now be so kind as to name the conspirators, or don't you dare because the would surely send their hitsquads for you if you did?
Under current interpretation of copyright law, linking is considered making a derivative work.
You mean under current interpretations by Debian, don't you?
If not, I'd like to see some backup for this claim!
All major versions are of Qt are binary compatible, i.e. you can run apps linked to 1.40 with 1.44, 2.0 apps on 2.1 or 2.1.1
Obviously it doesn't work the other way, but since you can have both Qt 1.4x and Qt 2.x installed at the same time, it's not much of a problem...
Only partially correct.
;) nowadays it's just "K Desktop Environment", although I'd prefer a recursive acronym "KDE Desktop Environment". Ah well, I guess it's just like eight megs and continually swapping... you just take what you like *g*
It started off as the Kool Desktop Environment, which obviously is a pun on CDE. Since Kool is rather uncool
You could say it's simply the spelling in another language. Kopernikus and Kleopatra are correct spellings for those names in German...
:-)
Sorry, I forgot the URL: KDE Standards
There is a styleguide, and it says that the label should be "OK" (although I seem to remember it called for the label to be "Close" in past editions *mhm*).
That doesn't mean that the styleguide can't be changed (after due review) if it is inconsistent or broken in some aspect (and some sections aren't finished yet).
Well, I can tell you from experience that a lot of things happening/being done in open source projects are NOT the result of conscious choices, but are rather done at 3am after having the 4th pot of coffee, if you you get my meaning ;-)
Mistakes happen, style guides are not read before implementing a particular feature etc.
That's where someone like Linux QA from Corel comes in handy, if even if something WAS a conscious decision by one of developers, the bug report allows us to peer review that decision. Also not all developers have got the same level of knowledge regarding UI design, you've always got to remember that KDE developers come from all sorts of different backgrounds!
A user interface deficiency is a bug, plain and simple.
Now there's no chance a software will ever be completely bug-free, so shipping with a known deficiency may be ok, but that doesn't make it only a "wish".
But it's not the KDE Team that has got these problems, it's Dennis E. Powell aka "dep"!
He was ranting on the mailing list until enough told him that they didn't share his opinion and he should please stop spamming the list...
Well, because kdelibs and qt are libraries that kmail depends on.
You won't have much luck with Mozilla either, if you haven't got gtk+ or libc.
As for "my original post was moderated up": my posts won't be moderated up because the story is too old, we all know what stories are actively moderated, and one two days old isn't among the likely list.
And what's the problem with downloading the tarball of the 1.1.2-kdenetwork? Sorry to say that, but to me you appear to be complaining for the sake of complaining.
And you don't HAVE to compile 6 apps, even if you don't use the nice "inst-app" file, you can still simply uncomment the other dirs in the Makefile after configure.
As for "fiddling with environment variables": yeah, you're completely right, setting two variables (KDEDIR and QTDIR) is just SOOOOO hard...
Sorry to say, but either you WANT it to be difficult, i.e. troll (though I don't think so really), or you construe things to be much more complicated than the really are.
Instructions for Downloading & Installing KMail
Yes, the list is longer than for Mozilla. OTOH KDE IS much more than one app, it's an environment/application framework.
BTW: your comment about Qt needing to be "linked" certainly doesn't hold true for Qt-2.1.1, maybe you are confusing it with some earlier version?
Close, but no cigar. It has to be: KDE_1_2_STABLE CVS, and it has to be complemented with the individual apps also posted in simple tgz format. In addition, the individual apps in, for example, kdenetwork, should be available as individual tgz's. Why should you have to download and build 6 apps when you're only interested in one?
The branch is called KDE_1_1_BRANCH, that's the post 1.1.2 tree. I don't see why you've got a problem with that.
As for downloading 6 apps, well, you only have to do that once, and you NEVER have to compile every app. For KSysV development (meanwhile moved to KDE2), I never do that, I just compile kdeadmin/ksysv, and maybe kdeadmin/doc/ksysv.
The only thing I see getting in the way is core developers are not, at this point, willing to recognize that non-core developers have a big barrier to getting started - much bigger than most other open-source apps. Even mozilla is easier to download and compile than KDE, let alone individual KDE core apps which have to be dug out with considerable effort from a rather indimidating CVS tree.
Really, in what way is downloading & compiling KDE less easy than doing the same for Mozilla? There ARE snapshots of libs and app-packages available, and the next set of those will even contain CVS information, so you just need to update a specific directory from that on.
But why is it necessary to solve the problem by forcing a fork? Why not address the problem in the first place by having a well-defined fork a la the stable-vs-development strategy of the Linux kernel?
But there IS a KDE_1_1_STABLE branch in CVS! It's just that nobody used it after releasing 1.1.2 (besides some bug fixing).
Since KDE2 wasn't stable enough for me to develop KSysV, I continued to improve the 1.1.2 version. The result can be downloaded from here.
Now granted, I was the original author of KSysV and therefore had it a little easier, but it's not hard to grab KDE_1_1_BRANCH and make a standalone app out of some module.
Honestly I couldn't think of any "great insight" given by Nazi memorabilia... could you name any?
I've got a Tyan Trinity 100 ATX (the new 1598S, with the MVP4 South(?)bridge) and a Matrox G400 (cheap OEM version without dual-head/TV-out), and I have had only one problem so far: under Win98, until the 5.40.x driver, if I had 256MB RAM installed and "AGP aperture size" set to anything above 8 MB, the machine would crash shortly after Windows came up (this hasn't happened with Linux, neither with NT 4).
With the new drivers, everything works fine, even with the aperture size set to 128MB (the current BIOS of the board doesn't allow for more).
My system specs: Tyan Trinity 100 ATX (1598S), 256 MB PC100 SD-RAM, AMD K6-III 450, Linux, Win98, WinNT, WinTV/PCI TV-card, Mylex (ex-BusLogic) Flashpoint SCSI controller, 2 IDE hard-disks, 1 Mitsumi 40x CD-ROM, 1 SCSI hd, 1 Toshiba CD-R