I would say there are a few things you should do, firstly you should ensure that you explicitly state who has copyright on the information. Generally I would guess you should state it remains with the author of any articles etc. you publish, so that they are the point of contact for any disputes. To make this work though, you need to provide a bit more:
You should make sure that there is a contact address for the author of any docs you reproduce, if you don't then you will get any complaints yourself. Finally, you should ensure there is a way for the author to remove the document. If you are the only one who can remove the doc then it is hardly fair that the author should be the one getting 'Cease and desist' letters.
Another important issue to bear in mind is the variability of the laws in different countries: be aware of the law in the country where your pages are hosted.
The final thing to remember is that there are exceptions in copyright law that allow the use of extracts of a larger work for the purposes of criticism etc. and also that there are additional rights granted to non-profit organisations.
I'm not a lawyer, so you should take the above with a pinch of salt.
There is no code copyrighted by the FSF in KDE. Not a single line. This is just RMS trying to gain himself more publicity (as usual).
In fact the vast majority of successfull Open Source and Free Software projects have been developed outside of the FSF. For example Perl, Linux, Apache, KDE, X11... Even gcc suffered badly when the FSF was at the helm, and didn't get properly maintained until the egcs fork. XEmacs is much better than GNU Emacs in many ways too. The FSF and RMS are good at talking, but seem unable to run decent software projects.
The FSF and RMS may once have been a good thing, but for last few years I think they have been mill stones dragging both Open Source and Free Software down.
If you want to use KMail (or any other app) without running the whole desktop, you can. All you need to do is run a couple of standard services (detailed on the KDE web site) and you're done. Using DCOP doesn't tie anything to KDE.
Yes, we've inserted an extra beta. We felt that the previous one was not of the quality we demand, so another beta seemed advisable. That said however if we find that the release candidates are good enough we may still meet the original target.
Obviously we'd like deliver on time, but if it's a choice between timing and quality then we'd prefer to go for quality.
You can have both the terminal view and the icons view, or any other combination of views you want.
Checkout www.konqueror.org if you want some more info about what you can do.
I am fully aware of what the site says, but the question is what does the license say. Companies are legally considered to be a single entity and can freely distribute modified GPL programs, or programs written using GPL libraries internally. The only restriction is if they are able to let anyone else see it. What is needed is to add an explicit restriction about internal distribution (ie. to another person within the same organisation). This is different from simple play or personal customisation, and allows people to develop custom applications for internal use without releasing the code.
1. TrollTech has already said it would GPL Qt, if the GPL v3 prevented proprietary development. Currently it does not, in this respect a lot of the trouble is caused because the FSFs PR engine refuses to admit this. See Eric's piece on FreshMeat a few months back (And Matthias E's comments expanding on it).
2. It is true that KDE 1.x is no longer better than Gnome 1.2, but KDE 2.0 blows Gnome 1.2 away.
You are wrong that the underlying framework for KDE 2.0 will keep changing - it won't. There aren't 'many problems' with it as you claim, there are some bugs sure, but they are getting fixed extremely rapidly.
3. You are so wrong about the difficulty of porting from KDE 1.x to KDE 2.0. Most simple apps can be ported in the most minimal sense of the word in less than half an hour. More complex apps might take a week or so. If you actually look around you'll see that the process of moving over to KDE 2.0 has already begun with many of the non-CVS apps starting to develop 2.0 branches.
This will become more and more common as we approach closer to the release.
I also doubt your comment that more people are developing for Gnome than for KDE. For one thing a big question is what are they writing? In many cases they are still playing catch up for apps KDE had a year ago.
It is really not an issue if Sun and Gnome try to do this - for one thing the effort involved will be huge, and I seriously doubt if the results will justify it. Star Office has some good points, but there's no getting away from the fact that it is a pretty hairy piece of software. By the time such a port becomes usable we will already have KDE 2.1, and maybe even 2.2.
One thing a lot of people has missed is that the plan for KDE 2 is to have a much more rapid release cycle than that between 1.1 and 2.0. We have spent a lot of time making sure that not only will 2.0 be good in itself, but also that it is an API that is well documented and will remain usable for a long time. KDE 2.1 and 2.2 at the least will remain source and binary compatible.
If you had been following this at all, then you would know that KDE 2.0 introduces a powerful object model called KParts. This is used in Koffice, and throughout KDE. You can find a detailed tutorial (a chapter from a forthcoming OPL book on KDE) at http://developer.kde.org/d ocumentation/tutorials/kparts/
It is funny. I did wonder if the Gnome office article was to counteract the discussion about the beta which was planned to come out today. (I don't mean this in a bad way, I interpreted it as an attempt to be balanced).
The guys in Tyrsil have done a great job, the stability is much improved since the meeting. The addition of some great new UI improvements, and stuff like kdcop, dcop etc. are an added bonus.
Yes, the terminal can drive the location of the konqueror views and vice versa. This is part of the more general mechanism for linking views together. You simply check the boxes to link a set of views then they will automatically track each other.
No, it's just that Rik (who wrote most of the text) lost his mail connection for a few days, and didn't get it back until yesterday. As he was working on the text at the time we couldn't release it as soon after Trysil as was intended.
This was fixed in the CVS ages ago. You can also drag images straight out of the browser onto the desktop to set the background image. This will all be in beta 3.
Beta 3 isn't quite ready yet. It is tagged in the CVS, but we have moved the tag a few times to include fixes for problems we considered serious. It will probably be a few days before it is actually released. There are some test tar balls around, but these may not correspond to the actual beta as some or all of these last few bug fixes are probably missing. Please be patient, it won't be long and I think you'll find it worth the wait.
The icon size is configurable via the control center, so if you want smaller icons you can have them. In addition you should bear in mind that the KSpread window in the screenshot is smaller than it would normally be in real use in order to make the screenshot small enough to download quickly.
An applet running in it's own process adds some overhead because it needs context switches and some app specific data to be initialised. Giving you control over what happens means you can choose how you want stability to be played off against speed and memory. The default is that the most common applets (which have been tested most) run in-process, with the others (especially those downloaded from elsewhere) running out-of-process.
Note that the applets are different from the simpler 'system tray' applets which are always out-of-process. The applets being discussed in the report are those such as the clock, task bar, pager etc. The in-process and out-of-process applets use the same API and have the same features, they don't know or care if they are actually running in the same process as the panel.
You can have a separate tree view for directories if you want too. It can even include remote directories such as ftp sites if you like. The same is true of the file dialog.
Your wish is our command! You can have the task bar embedded in the panel, totally hidden, replaced by an icon box down the side of the screen, and more.
It is not true that the GPL prohibits linking non-GPL code, the situation is nowhere near than simple. You would have to delete every GPL graphical program you have if your reading was true, because Xlib isn't GPL.
Please check your facts before spouting such utter drivel. The Qt foundation is anything but garbage. It is true that TT hired one of the KDE representatives, but you fail to mention that the representative then stood down and another took his place. The foundation still exists and still acvhieves it's purpose - ensuring that Open Source developers will always have access to the Qt source no matter what happens at Troll Tech.
Slashdot Mirror
Another important issue to bear in mind is the variability of the laws in different countries: be aware of the law in the country where your pages are hosted.
The final thing to remember is that there are exceptions in copyright law that allow the use of extracts of a larger work for the purposes of criticism etc. and also that there are additional rights granted to non-profit organisations.
I'm not a lawyer, so you should take the above with a pinch of salt.
I think you are being a little ingenuous. If you look at the surrounding context it is pretty clear that he is discussing KDE code.
I am not aware of any. In addition he talks about KDE specifically and says nothing about other Qt apps so your point is moot.
In fact the vast majority of successfull Open Source and Free Software projects have been developed outside of the FSF. For example Perl, Linux, Apache, KDE, X11... Even gcc suffered badly when the FSF was at the helm, and didn't get properly maintained until the egcs fork. XEmacs is much better than GNU Emacs in many ways too. The FSF and RMS are good at talking, but seem unable to run decent software projects.
The FSF and RMS may once have been a good thing, but for last few years I think they have been mill stones dragging both Open Source and Free Software down.
If you want to use KMail (or any other app) without running the whole desktop, you can. All you need to do is run a couple of standard services (detailed on the KDE web site) and you're done. Using DCOP doesn't tie anything to KDE.
Obviously we'd like deliver on time, but if it's a choice between timing and quality then we'd prefer to go for quality.
You can have both the terminal view and the icons view, or any other combination of views you want. Checkout www.konqueror.org if you want some more info about what you can do.
I am fully aware of what the site says, but the question is what does the license say. Companies are legally considered to be a single entity and can freely distribute modified GPL programs, or programs written using GPL libraries internally. The only restriction is if they are able to let anyone else see it. What is needed is to add an explicit restriction about internal distribution (ie. to another person within the same organisation). This is different from simple play or personal customisation, and allows people to develop custom applications for internal use without releasing the code.
1. TrollTech has already said it would GPL Qt, if the GPL v3 prevented proprietary development. Currently it does not, in this respect a lot of the trouble is caused because the FSFs PR engine refuses to admit this. See Eric's piece on FreshMeat a few months back (And Matthias E's comments expanding on it).
2. It is true that KDE 1.x is no longer better than Gnome 1.2, but KDE 2.0 blows Gnome 1.2 away. You are wrong that the underlying framework for KDE 2.0 will keep changing - it won't. There aren't 'many problems' with it as you claim, there are some bugs sure, but they are getting fixed extremely rapidly.
3. You are so wrong about the difficulty of porting from KDE 1.x to KDE 2.0. Most simple apps can be ported in the most minimal sense of the word in less than half an hour. More complex apps might take a week or so. If you actually look around you'll see that the process of moving over to KDE 2.0 has already begun with many of the non-CVS apps starting to develop 2.0 branches. This will become more and more common as we approach closer to the release.
I also doubt your comment that more people are developing for Gnome than for KDE. For one thing a big question is what are they writing? In many cases they are still playing catch up for apps KDE had a year ago.
It is really not an issue if Sun and Gnome try to do this - for one thing the effort involved will be huge, and I seriously doubt if the results will justify it. Star Office has some good points, but there's no getting away from the fact that it is a pretty hairy piece of software. By the time such a port becomes usable we will already have KDE 2.1, and maybe even 2.2.
One thing a lot of people has missed is that the plan for KDE 2 is to have a much more rapid release cycle than that between 1.1 and 2.0. We have spent a lot of time making sure that not only will 2.0 be good in itself, but also that it is an API that is well documented and will remain usable for a long time. KDE 2.1 and 2.2 at the least will remain source and binary compatible.
If you had been following this at all, then you would know that KDE 2.0 introduces a powerful object model called KParts. This is used in Koffice, and throughout KDE. You can find a detailed tutorial (a chapter from a forthcoming OPL book on KDE) at http://developer.kde.org/d ocumentation/tutorials/kparts/
#include <qlabel.h>
int main( int argc, char **argv )
{
QApplication app( argc, argv );
QLabel hello( "Hello World" );
hello.show();
return app.exec();
}
Not in 2.0. It is possible to add it in future though. The performance hit in doing this with a large API however would be quite large.
The guys in Tyrsil have done a great job, the stability is much improved since the meeting. The addition of some great new UI improvements, and stuff like kdcop, dcop etc. are an added bonus.
Yes, the terminal can drive the location of the konqueror views and vice versa. This is part of the more general mechanism for linking views together. You simply check the boxes to link
a set of views then they will automatically track each other.
No, it's just that Rik (who wrote most of the text) lost his mail connection for a few days, and didn't get it back until yesterday. As he was working on the text at the time we couldn't release it as soon after Trysil as was intended.
This was fixed in the CVS ages ago. You can also drag images straight out of the browser onto the desktop to set the background image. This will all be in beta 3.
Beta 3 isn't quite ready yet. It is tagged in the CVS, but we have moved the tag a few times to include fixes for problems we considered serious. It will probably be a few days before it is actually released. There are some test tar balls around, but these may not correspond to the actual beta as some or all of these last few bug fixes are probably missing. Please be patient, it won't be long and I think you'll find it worth the wait.
The icon size is configurable via the control center, so if you want smaller icons you can have them. In addition you should bear in mind that the KSpread window in the screenshot is smaller than it would normally be in real use in order to make the screenshot small enough to download quickly.
The 40 colour icon set is only used if you aren't using a true colour video mode. If you do have true colour, then you get the true colour icon set.
Rich.
Note that the applets are different from the simpler 'system tray' applets which are always out-of-process. The applets being discussed in the report are those such as the clock, task bar, pager etc. The in-process and out-of-process applets use the same API and have the same features, they don't know or care if they are actually running in the same process as the panel.
You can have a separate tree view for directories if you want too. It can even include remote directories such as ftp sites if you like. The same is true of the file dialog.
Your wish is our command! You can have the task bar embedded in the panel, totally hidden, replaced by an icon box down the side of the screen, and more.
It is not true that the GPL prohibits linking non-GPL code, the situation is nowhere near than simple. You would have to delete every GPL graphical program you have if your reading was true, because Xlib isn't GPL.
Please check your facts before spouting such utter drivel. The Qt foundation is anything but garbage. It is true that TT hired one of the KDE representatives, but you fail to mention that the representative then stood down and another took his place. The foundation still exists and still acvhieves it's purpose - ensuring that Open Source developers will always have access to the Qt source no matter what happens at Troll Tech.