1) All of your arguments apply to Linux and the GPL. (Can't produce a shareware version of Linux, can't develop hybrid license version of Linux, can't distribute freeware (no source) version of linux). The difference with QT is you can buy a license to develop proprietary software.
2) If you are going to make money by selling proprietary software what is wrong with the idea of having to give back some of that money to troll tech? (How much you can argue about but surely there is nothing wrong with giving something back!).
3)KDE symbolizes a Marxist approach to software development KDE development has no political or religious affinity. Each project can choose their own development model. Different projects contribute code under different licenses. Core development tends to be done on an anarchy/meritocracy basis.
Basically KDE development encourages Open Source development but allows proprietary development at a cost.
As I have mentioned before the document you reference http://pmitros.mit.edu/patchwork.html is obsolete. The QPL license does not require modifications to be distributed with the "patch" utility, a fact many of the arguments in patchwork.html assume.
In fact KDE is fully free software, as defined by the debian free software guidelines.
There are valid criticisms of the KDE licensing scheme that need to be heard (GPL/QPL incompatibility), by repeating these incorrect assertions you are simply causing unnecessary confusion.
Please read the QPL http://www.troll.no/qpl/plaintext.txt it is a very simple license.
Initially I read that as Australia had criminalised reverse engineering and took the rest of the posting as sarcasm. Still can't believe legislators would actually do something sensible.
Aah now I understand looks like this is already legal everywhere else (the article mentions this being legal already in Europe and USA) and concerns about fixing Y2K bugs bought the stupidity of criminalizing reverse engineering into light, bit late now though!
Re:Any chance of getting that into Emacs/Xemacs?
on
Changing the Keyboard
·
· Score: 1
Here is a way to get that functionality by binding Alt-Down and Alt-Up.
;Scroll buffer without moving point (defun scroll-down-line () "Scroll one line down." (interactive) (scroll-down 1))
(defun scroll-up-line () "Scroll one line up." (interactive) (scroll-up 1))
I agree there is an issue here. I'm not going to say whether the QPL is or isn't compatible with the GPL (Note for audience RMS who is far more civilized about the whole thing than many others says it isn't, others question this).
But assumming for the moment that they are incompatible, then I buy the argument that redistribution of KDE apps is legal so long as the authors haven't used GPL'd code without permission. Because the authors of said apps has given implicit permission (why else write a KDE app and put it on a public server and encourage people to redistribute it).
If someone wanted to do something useful they could make a list of questionable KDE apps (if any) and I would look into it further. (I'm sure we'll all be back here talking about it later in another KDE related article). But then again this is/., I suspect people would rather argue than do something more constructive here.
And that is why people try to convince the KDE developers to use another license Doesn't the KDE Artistic License just keep on getting more and more popular:-)
That is why we have the Harmoney project so we have a library that can be linked with KDE as a Qt replacement Not correct. Jo Dillon started the Harmony project before the QPL existed. He seems to be contributing more to KDE than Harmony nowadays so I guess he has found the QPL to remove the need for Harmony. (Note the Harmony list had been dead for months last time I checked)
The best solution would be if Troll Tech released Qt under a license that is compatible with the GPL. I don't agree, or at least I'm going to require a lot convincing before I agree. The QPL is a nice license whereas the GPL is something of a monstrosity (read both to see what I mean), I'm beginning to think it's the GPL that needs work.
Hell now that was funny, I've got to know was it intentional?
Technically speaking, much of KDE is illegal. One cannot legally link Qt and KDE together. Typical ignorant babble (The GPL permits linking, you probably want to complain about redistribution in which case I have an answer ready for you:-)
Anyway onto the funny part No one has sued yet, but if the author if Lyx chooses to sue every person using or distributing kLyx, it's in his rights. Well he would have to sue himself then. As Matthias Ettrich founded the Lyx project as well as (drumroll please....)
The person you replied to seems to be an idiot so I'm not taking their side, but what you're saying is wrong.
The incompatibilites at source level simply don't exist. Period. Blatantly false. The "Porting Code from 16-bit Windows to 32-bit Windows" section of the "Platform, SDK, and DDK Documentation" clearly states: "Although the Win32 API was designed to be as compatible as possible, you may need to modify a large amount of source code."
I now feel obliged to state that while i get paid for windows application development, I, of course, spend all of my friend time developing for Linux. The same as any other self respecting nerd.
Amongst other oddities Petzold Win3x example printing source code won't work on 95 (but the binaries will) and I doubt your average Win32 program ports easily to Wince. However it's much easier to port programs between versions of windows than versions of unix.
Just look at the state of threading for instance. Linux has good support for threading but other *nixes don't so code intended to be portable can't use it:-( I believe there is an ACE library that includes portably *nix threads but from all accounts ACE is bloated and complicated, most people opt to use a non threading solution, luckily this is almost always possible.
Developers would try to fix the big, prominent bugs instead of the smaller ones.
Yes, that would be the idea. Allow users to vote for what bugs should be fixed (money isn't even needed) hence allowing important bugs to be seperated from less important bugs.
But, small ones are often the hardest to fix. Isn't that the truth, lots of peope get really ticked off about the small things though.
Nice idea, but I don't think it will work. If a really believed in it I would implement myself. Things are working pretty well at the moment but I notice there isn't much incentive for developers to fix problems that don't affect them.
Hopefully competition amongst developers would stop this, if a developer starts introducing bugs just to get paid for fixing them someone else could fork the code or start up a new project. In this sense free software is a free market.
One way of rewarding open source developers would be to augment the Debian Bug Tracking software and allow users to offer a reward to the first developer who is able to close a bug. The user would make a maxmimum offer that is kept secret. The system would calculate the maxiumum reward, given that all bidders pay the same amount or nothing at all. After a bug has been fixed (or feature request satisfied) bidders who actually paid would be given a small bonus say an e-mail telling them the problem had been fixed, (and the developer would be forwarded the cash, a third party coud settle disputes).
Several large projects use the Debian Bug Tracking System and any/all of them could benefit from this idea, you wouldn't even need to use real money though using actual money would probably be more effective.
The main drawback with this system is that currently there is an atmosphere of good will and a sense of working towards a greater goal, money could spoil that and turn friends into enemies.
Imaginary definition and out of date claims
on
Red Hat Europe
·
· Score: 1
According to the Debian Free Software Guidelines QT is free software. You are making up your own definition for the word free and I don't share it.
Secondly the document you referenced (http://pmitros.mit.edu/patchwork.html) is obsolete. The QPL was changed months ago (before QT 2.0 was released) and the stipulation that the patch program must be used to distribute modifications has been removed.
For an objective critque of the license see my post here http://slashdot.org/comments.pl?sid=99/06/25/12462 58&cid=144
Please people take 2 minutes to read the QPL!
on
qt 2.0 released
·
· Score: 1
People please read http://www.troll.no/qpl/plaintext.txt and see the truth for yourself. The QPL is a very simple license. It is the simplest license I have ever read, it is much simpler than the GPL. It is simpler than many postings here on slashdot, it is simpler than this posting. It is in plain english. You will understand it much better by reading it than by reading postings here.
people are forbidden from distributing modified versions of QT No, no, no, no! I can't believe this crap has been ranked up. It is so blatantly false. Did you read the wrong license? Please follow my link.
Firstly distribution takes place as one of two forms either distribution of binaries or distribution of source code.
Clause 4 (of 6) allows you to distribute binaries of modified versions of QT under the following 3 conditions a) You must include the license document. b) You must make the source code available. c) You must place all your modifications under the same license (the QPL).
Note that the distribution of binaries under the QPL protects your freedoms better than the GPL does, because the QPL contains no "privacy loophole".
Clauses 2 and 3 (of 6) allows you to distribute modified versions of the source code. Clause 2 allows me checkout the original QT from any CVS repository (or copy it off any CD). Clause 3 allows me to CVS update (or apply a patch script on a tar file of modifications) to update to a modified version of QT (source code).
That is clauses 2 and 3 allow you to distribute modified versions of the QT source code under reasonable conditions. There is no problem here!
Okay onto your next point and their programs can't require a user to make changes to QT. A honestly don't understand what you are trying to say here. If your program requires the user to use a modified version of QT then distribute a binary version of your modified QT along with your program.
while the license is somewhat better, it ain't the GPL (any version); and I still have hope for the Harmony Project. I have news for you. 1) The GPL ain't perfect. 2) None of the Harmony Project source is under the GPL, it is under the LPGL.
Not that I'm against the harmony project, BTW.
If you are going to complain about the QPL please find something worthy of complaining about!
Now I'm no Troll Tech lackey. I admire the GTK toolkit and have great respect for those who developed it. If you are a GTK/GNOME supporter and want something to complain about, then complain about this:
The QPL makes it harder to reuse code than the GPL or BSD licenses do. Clause 3 of the QPL effectively prevents you from taking a bit of Troll Techs QT code and including it in your own program. The QPL is an "indivisible" license if I may be permitted to coin a phrase.
Personally that is a feature of the QPL I really don't like but I'm prepared to live with given the great work (code) that the Trolls are producing.
I hoped this cleared a few things up. (Well I know full well that in another couple of weeks the same people will just post the same crap again, but at least I got to reread the QPL and double check my facts (again))
do you know how hard it is to compile KOffice yourself?!?). Yes.
Though Mico 2.2.7 has been the easiest to compile in a while, especially with instructions http://lists.kde.org/?l=kdedevel&m=92936429524154& w=2 . QT 2 is finally stabalizing, if you download a beta it shouldn't be made obsolete until the actual release is made. (That is changes in QT shouldn't neccessitate changes in kdelibs that are incompatible with your beta).
You only need kdelibs to compile koffice, not kdebase or the other packages and you can run koffice apps (using the QT 2 based kdelibs) from inside your old kde 1.1 (in fact that's the reccommended way, I reccommend setting up a new user and compiling all the kde2 stuff under that users home directory).
I managed to compile and run kpresenter, killustrator and kspread last weekend but the kword compile died due to an internal error in egcs (1.03). I couldn't work out a way around this. This was a shame as kword was looking good when I last looked at it 6 months ago, and I wanted to see the improvements.
I'm using a RH5.2 distribution (only thing my local shop had). Does anyone know an easy way of upgrading to ecgs 1.1x? The RH rpms seemed to require me to upgrade my kernel which I'm not prepared to do (I have enough bleeding edge software installed and don't want to have to debug kernel problems as well).
Re:Corel is clueless about OSS development
on
Corel Linux FAQ
·
· Score: 1
Obviously I meant to say any attempt to screw the KDE project for a quick buck will backfire.
Re:Corel is clueless about OSS development
on
Corel Linux FAQ
·
· Score: 1
I wonder if Corel has purchased any licenses from Troll Tech, after all they are apparently relying on Wine and not QT (to port their software that is). It's possible that they haven't paid TrollTech a dime.
Meanwhile KDE developers have contributed code to QT (I don't know how much exactly). Several KDE developers work for TrollTech and feelings between the two camps is good, excellent even. I'd shout a Troll a beer any day. All the publicity KDE receives can't be bad for TrollTech either. After all if Corel purchases licenses from TrollTech it'll be because of the KDE won't it?
Disclaimer: I don't work for TrollTech and don't know a great deal about them.(But they seem like nice guys to me, keep up the good work! I'm counting on you guys for a bug free QT 2.0!)
Note: I don't want to come off sounding like an anti Corel KDE developer. I'm a very minor contributor and no significance in the big scheme of things. I'm moderately anti IP and aren't keen on entities owning software for lenghty periods of time, so I'm weary of Corel's involvement with free software. I hope they are smart enough to realize that they are in a "give and thou shalt receive" type situation as far as being involved in free software type projects.
Any attempt to screw the KDE project for a quick buck is not going to back fire.
Re:survival of the fitest (or "the best code wins"
on
Corel Linux FAQ
·
· Score: 1
It's entirely possible that Corel will release a version that's better than the original, and if it's successful in the marketplace, the original KDE project may be relegated to second place status. Even if Corel release a version of KDE that is superior to the original KDE, users may choose to use the authentic version, believing that the next release of the authentic version will be superior to the Corel release. Moreover if it is easier to upgrade from one authentic version to another rather than from a Corel version to an authentic version. It can't just be better at one point in time, it has to better over a prolonged period.
Corel would effectively gain control of future development The current suite of KDE applications provide valuable functionality and will continue to mature and become increasingly valuable in the comming months.
There is good will that exists between KDE application developers and kde libs/base developers that has been built up over a period of years through a combination of open communication and joint involvement in projects of mutual benefit. (The same is true of KDE users and KDE application programmers and KDE libs/base developers and TrollTech developers). Even if Corel produce a superior version of KDE libs/base they may fail to gain market share due to failure to attract KDE application programmers.
I fear that if Corel is intending to go their own way and produce a better KDE than KDE then they are doomed to failure. The free software community is different, they can look beyond the set of features sported by a software system and look at how that software will satisfy the long term needs of themselves and their community.
Re:Corel is clueless about OSS development
on
Corel Linux FAQ
·
· Score: 1
Thanks very much for that response anonymous.
I have to agree that anything less than regular communication with the KDE team greatly increases the chances of bad feelings and wasted work. Months of hard work by Corel might after a days discussion be rejected from inclusion into KDE CVS. This would pretty much mean that their distribution would be non-standard and their changes would become obsolete as the main KDE branch progressed. If there was a book on OSS anti-patterns this would be in it, I've seen individuals make this mistake over and over again.
That scenario is only likely to eventuate if they are working on kdelibs or kdebase stuff if they are working on additional apps then I don't have a problem with them doing it in privacy until they are ready to release an alpha/beta.
Thanks for the info again, 'preciate it.
Corels contributions to the KDE
on
Corel Linux FAQ
·
· Score: 1
Does anyone know of any contributions Corel has made to the KDE? Do they have programmers with CVS access?
Just curious, as I haven't seen any Corel developers post on the dev list.
Hunh? Have you ever compared (for instance) the display properties applets of KDE and Windows? You don't think these two are a lot alike? How about a taskbar/panel? Or "Start" menu? Trash can? Auto-start folder? Shortcuts? Yes the display properties is similar to windows. The panel is more like CDE than anything windows. The taskbar is like windows, I don't use it much though but don't know how to turn it off, also note a MacOs like alternative the Windowlist in the panel is provided. Auto-start folder, sure I remember the mac having something like this. Shortcuts ditto.
I can't really justify my original statement though, I guess I meant KDE isn't a windows clone it's a blend of the best parts of CDE, Windows, the Mac GUI, OS/2 and NeXtStep. My first impression was, heck that looks a lot like CDE, then I discovered it was similar to Windows/Mac, then a found it has its own distinctive flavor, YMMV.
to say that the two aren't very similar seems silly Except for the very I agree:-)
A consistent UI is dependent upon the toolkit, not a "desktop environment." No. In the case of KDE the consistent feel depends on the kdelibs as well as QT, but not on (kdebase). kdelibs is basically replacements and extensions to QT. KDE = development libraries + desktop shell + apps.
Not everyone needs to be able to edit spreadsheets from within a word processor. Why should those who don't need such "features" be expected to suffer the overhead associated with them in their UI? Hey this is free software. That means a much more level playing field. If the apps with interoperability features are so bloated that demand for slimmer apps is strong then someone will code those slimmer apps. (Kruiser the alternative KDE file manger is one example). You've got the source code so the developer should be able to choose the level of interoperability.
Look at the plans for E, its going to be a competitor in the desktop shell arena, but you will still be able to use KDE apps from it. There is a fair bit of choice there.
Note there are limits, the choice of toolkits should benefit the developer but not make much of a difference to the user. I mean from the users point of view I don't want different types of scrollbars in different apps (themeing allows some flexibility and power here), and I don't want to find out my app doesn't support voice control as there aren't enough developers available to implement it.
It's basically depends on the supply of able programmers and the level of demand from users as to what gets done.
One of the *major* things I love about Linux is how fast it is. But it's *not* as fast at all running these big GUIs. It's manifestly slower. Hmm, KDE doesn't slow down Linux much for me, I mean the kernel going at the same speed as always. I use bash to do most of my file management, KDE doesn't seem to have slowed down that at all, I still have the "choice".
I really would like to try to put more time into this reply but I still haven't finished that coding...
Now, what benefits are generally available from having applications that can communicate via CORBA? Well KOM will allow linking and embedding for one thing, see the Openpart docs available at the KDE website for more info.
How is a desktop environment necessary for the use of CORBA? It isn't with KDE.
Everyone grumps about the M$ interface, The ocassional non-resizable dialog with a list box in it pisses me off, but I would say that comparatively MS's interfaces are good, indeed MSs main strength.
it appears to my poor vision that KDE and GNOME are striving to be nothing more than better implementations of what M$ has already done I don't agree with that at all. KDE isn't any more like windows than it is the Mac GUI, or NextStep or OS/2. A lot of effort goes into not copying the bad features of other GUIs.
I just don't know what benefit *I* am supposed to obtain from them[DEs]. I don't know enough about you to say for sure, but you might find a web browser, e-mail client and word processor easier to use if they interoperate well and have consistent UIs. Also look for Matthias Ettrich's original e-mail on the motivation for the KDE it's worth reading.
Perhaps this isn't revolutionary enough for your tastes, but some of us just want to focus on making useful free apps with GUIs rather than creating a revolution in GUI design. (At least for the moment anyway, one thing at a time).
Sorry I couldn't provide links I'm just taking a short break from coding.
I've never meet Bruce Perens, or even e-mailed him, but from reading his work, and from observing his involvement in threads here I gotta say, I like the guy.
He is committed to free software development, he doesn't just talk, he does what it takes to make a difference. I admire him for it.
I've watched people here slander him in the worst possible way, and seen him lose his cool and reply angrily. I didn't think any the less of him for it, to me it made him seem more real, it made it seem like the stuff he is contributing to is really, truely, dear to him. Even if we go away I think he'll stay.
So you say he was involved in the anti-KDE campaign. To me the "anti-KDE campaign" is the worst thing to ever happened in the free software world. It is a shameful story, a witch hunt were innocent developers were attacked for "crimes" they did not commit. The KDE developers did nothing wrong, I wasn't around from the beginning but I've read the mailing list archives and I've watch in horror and disgust over the last year or so.
There is no excuse for what I've witnessed.
Now I know Bruce Perens was part of this, I know he voted against the creation of a KDE newsgroup on usenet, I know there's much I don't know about how he was part of the anti-KDE campaign.
But I believe he is innocent, unlike others who joined the lynch mob in this despicable affair, what he did, he did for the right reasons.
He had every right to criticize the KDE project, people expressed valid concerns, what if MS brought TrollTech and stop giving away QT for free? If would have been the end of KDE that's what.
KDE was about a GUI for unixes, not about freeing the source code. It relied on a toolkit that didn't give us the right to freely modify and distribute it. For some people, for Bruce Perens that wasn't good enough.
Some still criticize KDE they call it evil and make derogatory remarks about the KDE developers. There are still reasons people don't like KDE, they consider C superior to C++, or the only kind of free software the are interested in is GPL'd software, or they won't support a truely international project like KDE because they consider it un-American. I don't think Bruce was interested in any of those reasons though.
Once Bruce was satisfied with the QT license he crossed the line to support KDE. He stepped out of the lynch mob that had flocked around him and shielded the lynchees. That took guts, that's something he should be admired for.
Slashdot Mirror
1) All of your arguments apply to Linux and the GPL. (Can't produce a shareware version of Linux, can't develop hybrid license version of Linux, can't distribute freeware (no source) version of linux). The difference with QT is you can buy a license to develop proprietary software.
2) If you are going to make money by selling proprietary software what is wrong with the idea of having to give back some of that money to troll tech? (How much you can argue about but surely there is nothing wrong with giving something back!).
3)KDE symbolizes a Marxist approach to software development
KDE development has no political or religious affinity. Each project can choose their own development model. Different projects contribute code under different licenses. Core development tends to be done on an anarchy/meritocracy basis.
Basically KDE development encourages Open Source development but allows proprietary development at a cost.
As I have mentioned before the document you reference http://pmitros.mit.edu/patchwork.html is obsolete. The QPL license does not require modifications to be distributed with the "patch" utility, a fact many of the arguments in patchwork.html assume.
In fact KDE is fully free software, as defined by the debian free software guidelines.
There are valid criticisms of the KDE licensing scheme that need to be heard (GPL/QPL incompatibility), by repeating these incorrect assertions you are simply causing unnecessary confusion.
Please read the QPL http://www.troll.no/qpl/plaintext.txt it is a very simple license.
oops s/brought/bought.
Initially I read that as Australia had criminalised reverse engineering and took the rest of the posting as sarcasm. Still can't believe legislators would actually do something sensible.
Aah now I understand looks like this is already legal everywhere else (the article mentions this being legal already in Europe and USA) and concerns about fixing Y2K bugs bought the stupidity of criminalizing reverse engineering into light, bit late now though!
Here is a way to get that functionality by binding Alt-Down and Alt-Up.
;Scroll buffer without moving point
(defun scroll-down-line ()
"Scroll one line down."
(interactive)
(scroll-down 1))
(defun scroll-up-line ()
"Scroll one line up."
(interactive)
(scroll-up 1))
(global-set-key [M-down] 'scroll-up-line)
(global-set-key [M-up] 'scroll-down-line)
I agree there is an issue here. I'm not going to say whether the QPL is or isn't compatible with the GPL (Note for audience RMS who is far more civilized about the whole thing than many others says it isn't, others question this).
/., I suspect people would rather argue than do something more constructive here.
:-)
But assumming for the moment that they are incompatible, then I buy the argument that redistribution of KDE apps is legal so long as the authors haven't used GPL'd code without permission. Because the authors of said apps has given implicit permission (why else write a KDE app and put it on a public server and encourage people to redistribute it).
If someone wanted to do something useful they could make a list of questionable KDE apps (if any) and I would look into it further. (I'm sure we'll all be back here talking about it later in another KDE related article). But then again this is
And that is why people try to convince the KDE developers to use another license
Doesn't the KDE Artistic License just keep on getting more and more popular
That is why we have the Harmoney project so we have a library that can be linked with KDE as a Qt replacement
Not correct. Jo Dillon started the Harmony project before the QPL existed. He seems to be contributing more to KDE than Harmony nowadays so I guess he has found the QPL to remove the need for Harmony. (Note the Harmony list had been dead for months last time I checked)
The best solution would be if Troll Tech released Qt under a license that is compatible with the GPL.
I don't agree, or at least I'm going to require a lot convincing before I agree. The QPL is a nice license whereas the GPL is something of a monstrosity (read both to see what I mean), I'm beginning to think it's the GPL that needs work.
Goodnight, I'd rather be coding.
Hell now that was funny, I've got to know was it intentional?
:-)
Technically speaking, much of KDE is illegal. One cannot legally link Qt and KDE together.
Typical ignorant babble (The GPL permits linking, you probably want to complain about redistribution in which case I have an answer ready for you
Anyway onto the funny part
No one has sued yet, but if the author if Lyx chooses to sue every person using or distributing kLyx, it's in his rights.
Well he would have to sue himself then. As Matthias Ettrich founded the Lyx project as well as (drumroll please....)
KDE.
The person you replied to seems to be an idiot so I'm not taking their side, but what you're saying is wrong.
The incompatibilites at source level simply don't exist. Period.
Blatantly false. The "Porting Code from 16-bit Windows to 32-bit Windows" section of the "Platform, SDK, and DDK Documentation" clearly states:
"Although the Win32 API was designed to be as compatible as possible, you may need to modify a large amount of source code."
I now feel obliged to state that while i get paid for windows application development, I, of course, spend all of my friend time developing for Linux. The same as any other self respecting nerd.
Amongst other oddities Petzold Win3x example printing source code won't work on 95 (but the binaries will) and I doubt your average Win32 program ports easily to Wince. However it's much easier to port programs between versions of windows than versions of unix.
:-( I believe there is an ACE library that includes portably *nix threads but from all accounts ACE is bloated and complicated, most people opt to use a non threading solution, luckily this is almost always possible.
Just look at the state of threading for instance. Linux has good support for threading but other *nixes don't so code intended to be portable can't use it
Developers would try to fix the big, prominent bugs instead of the smaller ones.
Yes, that would be the idea. Allow users to vote for what bugs should be fixed (money isn't even needed) hence allowing important bugs to be seperated from less important bugs.
But, small ones are often the hardest to fix.
Isn't that the truth, lots of peope get really ticked off about the small things though.
Nice idea, but I don't think it will work.
If a really believed in it I would implement myself. Things are working pretty well at the moment but I notice there isn't much incentive for developers to fix problems that don't affect them.
I've read that particular Dilbert too.
Hopefully competition amongst developers would stop this, if a developer starts introducing bugs just to get paid for fixing them someone else could fork the code or start up a new project. In this sense free software is a free market.
One way of rewarding open source developers would be to augment the Debian Bug Tracking software and allow users to offer a reward to the first developer who is able to close a bug. The user would make a maxmimum offer that is kept secret. The system would calculate the maxiumum reward, given that all bidders pay the same amount or nothing at all. After a bug has been fixed (or feature request satisfied) bidders who actually paid would be given a small bonus say an e-mail telling them the problem had been fixed, (and the developer would be forwarded the cash, a third party coud settle disputes).
Several large projects use the Debian Bug Tracking System and any/all of them could benefit from this idea, you wouldn't even need to use real money though using actual money would probably be more effective.
The main drawback with this system is that currently there is an atmosphere of good will and a sense of working towards a greater goal, money could spoil that and turn friends into enemies.
According to the Debian Free Software Guidelines QT is free software. You are making up your own definition for the word free and I don't share it.
2 58&cid=144
Secondly the document you referenced (http://pmitros.mit.edu/patchwork.html) is obsolete. The QPL was changed months ago (before QT 2.0 was released) and the stipulation that the patch program must be used to distribute modifications has been removed.
For an objective critque of the license see my post here http://slashdot.org/comments.pl?sid=99/06/25/1246
People please read http://www.troll.no/qpl/plaintext.txt and see the truth for yourself. The QPL is a very simple license. It is the simplest license I have ever read, it is much simpler than the GPL. It is simpler than many postings here on slashdot, it is simpler than this posting. It is in plain english. You will understand it much better by reading it than by reading postings here.
people are forbidden from distributing modified versions of QT
No, no, no, no! I can't believe this crap has been ranked up. It is so blatantly false. Did you read the wrong license? Please follow my link.
Firstly distribution takes place as one of two forms either distribution of binaries or distribution of source code.
Clause 4 (of 6) allows you to distribute binaries of modified versions of QT under the following 3 conditions
a) You must include the license document.
b) You must make the source code available.
c) You must place all your modifications under the same license (the QPL).
Note that the distribution of binaries under the QPL protects your freedoms better than the GPL does, because the QPL contains no "privacy loophole".
Clauses 2 and 3 (of 6) allows you to distribute modified versions of the source code. Clause 2 allows me checkout the original QT from any CVS repository (or copy it off any CD). Clause 3 allows me to CVS update (or apply a patch script on a tar file of modifications) to update to a modified version of QT (source code).
That is clauses 2 and 3 allow you to distribute modified versions of the QT source code under reasonable conditions. There is no problem here!
Okay onto your next point
and their programs can't require a user to make changes to QT.
A honestly don't understand what you are trying to say here. If your program requires the user to use a modified version of QT then distribute a binary version of your modified QT along with your program.
while the license is somewhat better, it ain't the GPL (any version); and I still have hope for the Harmony Project.
I have news for you.
1) The GPL ain't perfect.
2) None of the Harmony Project source is under the GPL, it is under the LPGL.
Not that I'm against the harmony project, BTW.
If you are going to complain about the QPL please find something worthy of complaining about!
Now I'm no Troll Tech lackey. I admire the GTK toolkit and have great respect for those who developed it. If you are a GTK/GNOME supporter and want something to complain about, then complain about this:
The QPL makes it harder to reuse code than the GPL or BSD licenses do. Clause 3 of the QPL effectively prevents you from taking a bit of Troll Techs QT code and including it in your own program. The QPL is an "indivisible" license if I may be permitted to coin a phrase.
Personally that is a feature of the QPL I really don't like but I'm prepared to live with given the great work (code) that the Trolls are producing.
I hoped this cleared a few things up. (Well I know full well that in another couple of weeks the same people will just post the same crap again, but at least I got to reread the QPL and double check my facts (again))
do you know how hard it is to compile KOffice yourself?!?).
& w=2 . QT 2 is finally stabalizing, if you download a beta it shouldn't be made obsolete until the actual release is made. (That is changes in QT shouldn't neccessitate changes in kdelibs that are incompatible with your beta).
Yes.
Though Mico 2.2.7 has been the easiest to compile in a while, especially with instructions http://lists.kde.org/?l=kdedevel&m=92936429524154
You only need kdelibs to compile koffice, not kdebase or the other packages and you can run koffice apps (using the QT 2 based kdelibs) from inside your old kde 1.1 (in fact that's the reccommended way, I reccommend setting up a new user and compiling all the kde2 stuff under that users home directory).
I managed to compile and run kpresenter, killustrator and kspread last weekend but the kword compile died due to an internal error in egcs (1.03). I couldn't work out a way around this. This was a shame as kword was looking good when I last looked at it 6 months ago, and I wanted to see the improvements.
I'm using a RH5.2 distribution (only thing my local shop had). Does anyone know an easy way of upgrading to ecgs 1.1x? The RH rpms seemed to require me to upgrade my kernel which I'm not prepared to do (I have enough bleeding edge software installed and don't want to have to debug kernel problems as well).
Obviously I meant to say any attempt to screw the KDE project for a quick buck will backfire.
I wonder if Corel has purchased any licenses from Troll Tech, after all they are apparently relying on Wine and not QT (to port their software that is). It's possible that they haven't paid TrollTech a dime.
Meanwhile KDE developers have contributed code to QT (I don't know how much exactly). Several KDE developers work for TrollTech and feelings between the two camps is good, excellent even. I'd shout a Troll a beer any day. All the publicity KDE receives can't be bad for TrollTech either. After all if Corel purchases licenses from TrollTech it'll be because of the KDE won't it?
Disclaimer:
I don't work for TrollTech and don't know a great deal about them.(But they seem like nice guys to me, keep up the good work! I'm counting on you guys for a bug free QT 2.0!)
Note:
I don't want to come off sounding like an anti Corel KDE developer. I'm a very minor contributor and no significance in the big scheme of things. I'm moderately anti IP and aren't keen on entities owning software for lenghty periods of time, so I'm weary of Corel's involvement with free software. I hope they are smart enough to realize that they are in a "give and thou shalt receive" type situation as far as being involved in free software type projects.
Any attempt to screw the KDE project for a quick buck is not going to back fire.
It's entirely possible that Corel will release a version that's better than the original, and if it's successful in the marketplace, the original KDE project may be relegated to second place status.
Even if Corel release a version of KDE that is superior to the original KDE, users may choose to use the authentic version, believing that the next release of the authentic version will be superior to the Corel release. Moreover if it is easier to upgrade from one authentic version to another rather than from a Corel version to an authentic version. It can't just be better at one point in time, it has to better over a prolonged period.
Corel would effectively gain control of future development
The current suite of KDE applications provide valuable functionality and will continue to mature and become increasingly valuable in the comming months.
There is good will that exists between KDE application developers and kde libs/base developers that has been built up over a period of years through a combination of open communication and joint involvement in projects of mutual benefit. (The same is true of KDE users and KDE application programmers and KDE libs/base developers and TrollTech developers). Even if Corel produce a superior version of KDE libs/base they may fail to gain market share due to failure to attract KDE application programmers.
I fear that if Corel is intending to go their own way and produce a better KDE than KDE then they are doomed to failure. The free software community is different, they can look beyond the set of features sported by a software system and look at how that software will satisfy the long term needs of themselves and their community.
Thanks very much for that response anonymous.
I have to agree that anything less than regular communication with the KDE team greatly increases the chances of bad feelings and wasted work. Months of hard work by Corel might after a days discussion be rejected from inclusion into KDE CVS. This would pretty much mean that their distribution would be non-standard and their changes would become obsolete as the main KDE branch progressed. If there was a book on OSS anti-patterns this would be in it, I've seen individuals make this mistake over and over again.
That scenario is only likely to eventuate if they are working on kdelibs or kdebase stuff if they are working on additional apps then I don't have a problem with them doing it in privacy until they are ready to release an alpha/beta.
Thanks for the info again, 'preciate it.
Does anyone know of any contributions Corel has made to the KDE? Do they have programmers with CVS access?
Just curious, as I haven't seen any Corel developers post on the dev list.
Hunh? Have you ever compared (for instance) the display properties applets of KDE and Windows? You don't think these two are a lot alike? How
:-)
about a taskbar/panel? Or "Start" menu? Trash can? Auto-start folder? Shortcuts?
Yes the display properties is similar to windows. The panel is more like CDE than anything windows. The taskbar is like windows, I don't use it much though but don't know how to turn it off, also note a MacOs like alternative the Windowlist in the panel is provided. Auto-start folder, sure I remember the mac having something like this. Shortcuts ditto.
I can't really justify my original statement though, I guess I meant KDE isn't a windows clone it's a blend of the best parts of CDE, Windows, the Mac GUI, OS/2 and NeXtStep. My first impression was, heck that looks a lot like CDE, then I discovered it was similar to Windows/Mac, then a found it has its own distinctive flavor, YMMV.
to say that the two aren't very similar seems silly
Except for the very I agree
A consistent UI is dependent upon the toolkit, not a "desktop environment."
No. In the case of KDE the consistent feel depends on the kdelibs as well as QT, but not on (kdebase). kdelibs is basically replacements and extensions to QT. KDE = development libraries + desktop shell + apps.
Not everyone needs to be able to edit spreadsheets from within a word processor. Why should those who don't need such "features" be expected to suffer the overhead associated with them in their UI?
Hey this is free software. That means a much more level playing field. If the apps with interoperability features are so bloated that demand for slimmer apps is strong then someone will code those slimmer apps. (Kruiser the alternative KDE file manger is one example). You've got the source code so the developer should be able to choose the level of interoperability.
Look at the plans for E, its going to be a competitor in the desktop shell arena, but you will still be able to use KDE apps from it. There is a fair bit of choice there.
Note there are limits, the choice of toolkits should benefit the developer but not make much of a difference to the user. I mean from the users point of view I don't want different types of scrollbars in different apps (themeing allows some flexibility and power here), and I don't want to find out my app doesn't support voice control as there aren't enough developers available to implement it.
It's basically depends on the supply of able programmers and the level of demand from users as to what gets done.
One of the *major* things I love about Linux is how fast it is. But it's *not* as fast at all running these big GUIs. It's manifestly slower.
Hmm, KDE doesn't slow down Linux much for me, I mean the kernel going at the same speed as always. I use bash to do most of my file management, KDE doesn't seem to have slowed down that at all, I still have the "choice".
I really would like to try to put more time into this reply but I still haven't finished that coding...
Now, what benefits are generally available from having applications that can communicate via CORBA?
Well KOM will allow linking and embedding for one thing, see the Openpart docs available at the KDE website for more info.
How is a desktop environment necessary for the use of CORBA?
It isn't with KDE.
Everyone grumps about the M$ interface,
The ocassional non-resizable dialog with a list box in it pisses me off, but I would say that comparatively MS's interfaces are good, indeed MSs main strength.
it appears to my poor vision that KDE and GNOME are striving to be nothing more than better implementations of what M$ has already done
I don't agree with that at all. KDE isn't any more like windows than it is the Mac GUI, or NextStep or OS/2. A lot of effort goes into not copying the bad features of other GUIs.
I just don't know what benefit *I* am supposed to obtain from them[DEs].
I don't know enough about you to say for sure, but you might find a web browser, e-mail client and word processor easier to use if they interoperate well and have consistent UIs. Also look for Matthias Ettrich's original e-mail on the motivation for the KDE it's worth reading.
Perhaps this isn't revolutionary enough for your tastes, but some of us just want to focus on making useful free apps with GUIs rather than creating a revolution in GUI design. (At least for the moment anyway, one thing at a time).
Sorry I couldn't provide links I'm just taking a short break from coding.
Good for you. I've got no problem with your post. I was talking to the other guy, the one who was whining on Slashdot about Slashdot being crap.
That kinda thing just gets on my nerves that's all. If s/he doesn't like it here why don't they go elsewhere instead of adding to the noise.
If you think it's so bad then what the hell are you doing here? Sheesh.
I've never meet Bruce Perens, or even e-mailed him, but from reading his work, and from observing his involvement in threads here I gotta say, I like the guy.
He is committed to free software development, he doesn't just talk, he does what it takes to make a difference. I admire him for it.
I've watched people here slander him in the worst possible way, and seen him lose his cool and reply angrily. I didn't think any the less of him for it, to me it made him seem more real, it made it seem like the stuff he is contributing to is really, truely, dear to him. Even if we go away I think he'll stay.
So you say he was involved in the anti-KDE campaign. To me the "anti-KDE campaign" is the worst thing to ever happened in the free software world. It is a shameful story, a witch hunt were innocent developers were attacked for "crimes" they did not commit. The KDE developers did nothing wrong, I wasn't around from the beginning but I've read the mailing list archives and I've watch in horror and disgust over the last year or so.
There is no excuse for what I've witnessed.
Now I know Bruce Perens was part of this, I know he voted against the creation of a KDE newsgroup on usenet, I know there's much I don't know about how he was part of the anti-KDE campaign.
But I believe he is innocent, unlike others who joined the lynch mob in this despicable affair, what he did, he did for the right reasons.
He had every right to criticize the KDE project, people expressed valid concerns, what if MS brought TrollTech and stop giving away QT for free? If would have been the end of KDE that's what.
KDE was about a GUI for unixes, not about freeing the source code. It relied on a toolkit that didn't give us the right to freely modify and distribute it. For some people, for Bruce Perens that wasn't good enough.
Some still criticize KDE they call it evil and make derogatory remarks about the KDE developers. There are still reasons people don't like KDE, they consider C superior to C++, or the only kind of free software the are interested in is GPL'd software, or they won't support a truely international project like KDE because they consider it un-American. I don't think Bruce was interested in any of those reasons though.
Once Bruce was satisfied with the QT license he crossed the line to support KDE. He stepped out of the lynch mob that had flocked around him and shielded the lynchees. That took guts, that's something he should be admired for.