Really, illegal is strong word for mere allegations... Besides, only a very small part of KDE code was not originally written by KDE people, so even if Debian's license interpretation were correct, it would only concern those few areas.
It's hard to do something illegal with your own code, you know.
I don't dispute the nicety of an automated test-suite, but that's totally beside the point.
Regarding changing the dynamic libs, it's an interesting idea, but rather hard to implement correctly (keeping binary compatibility is not so easy, and keeping the test-suite in sync with the latest Qt is a lot of work, too).
I doubt most developer's want to spend their time coding a stub version of Qt just to make Debian happy...
Besides, that would not alleviate the problems of Debian (I don't agrre with their interpretation of the GPL, but let's pretend it's correct for the moment), which is their claim that distributing binaries of GPLed programs linked to Qt is illegal.
But I think that there is a way to solve this problem for once and for all which is not discussed. Produce a GPL-friendly interface to Qt with a GPL-friendly implementation behind it. Have it support the full programming interface, but don't worry too much about it "looking nice" or usability for the end-user. Ship KDE with this and with some easy way to switch from this (bad) default to Qt. Then KDE can ship in compliance with the GPL completely separately from any license issues that Qt may have.
If you mean that KDE should implement its own GUI library and wrappers for Qt, so that one can switch between those two - actually using Qt, but having that other implementation as "GPL workaround" - then I can tell you: fat chance!
Something like that won't happen in the foreseeable future, its totally against the KDE philosophy (things that work, pragmatism), inefficient and a lot of work.
This sure looks like a troll, but in case it is not:
Where do you draw your conclusions from? And all the while you talk about GNOME, but that's like comparing apples and oranges... GTK+ vs Qt, ok, but GNOME is a different beast alltogether.
So? ReiserFS has had a lot of releases as well, and besides, while Linus may have had only implementational issues with devfs, other people object to it in principle.
So it's not that Linus stalled it for a long time, there were bugs to be ironed out, but even so it wouldn't be in had Linus not taken a favourable stance to it...
Hans Reiser was the project initiator, primary architect, supplier of funding, and one of the programmers. Some folks at times remark that naming the filesystem Reiserfs was egotistic. It was so named after a potential investor hired all of my employees away from me, then tried to negotiate better terms for his possible investment, and suggested that he could arrange for 100 researchers to swear in Russian Court that I had had nothing to do with this project. That business partnership did not work out.
If the KDE developers dont want to interoperate just because theyre against GNOME for political reasons i can only conclude theyre just braindead.
KDE was there before, so rightfully you could say "if the GNOME developers don't want to interoperate just because they're against KDE for political reasons, I can only conclude that they're braindead."
In real life however, neither of those statements is true. Since history can't be changed, both KDE and GNOME developers (well, some of them;) do what they can to ensure compatibility where it is practical. Since KDE2 will be released pretty soon, changing the component modell is NOT practical at the moment.
Even if everyone understood the concepts well enough (not everbody has got the same ability for abstraction), someone would have to write the most basic components, compilers,...
Programs for new (and old) hardware platforms won't just miraculously materialize...
Obviously physics is bad because you've got to know math to understand it...
Re:C++ as a teaching language/programming obscure?
on
Who's Afraid Of C++?
·
· Score: 1
Mhm. I'd say obviously you are not a software engineer, are you?
An algorithm that a C++ programmer can write that takes 5 minutes, I can do it in 4 - simply because I'm writing closer to assembly.
I kinda doubt that, but even if it were true, does that say that C is a better language? No, it doesn't. It all depends on the program, and for complex enough algorithms/problems, all possible speed gains by being "closer to assembly" are overshadowed by increased costs due to programming time and debugging.
Besides, you can program as close to assembly in C++ as in C, for those parts that actually need that amount of attention.
QTL is the Qt Template Library, a set of cross-platform template classes used instead of the STL.
You propably mean the QPL, but that license only applies to Qt, not to KDE.
KDE is GPLed for the most part, except the libraries which are LGPL, and some applications that come under different (Artistic,...) or multiple licenses.
Actually, nothing is decided yet. Note however that the article mentions both possibilities, i.e. KDE using Bonobo as is, or a successor to both, which proably would be better (both technology and "mindshare" wise).
Though I agree that a common object model would be A Good Thing (tm), it's questionable how this will be best achieved:
CORBA does indeed include a lot of unnecessary overhead for local applications, and general interoperability is currently hampered by Orbit's non-standard authentification mechanism...
Slashdot Mirror
Really, illegal is strong word for mere allegations... Besides, only a very small part of KDE code was not originally written by KDE people, so even if Debian's license interpretation were correct, it would only concern those few areas.
It's hard to do something illegal with your own code, you know.
I don't dispute the nicety of an automated test-suite, but that's totally beside the point.
Regarding changing the dynamic libs, it's an interesting idea, but rather hard to implement correctly (keeping binary compatibility is not so easy, and keeping the test-suite in sync with the latest Qt is a lot of work, too).
I doubt most developer's want to spend their time coding a stub version of Qt just to make Debian happy...
What for?
Besides, that would not alleviate the problems of Debian (I don't agrre with their interpretation of the GPL, but let's pretend it's correct for the moment), which is their claim that distributing binaries of GPLed programs linked to Qt is illegal.
But I think that there is a way to solve this problem for once and for all which is not discussed. Produce a GPL-friendly interface to Qt with a GPL-friendly implementation behind it. Have it support the full programming interface, but don't worry too much about it "looking nice" or usability for the end-user. Ship KDE with this and with some easy way to switch from this (bad) default to Qt. Then KDE can ship in compliance with the GPL completely separately from any license issues that Qt may have.
If you mean that KDE should implement its own GUI library and wrappers for Qt, so that one can switch between those two - actually using Qt, but having that other implementation as "GPL workaround" - then I can tell you: fat chance!
Something like that won't happen in the foreseeable future, its totally against the KDE philosophy (things that work, pragmatism), inefficient and a lot of work.
This sure looks like a troll, but in case it is not:
Where do you draw your conclusions from? And all the while you talk about GNOME, but that's like comparing apples and oranges... GTK+ vs Qt, ok, but GNOME is a different beast alltogether.
Now, copyrights do need to be inforced or they become worthless, but that's a different kettle of fish.
No, they don't. It's trademarks and patents that you're thinking of. Copyright does NOT diminish just because it's not "defended".
Without much whining> that's simply not true. See this and that summary of discussions on linux-kernel.
So? ReiserFS has had a lot of releases as well, and besides, while Linus may have had only implementational issues with devfs, other people object to it in principle.
So it's not that Linus stalled it for a long time, there were bugs to be ironed out, but even so it wouldn't be in had Linus not taken a favourable stance to it...
ramfs/cramfs. Features compressed file data - not a triviality either.
Sure, but it doesn't touch stuff outside the filesystem, does it?
devfs. Despite Linus' reservations against devfs, it's in the 2.4 kernel.
Huh? Linus was the driving force (besides Richard Gooch of course) behind the inclusion of devfs into the kernel!
You propably mean "modal" instead of "non-modal" (or "modeless")...
modal == can't switch/do anything else
non-modal == it's just a window
Which is only Debian's opinion, and not what the troll above said.
If the KDE developers dont want to interoperate just because theyre against GNOME for political reasons i can only conclude theyre just braindead.
KDE was there before, so rightfully you could say "if the GNOME developers don't want to interoperate just because they're against KDE for political reasons, I can only conclude that they're braindead."
In real life however, neither of those statements is true. Since history can't be changed, both KDE and GNOME developers (well, some of them ;) do what they can to ensure compatibility where it is practical. Since KDE2 will be released pretty soon, changing the component modell is NOT practical at the moment.
No system is perfect, therefore every system can be improved.
Besides, hardware platforms constantly change, you can't just rest on the laurels of you "perfect OS"...
Please pinch yourself.
...
Then ensure that you are indeed awake.
Even if everyone understood the concepts well enough (not everbody has got the same ability for abstraction), someone would have to write the most basic components, compilers,
Programs for new (and old) hardware platforms won't just miraculously materialize...
And who creates those off-the-shelf components?
Obviously physics is bad because you've got to know math to understand it...
Mhm. I'd say obviously you are not a software engineer, are you?
I kinda doubt that, but even if it were true, does that say that C is a better language? No, it doesn't. It all depends on the program, and for complex enough algorithms/problems, all possible speed gains by being "closer to assembly" are overshadowed by increased costs due to programming time and debugging.
Besides, you can program as close to assembly in C++ as in C, for those parts that actually need that amount of attention.
Ah yes, REAL men write object-oriented code in assembler (obviously a REAL language), or in SmallTalk (another obviously REAL language), ey?
Uh, I just noticed:
You propably meant this Mail by Stefan Westerfeld, didn't you?
Thanks for the info.
One nitpick, though: why not use ?
Ah sorry, it wasn't intended as a flame.
;)
(Neither is a post further down, where I again explain the difference, only in "formal" notation
PLEASE stop using wrong acronyms.
QTL != QPL && !KDE.coveredBy (QPL)
window manager hints are done (NETWM)
drag'n'drop is done (XDnd)
desktop files (MIME types and menus) are done (the ".desktop" standard)
Bullshit.
...) or multiple licenses.
QTL is the Qt Template Library, a set of cross-platform template classes used instead of the STL.
You propably mean the QPL, but that license only applies to Qt, not to KDE.
KDE is GPLed for the most part, except the libraries which are LGPL, and some applications that come under different (Artistic,
Actually, nothing is decided yet. Note however that the article mentions both possibilities, i.e. KDE using Bonobo as is, or a successor to both, which proably would be better (both technology and "mindshare" wise).
Though I agree that a common object model would be A Good Thing (tm), it's questionable how this will be best achieved:
CORBA does indeed include a lot of unnecessary overhead for local applications, and general interoperability is currently hampered by Orbit's non-standard authentification mechanism...