Cheney later clarified the President's remarks. "President Bush and I have a deep and everlasting respect for the great accomplishments that the Russians and former Sovet republics have achieved in the field of space travel," he said while affixing a ball gag to the President.
"Is this treading the dangerous waters of non-backwards compatibility?
Not that I can see. The new version is adding a new feature. This happens all the time. In order to be non-backwards compatible, the 2.0 features would have to be something other than a strict superset of 1.2 features. The article doesn't imply this at all. It would have to be the other way around to be non-backwards compatible. (I.e. Someone wrote anti-aliasing support for GTK+ 1.x, and no one was forward-porting it to 2.0, so that 2.0 would lack a feature that 1.x had).
There are lots of digital signals on C-Band, many of them using DigiCypher technology, which is basically an MPEG stream, similar to the pizza dish technology. People don't seem to realize that the digital signal is only a digitized version of an analog signal pulled off some other satellite, so how can it possibly have better quality than the analog signal? In my experience, I have never seen a better picture than an analog signal off my 10' dish. That includes pizza dishes, cable, antenna, VHS, and DVD.
At Acadia University (Nova Scotia, Canada), where I did my undergrad, it was very clear that I retained the copyright on my thesis. Upon completion, I was asked to sign a paper that would give the university library the right to retain one copy of my thesis and loan it out to people who asked for it. (I suppose I could have refused to sign it). I did this, and I could have licensed the software in any way I liked. This is standard practice at Acadia, although I'm not sure if it differs for Grad students (I doubt it). I was on scholarship from the university at the time, which didn't make a difference w.r.t. copyright ownership.
Now that I'm a grad student at a different university, and employed by a big blue subsidiary, the situation is different. Although I am funded, it is through my work, through an industry scholarship, and through a TA position at school. I never signed anything saying that Carleton owns my creative works; if they claim that they do, they'll have to fight it out with my workplace, as they have first claim as far as I can tell.
Only big difference is Look is Microwave-based, which means you have to have a line of sight to the microwave tower. This limits it to a range on the order of 10's of kilometres, rather than most of a hemisphere covered by a satellite. Microwave towers must be installed in your town, which limits probability of rural users getting in any time soon.
They sent around another kiss-ass message saying that things are getting better today. All I know is that it's been months since I've been able to depend on incoming email getting delivered in less than a week and outgoing email getting delivered at all.
From LICQ's home page: "Licq is distributed under GPL with some special QPL exceptions for Qt.". So there is no problem distributing LICQ in Debian. KDE does not contain such an exception, so there is a problem.
By the way, depending on your point of view, the problem is NOT with the QPL, nor is the problem with the GPL. The problem is that the two are not compatible in any coherent legal sense, so using or distributing products which combine these two licenses (KDE + QT) is not permitted.
I didn't say that non-free == evil. In case you weren't actually trolling, Debian is, among other things, a distribution that may be freely distributed by anyone for any reason. The packages in non-free have restrictions on them such that they may not necessarily be distributed by anyone for any reason. If I was a CD vendor who wanted to press Debian CDs and sell them, there are packages in non-free that I would not be allowed to distribute. It's as simple as that. It seems to be confused somewhat by the fact that other distribution vendors have little or no regard for the licences on these pieces of software, and choose to distribute them anyway.
The current QT release is 2.1.1, which does meet Debian's open source guidelines (the page you looked at was old. Go to www.troll.no to find the latest version).
From what I've gathered from mailing list discussions, the KDE developers will not acknowledge that there is a problem, which makes it very difficult to fix. If they acknowledged there was a problem, then all the other distributions in the world (RedHat, Mandrake, etc) which ship KDE just might sit up, take notice, and realize that it is illegal for them to shipping it. That would not be good for KDE.
However, this situation is pretty unproductive. This isn't the first time someone has taken the initiative to try to fix this; the Debian people have talked to the KDE people on a number of occasions trying to get this fixed to no avail.
Just to be clear, this problem only applies to the parts of KDE that use QT (i.e. the user interface). The KDE libs are GPL and do not use QT, so they are legal for use and for distribution.
Didn't you read the letter? There IS NO specific addition to the GPL in KDE's license which say s that the code may be linked with Qt. If there was, there would be no problem, no story, no discussion, and KDE would be in Debian.
The QPL is a free software license; Debian accepts software licensed under the QPL. The GPL is also a free software license; Debian accepts software licensed under the GPL. The terms of the QPL and the GPL are incompatible, such that binaries licensed under the GPL may not legally link to binaries licensed under the QPL - this is why a special exception is required by the copyright holders of the KDE programs.
It was not mentioned in the article that the simplest solution of all would be for TrollTech to modify the terms of the QPL such that it would be compatible with the GPL. I'm not advocating that they do this (or don't do this), I'm just saying that would be a simple solution.
He did. Do you think that he tarred up and released the first Linux kernel the minute that it worked on his machine? I don't think so. Release Early is important, but so also is releasing code when it's ready - and if you KNOW that your code needs improvement before it's ready for consumption, why would you release an unpolished, buggy, incomplete package? Sometimes a little bit of work would push it above the usability threshold, below which people probably wouldn't take a second look at it.
Only copyright holders have the right to license the code. Therefore, in order to assert that the code is covered by the GPL, the person would have to be the copyright holder. Code without a copyright holder (i.e. Public Domain) cannot have a license.
The Palm has a com port on the bottom, which has a proprietary connector. This usually connects to a cradle or a hot-sync cable, which has a normal 9-pin connection at the other end. This may be plugged into your PC, notebook, cell phone, or other device. You can do TCP/IP through this COM port and make the palm a real host on your network fairly easily. Having said all that, I have no idea if this game supports multiplayer, or if it supports the com port.
I don't see how vendors could make a dime. The only people who have legal recourse against Abit are the copyright holders of the software whose license has been violated. I.e. the authors of hdparm or whatever other utilities. Unless RedHat holds the copyright on the utility (I don't think they do), I don't see a lawsuit from them.
Wine is not developed under the GPL. It's distributed under a modified BSD license, but should shortly change to the X11 license, pending approval from all copyright holders (of which I am one).
This thread has started some rumours that may lead to misinformation, so let me report what I KNOW from reading the wine-devel mailing list:
1. Corel is very committed to Wine and will be shipping apps based on winelib in the very near future.
2. Until fairly recently (meaning up until the last month or so), Corel has been VERY dilligent about sending MANY patches to the wine-patches mailing list, from which Alexandre (the Wine project lead) applies some or all to the wine codebase. Their contributions have been numerous.
3. According to an email that was accidentally sent to wine-devel by one of the Corel engineers, as Corel approaches the release of their beta, they will be focusing on shipping the product and have thus put patch contributes to Wine on the back burner FOR NOW. They are in the business of shipping software, and given their manpower, this was the most efficient thing for them to do at the time. When the software ships, they will send all of their pending patches to wine and business continues as usual. Merging patches from Corel's internal tree, preparing them and mailing them to the wine-patches list, and subsequently modifying or rewriting those that are not immediately accepted is a time-consuming process, and I guess they just need to use the time for something else at this particular point, namely polishing up their internal wine tree to the point where they can ship software based on it.
The Corel engineers have been very active participants on the wine mailing lists and I think we owe them all a big thank you for all of their work. Wine has improved dramatically in the past year. I have seen nothing that would cause me to doubt Corel's dedication to Wine as a solution to shipping Linux applications. Judging by the screenshots I've seen of Quattro Pro and other Corel apps running against winelib, we're all in for some spectacular Linux apps.
...many times on linux-kernel. The short story is that Linus will never do this, but obviously won't stop someone else if they want to give it a try.
However, the benefit of doing this is minimal. The majority of the code in the kernel is not in the arch/ subdirectories, but rather in the drivers. A more reasonable approach to me would seem to be some sort of dynamic system (web-driven or otherwise), where you could go and "order" a custom kernel tarball (i.e. i386, SB32, NE2000, nfs and firewall support) and out pops a stripped-down kernel source tree with the appropriate subset of the kernel proper.
Actually, it is based on Debian. Disclaimer: I haven't tried it. It is different from Debian first of all because it incorporates KDE; Debian does not include KDE because of potential legal issues (no flamewars, just a fact). Corel has also apparently put quite a bit of effort into the areas of both installation and configuration, creating some KDE-based front-ends that look quite nice from the screenshots. It is also presumably different from Debian because Corel will provide official support for your purchase, whereas Debian does not market or officially support their product.
Slashdot Mirror
>> Will 6 have grammerchecking?
^^^^^^^^^^^^^^^^
Word not found.
Suggested replacement: "grammar checking"
That is all.
Thank you,
StarOffice
Who can tell me the atomic weight of Bolognium?
Cheney later clarified the President's remarks. "President Bush and I have a deep and everlasting respect for the great accomplishments that the Russians and former Sovet republics have achieved in the field of space travel," he said while affixing a ball gag to the President.
Not that I can see. The new version is adding a new feature. This happens all the time. In order to be non-backwards compatible, the 2.0 features would have to be something other than a strict superset of 1.2 features. The article doesn't imply this at all. It would have to be the other way around to be non-backwards compatible. (I.e. Someone wrote anti-aliasing support for GTK+ 1.x, and no one was forward-porting it to 2.0, so that 2.0 would lack a feature that 1.x had).
There are lots of digital signals on C-Band, many of them using DigiCypher technology, which is basically an MPEG stream, similar to the pizza dish technology. People don't seem to realize that the digital signal is only a digitized version of an analog signal pulled off some other satellite, so how can it possibly have better quality than the analog signal? In my experience, I have never seen a better picture than an analog signal off my 10' dish. That includes pizza dishes, cable, antenna, VHS, and DVD.
At Acadia University (Nova Scotia, Canada), where I did my undergrad, it was very clear that I retained the copyright on my thesis. Upon completion, I was asked to sign a paper that would give the university library the right to retain one copy of my thesis and loan it out to people who asked for it. (I suppose I could have refused to sign it). I did this, and I could have licensed the software in any way I liked. This is standard practice at Acadia, although I'm not sure if it differs for Grad students (I doubt it). I was on scholarship from the university at the time, which didn't make a difference w.r.t. copyright ownership.
Now that I'm a grad student at a different university, and employed by a big blue subsidiary, the situation is different. Although I am funded, it is through my work, through an industry scholarship, and through a TA position at school. I never signed anything saying that Carleton owns my creative works; if they claim that they do, they'll have to fight it out with my workplace, as they have first claim as far as I can tell.
Only big difference is Look is Microwave-based, which means you have to have a line of sight to the microwave tower. This limits it to a range on the order of 10's of kilometres, rather than most of a hemisphere covered by a satellite. Microwave towers must be installed in your town, which limits probability of rural users getting in any time soon.
Slashdot needs a new rating for messages:
+1 Funny, but sad because it's true
They sent around another kiss-ass message saying that things are getting better today. All I know is that it's been months since I've been able to depend on incoming email getting delivered in less than a week and outgoing email getting delivered at all.
Mirroring allows others to view it even if the original site gets slashdotted. Yes, it's probably copyright infringement.
Because then MS is seen as embracing and promoting an open standard. Aren't they nice?
From LICQ's home page:
"Licq is distributed under GPL with some special QPL exceptions for Qt.". So there is no problem distributing LICQ in Debian. KDE does not contain such an exception, so there is a problem.
By the way, depending on your point of view, the problem is NOT with the QPL, nor is the problem with the GPL. The problem is that the two are not compatible in any coherent legal sense, so using or distributing products which combine these two licenses (KDE + QT) is not permitted.
I didn't say that non-free == evil. In case you weren't actually trolling, Debian is, among other things, a distribution that may be freely distributed by anyone for any reason. The packages in non-free have restrictions on them such that they may not necessarily be distributed by anyone for any reason. If I was a CD vendor who wanted to press Debian CDs and sell them, there are packages in non-free that I would not be allowed to distribute. It's as simple as that. It seems to be confused somewhat by the fact that other distribution vendors have little or no regard for the licences on these pieces of software, and choose to distribute them anyway.
The current QT release is 2.1.1, which does meet Debian's open source guidelines (the page you looked at was old. Go to www.troll.no to find the latest version).
From what I've gathered from mailing list discussions, the KDE developers will not acknowledge that there is a problem, which makes it very difficult to fix. If they acknowledged there was a problem, then all the other distributions in the world (RedHat, Mandrake, etc) which ship KDE just might sit up, take notice, and realize that it is illegal for them to shipping it. That would not be good for KDE.
However, this situation is pretty unproductive. This isn't the first time someone has taken the initiative to try to fix this; the Debian people have talked to the KDE people on a number of occasions trying to get this fixed to no avail.
Just to be clear, this problem only applies to the parts of KDE that use QT (i.e. the user interface). The KDE libs are GPL and do not use QT, so they are legal for use and for distribution.
Didn't you read the letter? There IS NO specific addition to the GPL in KDE's license which say s that the code may be linked with Qt. If there was, there would be no problem, no story, no discussion, and KDE would be in Debian.
The QPL is a free software license; Debian accepts software licensed under the QPL.
The GPL is also a free software license; Debian accepts software licensed under the GPL.
The terms of the QPL and the GPL are incompatible, such that binaries licensed under the GPL may not legally link to binaries licensed under the QPL - this is why a special exception is required by the copyright holders of the KDE programs.
It was not mentioned in the article that the simplest solution of all would be for TrollTech to modify the terms of the QPL such that it would be compatible with the GPL. I'm not advocating that they do this (or don't do this), I'm just saying that would be a simple solution.
Non-free is not part of Debian.
He did. Do you think that he tarred up and released the first Linux kernel the minute that it worked on his machine? I don't think so. Release Early is important, but so also is releasing code when it's ready - and if you KNOW that your code needs improvement before it's ready for consumption, why would you release an unpolished, buggy, incomplete package? Sometimes a little bit of work would push it above the usability threshold, below which people probably wouldn't take a second look at it.
Only copyright holders have the right to license the code. Therefore, in order to assert that the code is covered by the GPL, the person would have to be the copyright holder. Code without a copyright holder (i.e. Public Domain) cannot have a license.
RTFAQ. MWM is released with the rest of the toolkit.
The Palm has a com port on the bottom, which has a proprietary connector. This usually connects to a cradle or a hot-sync cable, which has a normal 9-pin connection at the other end. This may be plugged into your PC, notebook, cell phone, or other device. You can do TCP/IP through this COM port and make the palm a real host on your network fairly easily. Having said all that, I have no idea if this game supports multiplayer, or if it supports the com port.
I don't see how vendors could make a dime. The only people who have legal recourse against Abit are the copyright holders of the software whose license has been violated. I.e. the authors of hdparm or whatever other utilities. Unless RedHat holds the copyright on the utility (I don't think they do), I don't see a lawsuit from them.
Wine is not developed under the GPL. It's distributed under a modified BSD license, but should shortly change to the X11 license, pending approval from all copyright holders (of which I am one).
This thread has started some rumours that may lead to misinformation, so let me report what I KNOW from reading the wine-devel mailing list:
1. Corel is very committed to Wine and will be shipping apps based on winelib in the very near future.
2. Until fairly recently (meaning up until the last month or so), Corel has been VERY dilligent about sending MANY patches to the wine-patches mailing list, from which Alexandre (the Wine project lead) applies some or all to the wine codebase. Their contributions have been numerous.
3. According to an email that was accidentally sent to wine-devel by one of the Corel engineers, as Corel approaches the release of their beta, they will be focusing on shipping the product and have thus put patch contributes to Wine on the back burner FOR NOW. They are in the business of shipping software, and given their manpower, this was the most efficient thing for them to do at the time. When the software ships, they will send all of their pending patches to wine and business continues as usual. Merging patches from Corel's internal tree, preparing them and mailing them to the wine-patches list, and subsequently modifying or rewriting those that are not immediately accepted is a time-consuming process, and I guess they just need to use the time for something else at this particular point, namely polishing up their internal wine tree to the point where they can ship software based on it.
The Corel engineers have been very active participants on the wine mailing lists and I think we owe them all a big thank you for all of their work. Wine has improved dramatically in the past year. I have seen nothing that would cause me to doubt Corel's dedication to Wine as a solution to shipping Linux applications. Judging by the screenshots I've seen of Quattro Pro and other Corel apps running against winelib, we're all in for some spectacular Linux apps.
...many times on linux-kernel. The short story is that Linus will never do this, but obviously won't stop someone else if they want to give it a try.
However, the benefit of doing this is minimal. The majority of the code in the kernel is not in the arch/ subdirectories, but rather in the drivers. A more reasonable approach to me would seem to be some sort of dynamic system (web-driven or otherwise), where you could go and "order" a custom kernel tarball (i.e. i386, SB32, NE2000, nfs and firewall support) and out pops a stripped-down kernel source tree with the appropriate subset of the kernel proper.
Actually, it is based on Debian. Disclaimer: I haven't tried it. It is different from Debian first of all because it incorporates KDE; Debian does not include KDE because of potential legal issues (no flamewars, just a fact). Corel has also apparently put quite a bit of effort into the areas of both installation and configuration, creating some KDE-based front-ends that look quite nice from the screenshots. It is also presumably different from Debian because Corel will provide official support for your purchase, whereas Debian does not market or officially support their product.