They used them to protect the ASF file format as a previous post mentioned. here
They also threatened to use them against OpenGL fragment shaders, though I don't know if they did anything official about it, and OpenGL has continued with fragment shaders uncahnged.
I'm suprised that there are these two examples. Microsoft has not been as clean as people think here. However they are nothing compared to a lot of compainies with patent portfolios.
Actually SCO's customers are quite safe from any FSF/Linus/GPL claims. They are not violating copyright, SCO is.
So long as they don't buy a 'SCO-Source license', at least, that's correct.
I think even if the customer buys an "SCO-Source License" they are safe from copyright violations to the Linux copyright holders, as they still have not copied anything they should not have, SCO is the one doing the copying (possibly SCO could put "you are liable for our copyright violations" in the license, but I'm not sure that is legal).
Some have argued that selling such a license would make SCO much more liable for copyright violations. This is probably true and this is why SCO has refused to actually make it possible to purchase such a license. However I still feel this in no way affects SCO's customers.
Older terminal keyboards only had one Ctrl key. For almost all manufacturers it was located where "CapsLock" is today. There was no right-hand key, so there was no symmetry problem.
This is correct. However part of the problem was incredibly stupid design when IBM made the AT keyboard.
The IBM-PC had only the keypad, exactly like you see it today, with arrows and home/end/pgup/down/ins/del printed on the keys. If NumLock was off you got arrows. If NumLock was on you got numbers. You could use shift+keypad to get the opposite of the NumLock setting (thus holding down shift gave you numbers even if numlock was off).
NumLock defaulted to off because in almost any real situation you wanted the arrow keys before the numbers.
At that time it was absolutely necessary to produce fake keystrokes that looked exactly like an IBM-PC keyboard, due to lots of bad software that read the keyboard port directly. So what IBM did was use a fancy new keyboard controller that produced *multiple* keycodes when any key was hit, and could look at the NumLock light setting. They then programmed it so the new arrow keys would produce the left-shift-down code if NumLock was on, then the keypad key, then the left-shift-up. This fooled all the software into recognizing it as an arrow even if that software was reading the keyboard directly.
Unfortunately they were unable to alter the system to turn NumLock off by default so they had to default to having both arrows work at the same time until the user hit NumLock.
You could easily show this with programs that reported all keystrokes.
Sounds clever but it was really stupid. What they *should* have done is make the arrows produce the same keystrokes as before, and made the numbers be the "new" keys and had them produce shift+arrow. They could have then eliminated the NumLock from the layout, and also the extra printing on the number keys. They would also work in the default num-lock-off state. Keyboard design would make a lot more sense if this was at all true.
I believe the keyboards also accepted a signal that made them switch to "non-back-compatability" mode where all keys produce a unique code, and I think all Windows and Linux systems set this.
Wrong. The laptop "numlock" is not the same key. Usually that key actually implements a low-level change in the hardware so that the "keycode" produced by the key is changed from the letter to the keypad key. This is done in order to fool programs that insist on retrieving the data at that low of a level. The "real" numlock is missing from these keyboards and forced "on", but if you fool it into turning the internal bit off, suddenly the "number" keys will produce arrow keystrokes.
Xlib compatability instantly ports *all* the toolkits in one step.
The toolkits can still be ported if there is interest in making them run faster and better on this new system. But that won't happen unless the new system becomes popular, and that won't happen unless everybody's programs already work.
This is absolutely necessary for a replacement for X to become popular and I fully agree with their decision to make Xlib compatability a goal.
Actually if their graphics interface is in any way not brain-dead, they should be able to emulate Xrender enough to run modern antialiased programs. I don't think they should list that as one of the unsupported things.
I can understand why XSHM and Xv are not supported, though. XSHM may have to be emulated (perhaps without speedup), as many X programs assumme it is there.
exec("mail", "name", "file", 0); (or something like that) will work.
Now it actually does not work on my machine because the mail command is broken (why isn't it as easy to set up as the mail in the browser?) but I would think that might be fixed in a successful Linux distribution.
Almost none run openssh, and even a smaller percentage would run it in the "monoculture". It is turned off by default.
However, despite that error, I do agree that successful Linux would probably lead to a monoculture. Even if there are dozens of vendors (most likely popular linux would be made by the computer manufactures themselves) there would be extreme pressure for compatability and thus a monoculture.
Several people have said that making it easy to run executables is necessary for Linux to be popular.
This is wrong: instead it must be easy to run executables in a *sandbox* where it cannot do anything other than perhaps draw in it's own windows.
This is not easy, but it is possible. Under Linux it would involve changing to nobody (requiring I think changes to the system so that it is legal for a program with any permissions to change to "nobody") and settings of local environment variables containing keys to things like the X server connection.
If the system is properly designed, the virus *goes away* when you reboot. This is not true of Windows virii, and is the big difference. Despite the fact that they can easily do it, few Windows virii destroy users data.
Now this certainly does not clear Linux, unless it is VERY carefully designed and it will require the painful decision to require passwords to by typed for various simple things the user wants to do. A virus that can change the programs automatically run when you log in is going to infect the computer in a way that (to the user) is just as bad as any Windows registry-writing virus.
The "average person" who wants to put MP3's on his portable player will get pissed off when the disk does not work, and will go to P2P and get the files directly, and then wonder why they spent money on that useless disk. If this happens enough times (my estimate is twice) they will stop buying any disks and only use P2P. Good work, RIAA, I'm sure you wanted that result!
The reason SGI is important is that one of the two pieces of "infringing" code that they showed in a slide show came from SGI (the other one was immediately discounted as not being infringement and nobody ever seems to mention that one anymore).
They probably had no idea where the code came from or did not think it was going to matter. But it was identified and if it really was an infringement it identified an actual guilty party (somebody at SGI). It seems they have to at least make a show of suing actual infringers and thus have been forced to sue SGI.
I can guarantee you that the response will be "MS must take it out". That is the ONLY legal thing that can happen (well Microsoft could GPL their code, but that would be Microsoft's choice and I doubt they would choose that solution).
Try learning a little about copyright and about the REAL complaints about SCO's actions before you make yourself look more like an idiot with demonstratably false statements like you just did.
But it should be pretty easy to filter out attempts to hide the text this way. Don't forget the filter has access to the actual codes in the mail, not the resulting image on the screen.
I seems very obvious that this is all Microsoft's planning and that they are paying SCO for this service.
However in some ways it seems a little too obvious. I'm wondering if instead SCO wants people to believe Microsoft is paying for this service. They may have duped (or had some co-conspirators in) Microsoft into purchasing that license and then spewed out press releases carefully designed to sound like Microsoft attacking Linux (especially the early ones that really tried to make Linux sound like crap, which would not be logical if you expected to sell Linux yourself).
The investors are not stupid and must think there is income somewhere. Maybe they are being convinced that Microsoft will continue to pay for this.
Why doesn't Microsoft refute it, then? Probably because nobody will believe them. It is also possible there are inside co-conspirators and they may have the embarassing position of having to fire somebody for wasting company money on a bogus license.
The GPL is not a "license", it is simply exceptions to the laws of copyright, allowing you to do more with the purchased IP than you normally can do. You are free to ignore it, thus it cannot be considered a "license". (if you ignore it you cannot redistribute the code at all, because that is illegal by US and international copyright laws).
Cars do come with rules that say you must not modify or reverse-engineer them. Some of those rules are from the government (pollution controls), some are from the company for liability requirements, and some are actual attempts to make competition illegal (diagnostics interfaces).
I'm pretty certain there are already lots of CD's released with a data track of Windows programs.
The fact that they targeted the PS2 rather than a Windows machine is pretty interesting, but it seems all the press release is about things that would be true for the Windows executable as well.
I agree. What is with this "limited time?", that is sure to greatly reduce the demand. It would be much simpler to just have the disk fill up so that people are forced to pick an old movie to throw away. Any plausable DRM system that would prevent these time-limited movies from being copied would also work for the non-time-limited ones.
Nobody is "making assumptions that SGI is not legally liable".
If SGI actually stole SCO's code, they certainly are legally liable. And I think virtually every one of the "slashbots" agrees they are legally liable.
The praise here is that SGI is showing directly how copyright infringement should be handled. The infringment must be mitigated first (ie the code must be removed). Then the infringing party can be sued!!!. The infringing party in this case is SGI, not RedHat or the end users of Linux, which is the crap claim being spouted by SCO. Even if SGI admitted copying 100,000 lines from SCO, this letter would be a good thing because it would finally show how things are supposed to work.
Why don't you read the posts rather than make knee-jerk predictions about what all the "slashbots" will say.
Then you won't look like an idiot.
(hint: I think 95% of the posts are on Microsoft's side!)
They used them to protect the ASF file format as a previous post mentioned.
here
They also threatened to use them against OpenGL fragment shaders, though I don't know if they did anything official about it, and OpenGL has continued with fragment shaders uncahnged.
I'm suprised that there are these two examples. Microsoft has not been as clean as people think here. However they are nothing compared to a lot of compainies with patent portfolios.
Maybe he wants to be able to turn off his computer without disabling printing for other computers.
So long as they don't buy a 'SCO-Source license', at least, that's correct.
I think even if the customer buys an "SCO-Source License" they are safe from copyright violations to the Linux copyright holders, as they still have not copied anything they should not have, SCO is the one doing the copying (possibly SCO could put "you are liable for our copyright violations" in the license, but I'm not sure that is legal).
Some have argued that selling such a license would make SCO much more liable for copyright violations. This is probably true and this is why SCO has refused to actually make it possible to purchase such a license. However I still feel this in no way affects SCO's customers.
Older terminal keyboards only had one Ctrl key. For almost all manufacturers it was located where "CapsLock" is today. There was no right-hand key, so there was no symmetry problem.
This is correct. However part of the problem was incredibly stupid design when IBM made the AT keyboard.
The IBM-PC had only the keypad, exactly like you see it today, with arrows and home/end/pgup/down/ins/del printed on the keys. If NumLock was off you got arrows. If NumLock was on you got numbers. You could use shift+keypad to get the opposite of the NumLock setting (thus holding down shift gave you numbers even if numlock was off).
NumLock defaulted to off because in almost any real situation you wanted the arrow keys before the numbers.
At that time it was absolutely necessary to produce fake keystrokes that looked exactly like an IBM-PC keyboard, due to lots of bad software that read the keyboard port directly. So what IBM did was use a fancy new keyboard controller that produced *multiple* keycodes when any key was hit, and could look at the NumLock light setting. They then programmed it so the new arrow keys would produce the left-shift-down code if NumLock was on, then the keypad key, then the left-shift-up. This fooled all the software into recognizing it as an arrow even if that software was reading the keyboard directly.
Unfortunately they were unable to alter the system to turn NumLock off by default so they had to default to having both arrows work at the same time until the user hit NumLock.
You could easily show this with programs that reported all keystrokes.
Sounds clever but it was really stupid. What they *should* have done is make the arrows produce the same keystrokes as before, and made the numbers be the "new" keys and had them produce shift+arrow. They could have then eliminated the NumLock from the layout, and also the extra printing on the number keys. They would also work in the default num-lock-off state. Keyboard design would make a lot more sense if this was at all true.
I believe the keyboards also accepted a signal that made them switch to "non-back-compatability" mode where all keys produce a unique code, and I think all Windows and Linux systems set this.
Wrong. The laptop "numlock" is not the same key. Usually that key actually implements a low-level change in the hardware so that the "keycode" produced by the key is changed from the letter to the keypad key. This is done in order to fool programs that insist on retrieving the data at that low of a level. The "real" numlock is missing from these keyboards and forced "on", but if you fool it into turning the internal bit off, suddenly the "number" keys will produce arrow keystrokes.
Actually SCO's customers are quite safe from any FSF/Linus/GPL claims. They are not violating copyright, SCO is.
Xlib compatability instantly ports *all* the toolkits in one step.
The toolkits can still be ported if there is interest in making them run faster and better on this new system. But that won't happen unless the new system becomes popular, and that won't happen unless everybody's programs already work.
This is absolutely necessary for a replacement for X to become popular and I fully agree with their decision to make Xlib compatability a goal.
Actually if their graphics interface is in any way not brain-dead, they should be able to emulate Xrender enough to run modern antialiased programs. I don't think they should list that as one of the unsupported things.
I can understand why XSHM and Xv are not supported, though. XSHM may have to be emulated (perhaps without speedup), as many X programs assumme it is there.
exec("mail", "name", "file", 0); (or something like that) will work.
Now it actually does not work on my machine because the mail command is broken (why isn't it as easy to set up as the mail in the browser?) but I would think that might be fixed in a successful Linux distribution.
Almost none run openssh, and even a smaller percentage would run it in the "monoculture". It is turned off by default.
However, despite that error, I do agree that successful Linux would probably lead to a monoculture. Even if there are dozens of vendors (most likely popular linux would be made by the computer manufactures themselves) there would be extreme pressure for compatability and thus a monoculture.
Several people have said that making it easy to run executables is necessary for Linux to be popular.
This is wrong: instead it must be easy to run executables in a *sandbox* where it cannot do anything other than perhaps draw in it's own windows.
This is not easy, but it is possible. Under Linux it would involve changing to nobody (requiring I think changes to the system so that it is legal for a program with any permissions to change to "nobody") and settings of local environment variables containing keys to things like the X server connection.
If the system is properly designed, the virus *goes away* when you reboot. This is not true of Windows virii, and is the big difference. Despite the fact that they can easily do it, few Windows virii destroy users data.
Now this certainly does not clear Linux, unless it is VERY carefully designed and it will require the painful decision to require passwords to by typed for various simple things the user wants to do. A virus that can change the programs automatically run when you log in is going to infect the computer in a way that (to the user) is just as bad as any Windows registry-writing virus.
He was talking about the installation of programs, not the OS itself: ...it is a complex PITA to install and run stuff on
They will make devices that are able to record to this format illegal.
The "average person" who wants to put MP3's on his portable player will get pissed off when the disk does not work, and will go to P2P and get the files directly, and then wonder why they spent money on that useless disk. If this happens enough times (my estimate is twice) they will stop buying any disks and only use P2P. Good work, RIAA, I'm sure you wanted that result!
The reason SGI is important is that one of the two pieces of "infringing" code that they showed in a slide show came from SGI (the other one was immediately discounted as not being infringement and nobody ever seems to mention that one anymore).
They probably had no idea where the code came from or did not think it was going to matter. But it was identified and if it really was an infringement it identified an actual guilty party (somebody at SGI). It seems they have to at least make a show of suing actual infringers and thus have been forced to sue SGI.
I can guarantee you that the response will be "MS must take it out". That is the ONLY legal thing that can happen (well Microsoft could GPL their code, but that would be Microsoft's choice and I doubt they would choose that solution).
Try learning a little about copyright and about the REAL complaints about SCO's actions before you make yourself look more like an idiot with demonstratably false statements like you just did.
But it should be pretty easy to filter out attempts to hide the text this way. Don't forget the filter has access to the actual codes in the mail, not the resulting image on the screen.
I seems very obvious that this is all Microsoft's planning and that they are paying SCO for this service.
However in some ways it seems a little too obvious. I'm wondering if instead SCO wants people to believe Microsoft is paying for this service. They may have duped (or had some co-conspirators in) Microsoft into purchasing that license and then spewed out press releases carefully designed to sound like Microsoft attacking Linux (especially the early ones that really tried to make Linux sound like crap, which would not be logical if you expected to sell Linux yourself).
The investors are not stupid and must think there is income somewhere. Maybe they are being convinced that Microsoft will continue to pay for this.
Why doesn't Microsoft refute it, then? Probably because nobody will believe them. It is also possible there are inside co-conspirators and they may have the embarassing position of having to fire somebody for wasting company money on a bogus license.
The GPL is not a "license", it is simply exceptions to the laws of copyright, allowing you to do more with the purchased IP than you normally can do. You are free to ignore it, thus it cannot be considered a "license". (if you ignore it you cannot redistribute the code at all, because that is illegal by US and international copyright laws).
Cars do come with rules that say you must not modify or reverse-engineer them. Some of those rules are from the government (pollution controls), some are from the company for liability requirements, and some are actual attempts to make competition illegal (diagnostics interfaces).
I'm pretty certain there are already lots of CD's released with a data track of Windows programs.
The fact that they targeted the PS2 rather than a Windows machine is pretty interesting, but it seems all the press release is about things that would be true for the Windows executable as well.
I agree. What is with this "limited time?", that is sure to greatly reduce the demand. It would be much simpler to just have the disk fill up so that people are forced to pick an old movie to throw away. Any plausable DRM system that would prevent these time-limited movies from being copied would also work for the non-time-limited ones.
Nobody is "making assumptions that SGI is not legally liable".
If SGI actually stole SCO's code, they certainly are legally liable. And I think virtually every one of the "slashbots" agrees they are legally liable.
The praise here is that SGI is showing directly how copyright infringement should be handled. The infringment must be mitigated first (ie the code must be removed). Then the infringing party can be sued!!!. The infringing party in this case is SGI, not RedHat or the end users of Linux, which is the crap claim being spouted by SCO. Even if SGI admitted copying 100,000 lines from SCO, this letter would be a good thing because it would finally show how things are supposed to work.