Your skiing example is for a customer of the ski area. SCO is not a customer of RedHat, instead they are a third party that believes it has been harmed by RedHat's sales to the customer. Let's assumme SCO is right: RedHat broke into SCO's offices and stole the plans for UnixWare and then sold them to people as new RedHat Linux. Now do you really think RedHat can get away with that by putting some clause into the contract with the people they sell to?
No, unfortunatly any such "license" immediatly makes it illegal to sell (or give away) a copy of Linux containing the code covered by the license. This is because it violates the GPL that covers the rest of Linux.
The only way for this license to have some value is for SCO to identify what part of Linux it covers, and for that part to be a module or a user-level program or library (such licensed properties are allowed to be added to a Linux distributionj). SCO is definately claiming the exact opposite.
No, the license from SCO will not "allow" them to sell Linux, and if SCO's claims are true will actually prevent Sun (or anybody else) from selling Linux.
Assumme SCO's claims are true. If SCO requires payment and an agreement for this code then it is illegal to distribute Linux containing the code, as that directly violates the GPL that grants rights to copy all the rest of the code in Linux (ie it is illegal to redistribute anything *except* SCO's code). Even SCO is not claiming that their code can do anything useful without all the other code covered by the GPL in Linux.
If the affected code is removed from Linux (or SCO or the courts say that there is no claim to it) then anybody can redistribute the new Linux, including Sun, and the SCO license is meaningless.
I would suspect that Sun's lawyers are not as stupid as that, and have actually purchased something of value from SCO, such as the SCO compatability libraries.
What I meant was that Microsoft does not ban Xerox machines, but instead just says "don't use these to violate copyright", like you suggested. In the same way they can easily work with GPL code as long as they say to their programmers "don't copy it into our outside products", they don't have to ban it any more than they have to ban Xerox machines. They have to say the same thing about code the programmers learned from other copyrighted sources such as school, textbooks, their previous jobs, code from business partners (depending on the contract), and code sent in by customers for support questions.
Being able to look at copyrighted code but not copy it into your software is VERY common, happens in a million ways every day in business, and the GPL is in no way special. The only special thing about the GPL is that it gives some rules about how you can violate the copyright, but if you choose not to do that then the GPL is exactly the same as copyright. Business have dealt with copyright for two hundred years and should have no problem working with GPL code, except that Microsoft wants to spew FUD to scare people away from it.
Flaw 2: An end user can't be sued over copyright since he's not the one copying. - This is flawed in that many Linux distributors have
licensing agreements with end users where they waive all responsibility for copyright vioaltions. This shifts the burden from the
copyright infringer to the end user.
I'm sorry, that is BULLSHIT. Okay if that is true, well: I just gave a copy of RedHat to my cat. Part of that giving was that I waived all responsibility for copyright infingement, SCO cannot sue RedHat or me, the burden has shifted to my cat.
You missed part of the "typical interpretation" which I will put in all-caps for you so you don't miss it again:
if you put GPL code in your software that you release as a binary, you have to release the source, no exceptions IF YOU DO NOT WANT TO VIOLATE COPYRIGHT
Yes you are in trouble if you violate the GPL, but not much more than many other ways a company can get in trouble. Last I heard Microsoft is full of xerox machines and CD burners that can be used to violate copyright, and it does not seem to be making them panic.
An implementation is free to use the hacks to get the non-power-of-2 textures. The point is that the hack is now inside OpenGL and thus the interface *allows* a non-hack implementation. This is entirely a good thing. Way too much of OpenGL and X (and Windows GDI and some parts of DirectX) is crap like this where just a trivial amount of extra code would make a better interface, but the implementors don't add it because "it can be done by the user".
Apparently it is very difficult for developers to see where they could improve their interfaces because this sort of design happens so often. Try: if you have a call and it takes arguments, make ALL possible argument combinations do what the caller would expect, even if it is "obvious" how the call should be modified to work. Conversely, don't *add* arguments or calls. It is difficult...
True that may help a lot as improvements to the Linux driver can then also be put into the Windows driver. Thus you could make a reasonable claim that maintinence costs of the Linux driver are actually negative.
What I meant, which may still apply, is that you cannot change your mind and make your drivers (either the Windows or Linux ones) closed-source without either removing all the donated changes or getting permission to all the donated changes.
I'm also under the impression that open-source Windows drivers are impossible as the licensing agreement with Microsoft to get the developers kit disallows that. Is this correct, or is it maybe only true for more complex drivers such as 3d? It does seem possible that it is legal to delete all the Microsoft boilerplate stuff and only leave your changes and open-source that, so there is still a work-around.
If you release it GPL (or any other open-source compatable license) and your first version works at all (it does not crash & it manages to communicate enough signals that at least a light blinks & it contains enough partially-working code to "document" the device) then I would estimate the maintenence costs by multiplying them by zero. The driver would be immediately added to the Linux source and debugged and improved by users of your device. You would probably also make a bunch of sales instantly.
The only downside is that legally you cannot take fixes made by those outside users and put them into your closed-source drivers. However it is highly likely that you can ask the authors of the changes for permission to use the code, one way to convince them is to say that doing that is the only way for their code to get into the "official linux driver" that can be downloaded from your web page.
No, that licensing agreement is a meaningless piece of FUD designed to help the SCO case scare more people.
People who bought Microsoft's software are not liable for anything the company does (same for people who bought Linux, no matter what SCO does). Microsoft could be found guilty of helping terrorists and killing kittens and users of Windows would not have to pay anything, since they had no idea they were helping these evil acts.
I mean really, think about it. There is 100% chance that somebody you bought something from is guilty of a crime or is the target of a lawsuit. Do you really think this affects you at all?
If you ignore the jokes, it is pretty clear that Slashdot unaimously thinks Microsoft is the one to root for. Read the comments please, and find one serious one that does not say that the InterTrust is evil for this.
Since the cracker could not read the files originally, I don't see how they are worse off after changing the password. Perhaps now they have access to some data (perhaps over the network) that they did not have before and they can use that to find out the password, and thus are closer to decoding that encrypted data than before.
I agree the original poster is being silly. The exact same "attack" will work on Linux and every other operating system and is not a Windows bug.
Whatever. I was not complaining about either the current system or pure capitalism. What I was saying was that the current system != pure capitalism. Yes it actually employs a lot of people and most of the people using it are happy. But defending it as "capitalism" is as hypocritical as defending affirmative action as "freedom".
Those "new cars" are replacing "old cars" and thus absorbing tens of thousands of dollars from each consumer and preventing them from buying new stuff. And all those people at Home Depot are buying stuff to fix their houses, they are not buying new vacation homes. They are being told what to buy by H&G TV, which is owned by a big conglomerate just like Home Depot and the manufacturers of every single item in that store. Check out how many different brands of the same item you can get at home depot, in almost every case there is ONE brand, and thus zero competition.
I would agree that true capitalism is dead, it has been replaced by the current system. And "capitalists" who defend the current system are as big of hyprocrites as the supposedly librearl Democrats who pass the DMCA and defend the RIAA/MPAA.
Re:This next election is important
on
Saving the Net
·
· Score: 1
The problem is that it is 100% guaranteed that neither major candidate will "get it", and voting for the Green or Libertarian is useless.
Absolutely agree with you
on
Qt On DirectFB
·
· Score: 1
I want one of those "consistent user interface" people to show me a real person who is "confused" because the buttons in one program are a different color than the buttons in another program.
"Consistent user interface" is a fraud being thrown at us as a way to prevent programs from exploring new interface ideas and prevent systems from being designed where it is possible to program at low levels so that programs can be easily ported between completely different low-level implementations.
People once believed that database queries and record structures had to be understood by the base filesystem, or else programs would never be able to share files (take a look at VMS and the "pip" programs). Fortunatley the plain filesystems of Multics/Unix showed this to not only be false, but actually completely the opposite of what was true, and now we have programs that can read/write files on every operating system in the world and written by every other program, we have disks that are a MILLION times larger than the disks in use when the filesystem interface was designed but the programs can still use them, and we can transparenlty read/write files over a network that was not even imagined in 1970.
Yet 30 years later GUI design is still held down by a bunch of people who think that the idea of "menu" should be built into the operating system. Lets learn from what worked for filesystems, everybody!
Again remote desktop is NOT the problem
on
Qt On DirectFB
·
· Score: 1
The X clipboard protocol is designed to work over remote desktop. Once again legitimate complaints about X are going to get ignored because the people saying them continue to say stupid things at the same time, allowing the equally stupid X defenders to dismiss them as idiots.
The X clipboard protocol has only one huge technical problem, which is that it has a nasty complex interface so that "large" blocks can be copied (this was designed back when it was common to cut a piece of data larger than the memory on the X server, this is probably not true today), and typical X stupidity of not adding a modern call which hides this silly and obsolete interface. Otherwise the X protocol is exactly equivalent to what Windows has, with the advantage that there are more than one clipboard and that it was designed from the start to defer the communication of the data until the paste request comes (Windows was forced to kludge this on).
However the real problem is that while both X and Windows had a symbol that indicated the "type" of the data, Windows went through the simple step of assigning some predefined types. The X people instead felt that should be left to the programmers. The end result is that we have about 10 ways of cutting/pasting text (I know I have seen them all in an attempt to accept UTF-8 pasting) and no defined symbols that mean anything else. Meanwhile Windows went and said the number 10 (or something) means a.bmp file, and despite the fact that that format is terrible and inefficient, at least it allowed a picture to be sent and all the software agrees it is a picture!
In any case both are obsolete. What we really need is and interface that sends UTF-8 text and UTF-8 encoded arbitrary URL's. An image would actually be sent by writing it (hopefully to a temporary filesystem) and sending a URL to it. Since all programs probably know how to read/write their own data to files, this would allow them to communicate clipboard data with little extra code. Also it provides a human-readable fallback when the data cannot be interpreted.
Remote display is NOT the problem
on
Qt On DirectFB
·
· Score: 1
X may have a boatload of problems, but remote display is NOT one of them. Unfortunatley as long as idiots keep saying this, people who like X will keep associating anybody who says anything bad about X with know-nothing idiots who think that getting rid of remote display will fix anything.
Microsoft is working very very hard right now on adding remote display to their interface. This is because it is vitally needed and they screwed up by making some assumptions (mostly about the instant delivery of PAINT events, and too many calls that programs assumme are synchronous) that are making this hard while remianing compatable. The remote display adds ZERO to the time it takes to draw anything, every single GDI call is a call into a library that can decide whether to draw locally or remotely (or perhaps you didn't notice that GDI can already redirect calls to your printer, which is a remote device) and this redirection requires no more code if there is a possible target that is remote.
Now the difficulty is that even though remote display is not a problem, X still sucks. The main reasons:
1. horrid graphics model that requires any modern interace appearance to draw locally and send bitmapped images to get the display they want.
2. Many many synchronous calls (calls that return values). Asynchronous calls can be inserted into a buffer and sent at once, resulting in a 1/1000 or so ratio of context switches to calls, which makes the arguments used by Windows to put graphics in the kernel (which changed the ratio from 2 to 1) look terrible. But synchronous calls completely ruin this, and huge numbers of them are needed, especially for all the kludges needed to talk to the desktop environments.
3. Window managers seperate from programs. This produces the most objectionable redisplay problems, the ones that are not solved even though machines have sped up 100's of times, since there can always be the lag of one program or the other being swapped out. The time has come for people to give up their beloved window managers and realize that these are widgets just like everything else and put them into the local toolkit. Also anybody who suggests that more widgets should be in the server is an idiot, it should be obvious this is a VERY VERY BAD idea if you just look at the problems with window managers.
Jot uses X and OpenGL. All older Irix programs using OpenGL failed over a network to non-IRIX as they used a proprietary extension to communicate the OpenGL calls. OpenGL was not used to make widgets.
You may be thinking of earlier Irix machines that used NeWS, which really did have the widgets on the server end. Unfortunatley this was almost unused and everybody used it's X emulation.
So it sounds like the main problem is adding links to the start menu.
Why not have the program offer to do this when it is first run? The user downloads an executable and it appears on their desktop. They then double-click it and it runs. It examines the start menu and if no link is there it pops up a question asking if you wan to install it. The user can say yes/no/later. If they say yes it adds the startup item.
No, in all cases that have happened so far the GPL violators have elected to publish the code, and the FSF (or whoever what threatening the lawsuit) then offered to drop the charges despite the fact that the party was still guilty of GPL violations for the time before they published the code.
I believe you can use static linking even with the most strict interpretation of the GPL, at least technically.
The worst possible thing is that you must distribute.o files and instructions on how to link them.
I think it is legal to offer, for free, to relink the application with any version of the library a user submits.
However personally I think the whole LGPL is wrong here. These rules provide no benifit to the end user: any possible enhancement of the LGPL library is probably useless unless you can rewrite the calling program to use it, and every other change is a "bug fix" and I would much prefer a situation where such fixes have to be propagated back to the original author or at least to a lot of users of the LGPL software.
We desperately need an "LGPL" that is explicitly worded to mean exactly what most users think it means: they cannot modify the library without redistributing the source, but they can use the library all they want.
Currently I use the LGPL with an "exception" that basically says a program that links with the library has not restrictions at all, however you cannot modify the library itself without releasing those modifications. However I would much rather see a license designed from the start to do this.
No you don't get it. He wants to allow people to modify his library, and be free to use the modified library in their closed-source program, but be forced to release the modifications *themselves*. Making a binary version does not allow such modifications.
I am also in the same postion. I want my code to be used as much as possible, but I do not want it "embraced and extended". Therefore I would like people to be free to use the library in any way they want. But if they change the library, they must release their changes. They are then free to use the changed library in any way they want, just like the original.
I suspect this can be done with a license that basically says you must release any modifications you make to the original source code if you redistribute anything derived from it. The rules have to be more complex than that so that your modification is not "+call_secret_stuff()" where the implementation of call_secret_stuff() in in a new source file you don't distribute. I think also this is what almost everybody (other than RMS) expects and wants the LGPL to do.
Is there any license that does this and is legally sound? All I have seen is LGPL with "exceptions" but that seems much too complex for what is wanted.
It is probably reading the KDE settings from the file ~/.kde/share/config/kdeglobals. Older versions of KDE stored them in ~/.kderc so look there as well. The file is text in the "INI" style format, so it should be possible to edit it with a text editor.
You can also run the "kcontrol" program without running KDE and mess with the color settings in there.
Slashdot Mirror
Your skiing example is for a customer of the ski area. SCO is not a customer of RedHat, instead they are a third party that believes it has been harmed by RedHat's sales to the customer. Let's assumme SCO is right: RedHat broke into SCO's offices and stole the plans for UnixWare and then sold them to people as new RedHat Linux. Now do you really think RedHat can get away with that by putting some clause into the contract with the people they sell to?
The only way for this license to have some value is for SCO to identify what part of Linux it covers, and for that part to be a module or a user-level program or library (such licensed properties are allowed to be added to a Linux distributionj). SCO is definately claiming the exact opposite.
Assumme SCO's claims are true. If SCO requires payment and an agreement for this code then it is illegal to distribute Linux containing the code, as that directly violates the GPL that grants rights to copy all the rest of the code in Linux (ie it is illegal to redistribute anything *except* SCO's code). Even SCO is not claiming that their code can do anything useful without all the other code covered by the GPL in Linux.
If the affected code is removed from Linux (or SCO or the courts say that there is no claim to it) then anybody can redistribute the new Linux, including Sun, and the SCO license is meaningless.
I would suspect that Sun's lawyers are not as stupid as that, and have actually purchased something of value from SCO, such as the SCO compatability libraries.
Being able to look at copyrighted code but not copy it into your software is VERY common, happens in a million ways every day in business, and the GPL is in no way special. The only special thing about the GPL is that it gives some rules about how you can violate the copyright, but if you choose not to do that then the GPL is exactly the same as copyright. Business have dealt with copyright for two hundred years and should have no problem working with GPL code, except that Microsoft wants to spew FUD to scare people away from it.
licensing agreements with end users where they waive all responsibility for copyright vioaltions. This shifts the burden from the
copyright infringer to the end user.
I'm sorry, that is BULLSHIT. Okay if that is true, well: I just gave a copy of RedHat to my cat. Part of that giving was that I waived all responsibility for copyright infingement, SCO cannot sue RedHat or me, the burden has shifted to my cat.
I think it is plainly obvious that you are wrong.
if you put GPL code in your software that you release as a binary, you have to release the source, no exceptions IF YOU DO NOT WANT TO VIOLATE COPYRIGHT
Yes you are in trouble if you violate the GPL, but not much more than many other ways a company can get in trouble. Last I heard Microsoft is full of xerox machines and CD burners that can be used to violate copyright, and it does not seem to be making them panic.
Apparently it is very difficult for developers to see where they could improve their interfaces because this sort of design happens so often. Try: if you have a call and it takes arguments, make ALL possible argument combinations do what the caller would expect, even if it is "obvious" how the call should be modified to work. Conversely, don't *add* arguments or calls. It is difficult...
What I meant, which may still apply, is that you cannot change your mind and make your drivers (either the Windows or Linux ones) closed-source without either removing all the donated changes or getting permission to all the donated changes.
I'm also under the impression that open-source Windows drivers are impossible as the licensing agreement with Microsoft to get the developers kit disallows that. Is this correct, or is it maybe only true for more complex drivers such as 3d? It does seem possible that it is legal to delete all the Microsoft boilerplate stuff and only leave your changes and open-source that, so there is still a work-around.
What are you talking about? Both IE and Mozilla have a way to "whitelist" by URL, which would be much easier to use than your "change session" idea.
The only downside is that legally you cannot take fixes made by those outside users and put them into your closed-source drivers. However it is highly likely that you can ask the authors of the changes for permission to use the code, one way to convince them is to say that doing that is the only way for their code to get into the "official linux driver" that can be downloaded from your web page.
People who bought Microsoft's software are not liable for anything the company does (same for people who bought Linux, no matter what SCO does). Microsoft could be found guilty of helping terrorists and killing kittens and users of Windows would not have to pay anything, since they had no idea they were helping these evil acts.
I mean really, think about it. There is 100% chance that somebody you bought something from is guilty of a crime or is the target of a lawsuit. Do you really think this affects you at all?
If you ignore the jokes, it is pretty clear that Slashdot unaimously thinks Microsoft is the one to root for. Read the comments please, and find one serious one that does not say that the InterTrust is evil for this.
I agree the original poster is being silly. The exact same "attack" will work on Linux and every other operating system and is not a Windows bug.
Whatever. I was not complaining about either the current system or pure capitalism. What I was saying was that the current system != pure capitalism. Yes it actually employs a lot of people and most of the people using it are happy. But defending it as "capitalism" is as hypocritical as defending affirmative action as "freedom".
I would agree that true capitalism is dead, it has been replaced by the current system. And "capitalists" who defend the current system are as big of hyprocrites as the supposedly librearl Democrats who pass the DMCA and defend the RIAA/MPAA.
The problem is that it is 100% guaranteed that neither major candidate will "get it", and voting for the Green or Libertarian is useless.
"Consistent user interface" is a fraud being thrown at us as a way to prevent programs from exploring new interface ideas and prevent systems from being designed where it is possible to program at low levels so that programs can be easily ported between completely different low-level implementations.
People once believed that database queries and record structures had to be understood by the base filesystem, or else programs would never be able to share files (take a look at VMS and the "pip" programs). Fortunatley the plain filesystems of Multics/Unix showed this to not only be false, but actually completely the opposite of what was true, and now we have programs that can read/write files on every operating system in the world and written by every other program, we have disks that are a MILLION times larger than the disks in use when the filesystem interface was designed but the programs can still use them, and we can transparenlty read/write files over a network that was not even imagined in 1970.
Yet 30 years later GUI design is still held down by a bunch of people who think that the idea of "menu" should be built into the operating system. Lets learn from what worked for filesystems, everybody!
The X clipboard protocol has only one huge technical problem, which is that it has a nasty complex interface so that "large" blocks can be copied (this was designed back when it was common to cut a piece of data larger than the memory on the X server, this is probably not true today), and typical X stupidity of not adding a modern call which hides this silly and obsolete interface. Otherwise the X protocol is exactly equivalent to what Windows has, with the advantage that there are more than one clipboard and that it was designed from the start to defer the communication of the data until the paste request comes (Windows was forced to kludge this on).
However the real problem is that while both X and Windows had a symbol that indicated the "type" of the data, Windows went through the simple step of assigning some predefined types. The X people instead felt that should be left to the programmers. The end result is that we have about 10 ways of cutting/pasting text (I know I have seen them all in an attempt to accept UTF-8 pasting) and no defined symbols that mean anything else. Meanwhile Windows went and said the number 10 (or something) means a .bmp file, and despite the fact that that format is terrible and inefficient, at least it allowed a picture to be sent and all the software agrees it is a picture!
In any case both are obsolete. What we really need is and interface that sends UTF-8 text and UTF-8 encoded arbitrary URL's. An image would actually be sent by writing it (hopefully to a temporary filesystem) and sending a URL to it. Since all programs probably know how to read/write their own data to files, this would allow them to communicate clipboard data with little extra code. Also it provides a human-readable fallback when the data cannot be interpreted.
Microsoft is working very very hard right now on adding remote display to their interface. This is because it is vitally needed and they screwed up by making some assumptions (mostly about the instant delivery of PAINT events, and too many calls that programs assumme are synchronous) that are making this hard while remianing compatable. The remote display adds ZERO to the time it takes to draw anything, every single GDI call is a call into a library that can decide whether to draw locally or remotely (or perhaps you didn't notice that GDI can already redirect calls to your printer, which is a remote device) and this redirection requires no more code if there is a possible target that is remote.
Now the difficulty is that even though remote display is not a problem, X still sucks. The main reasons:
1. horrid graphics model that requires any modern interace appearance to draw locally and send bitmapped images to get the display they want.
2. Many many synchronous calls (calls that return values). Asynchronous calls can be inserted into a buffer and sent at once, resulting in a 1/1000 or so ratio of context switches to calls, which makes the arguments used by Windows to put graphics in the kernel (which changed the ratio from 2 to 1) look terrible. But synchronous calls completely ruin this, and huge numbers of them are needed, especially for all the kludges needed to talk to the desktop environments.
3. Window managers seperate from programs. This produces the most objectionable redisplay problems, the ones that are not solved even though machines have sped up 100's of times, since there can always be the lag of one program or the other being swapped out. The time has come for people to give up their beloved window managers and realize that these are widgets just like everything else and put them into the local toolkit. Also anybody who suggests that more widgets should be in the server is an idiot, it should be obvious this is a VERY VERY BAD idea if you just look at the problems with window managers.
You may be thinking of earlier Irix machines that used NeWS, which really did have the widgets on the server end. Unfortunatley this was almost unused and everybody used it's X emulation.
So it sounds like the main problem is adding links to the start menu.
Why not have the program offer to do this when it is first run? The user downloads an executable and it appears on their desktop. They then double-click it and it runs. It examines the start menu and if no link is there it pops up a question asking if you wan to install it. The user can say yes/no/later. If they say yes it adds the startup item.
No, in all cases that have happened so far the GPL violators have elected to publish the code, and the FSF (or whoever what threatening the lawsuit) then offered to drop the charges despite the fact that the party was still guilty of GPL violations for the time before they published the code.
The worst possible thing is that you must distribute .o files and instructions on how to link them.
I think it is legal to offer, for free, to relink the application with any version of the library a user submits.
However personally I think the whole LGPL is wrong here. These rules provide no benifit to the end user: any possible enhancement of the LGPL library is probably useless unless you can rewrite the calling program to use it, and every other change is a "bug fix" and I would much prefer a situation where such fixes have to be propagated back to the original author or at least to a lot of users of the LGPL software.
We desperately need an "LGPL" that is explicitly worded to mean exactly what most users think it means: they cannot modify the library without redistributing the source, but they can use the library all they want.
Currently I use the LGPL with an "exception" that basically says a program that links with the library has not restrictions at all, however you cannot modify the library itself without releasing those modifications. However I would much rather see a license designed from the start to do this.
I am also in the same postion. I want my code to be used as much as possible, but I do not want it "embraced and extended". Therefore I would like people to be free to use the library in any way they want. But if they change the library, they must release their changes. They are then free to use the changed library in any way they want, just like the original.
I suspect this can be done with a license that basically says you must release any modifications you make to the original source code if you redistribute anything derived from it. The rules have to be more complex than that so that your modification is not "+call_secret_stuff()" where the implementation of call_secret_stuff() in in a new source file you don't distribute. I think also this is what almost everybody (other than RMS) expects and wants the LGPL to do.
Is there any license that does this and is legally sound? All I have seen is LGPL with "exceptions" but that seems much too complex for what is wanted.
You can also run the "kcontrol" program without running KDE and mess with the color settings in there.