Re:SCO's case looks pretty strong
on
My Visit to SCO
·
· Score: 4, Insightful
IBM's aware of this. They have been ever since Phoenix Technologies broke the IBM monopoly on PC BIOSes way back when. They know exactly how to deal with it, and they've got lawyers who do nothing but make sure it's dealt with properly. I suspect that the work those programmers did was entirely new work not derived from SCO's work, which was then contributed to SCO's product. Any contamination there would be between IBM and Linux, not SCO and Linux. SCO might have a case against IBM if the contracts specifically said IBM would maintain confidentiality of the work, but I sincerely doubt IBM would have agreed to a contract that hamstrung them like that (and they wouldn't have contributed that code to Linux if they'd signed such a contract either).
If SCO's basing their case on the idea that they can extend rights upstream to code not derived from their code, IBM's going to hand them their heads on a platter.
The Forbes writer missed one thing: it isn't the Linux companies SCO and Canopy are suing, and against the company they are suing they're relatively small fish. IBM is the defendant named in their lawsuit. Remember the IBM-DOJ antitrust suit? The one that IBM fought to a standstill for 20 years? The one that IBM effectively won?
The Linux people may or may not be right, but IBM's saying SCO is blowing smoke and IBM has the legal department and the paper trail and audit trail procedures in place to be certain they know what they're talking about. And this suit is a direct threat to their core business, they aren't going to take it laying down nor pull any punches in dealing with it.
Playing devil's advocate, it might be fairly easy to make a case for mandatory free software in government. My argument for that would be that government, as a public entity, has special non-technical requirements. It's sufficiently important to insure that a) you know what's in that software, b) you can continue operating and accessing data for time periods literally an order of magnitude or more greater than the average software generation these days regardless of whether any single software vendor exists or supports the products you use, and c) your citizens aren't required to buy specific commercial products just to access government data and services, that those requirements trump any technical superiority of a proprietary solution.
This isn't about e-mail, it's about IP address blocks and how routes to networks are propagated through BGP from your routers through your NSP to the backbones.
Most of the big bandwidth providers don't just automatically accept any IP blocks you advertise. They want to know beforehand what blocks you'll be using. If you can't alter someone else's netblock registration to reflect your information, it makes it a lot harder to fake out the provider. Either you have to go to the trouble of forging all your documentation to look like the real owner or as soon as the provider you're trying to use checks the registration they'll see that the info for the owner of the block doesn't match what you've provided and a big red flag goes up. That stops the problem before it ever makes it into the routing table. Plus, all the provider has to do is also drop a line to the registered owner giving them all the hijacker's information and asking why the hijacker is trying to hijack those addresses and the hijacker is now in some very hot water.
Perhaps we ought to go to what we had with DNS domains back before Verisign privatized: you create a PGP public key and register it when you get your block, and from there on out any requests to change information about that block are only valid if they're signed with that key (or after some very stringent checks if you claim you've lost the key). That'd make it more difficult for hijackers to change the registration information.
Except that that's self-limiting on the programmer's side. Sooner or later there won't be any programmers who are a) stupid enough to go along and b) not yet in jail.
As a programmer you make sure you document what you promised and on what schedule. And you make sure you can deliver as promised. Then when sales starts promising more faster and gets nailed by this, you can produce the documentation showing that you were delivering on your promises. Then it'll come back on Sales for promising more than they were told would be delivered. And it'll probably be worse for them, because your documentation trail will show that they knew they were over-promising and courts tend to be harder on people who deliberately write checks they can't cash.
Simple: give them the chance to comply. If they won't voluntarily, they get a chance to explain it to a judge. They'd do the same to anyone who used their code in a product without permission (except they'd probably dkip the "give them a chance to comply" step). Sauce for the goose and all.
Complying should be simple. If they have an NDA preventing them from releasing the Broadcom drivers, they'll need to jump through the code hoops to be able to release those drivers as binary-only modules. If they can't release the drivers or their other modifications as legal binary-only modules and they can't (or won't) release them as source, then open-source was indeed a bad idea for them.
Companies need to get the message that open-source software, and GPL'd software, are the same as any other licensed software: you want to use it, you honor the license terms that let you use it. If those terms are incompatible with what you want to do, you either negotiate other terms with the creator or find other software. You don't go using it without a license and then expect the owner to sit back and let you profit from your violation of the law just because it would be inconvenient for you to not break the law.
Actually, the Vegas casinos don't cheat. They don't have to. Take roulette. They pay 35 to 1 on a winning spin. Now there's 38 numbers on an American wheel, 1-36 plus 0 and 00. That's 37 to 1 odds of winning a 35 to 1 payout. If the wheel's honest, the difference between those is 5.26%, which is the house's edge. If they don't cheat, they will get 5.26% of the money you play over the long run. This same thing applies to just about every other game on the floor, be it slots or blackjack or craps or whatnot.
It's only "just about", though. You can spot the exceptions by a simple question: who are you playing against? In craps and blackjack, for example, you're playing against the house. The house will win over the long run. In poker, OTOH, you're playing against the other players. The house just acts as bank and neutral dealer, and takes their cut from every pot. That's because in poker there's no house edge.
Sure, with computerized slots and such the casino could cheat, but why risk it? Nevada Gaming Control, believe it or not, is honest and all but incorruptible, and they've got enough experience that any cheating scheme a casino could use will be spotted pretty quick. The house gets their money, with honest games the nickel slots alone will pay the bills for the entire casino and everything else including the pit is pure profit. Why risk that gravy train for an extra fraction of a percent for maybe a year tops?
Frankly I don't much care about what they've got in a disclosure framework, as long as it meets at least a few requirements:
The problem must be disclosed to the vendor in a reasonable fashion (through the vendor's preferred method if they make such known) before any other action is taken. It's only fair to give the vendor a chance to fix the problem before making it public.
Disclosure, both to the vendor and the public, must include sufficient technical details to verify whether the exploit is actually valid and whether a specific machine is or is not vulnerable to it. This insures that frauds can't make up exploits, and that the vendor and the rest of us don't have to take anyone's word for whether the exploit works or not. Being able to demonstrate the exploit also helps get management's attention and buy-in on actually fixing it if the fix requires expenditures or downtime or other changes in the systems/network.
There are definite and not too long time limits for a vendor to either acknowledge a problem and provide either a fix, a workaround or acknowledgement that there is no fix or workaround and won't be for a while, or to provide an analysis of the proposed exploit and why it cannot work. 30 to 60 days would be reasonable for me. Vendors have proven willing to allow problems to go unfixed for too long, they'll have to prove they can be trusted to deal with problems in a timely manner before being allowed to delay disclosure indefinitely. Disclosure is the only lever we have to force them to address and fix problems. And remember that I'm vulnerable while the vendor works on the problem, I have a right to know I'm vulnerable and the option to take action to limit my vulnerability if the vendor can't come up with a fix.
Sorry, Charney, it's not the patch installation software that's the problem. Sure the changes you suggest will make things a lot easier, but their absence isn't why people don't install your patches. The problem is the patches themselves.
Yes, the patches themselves. People don't install them because they break critical production software which must not be broken. And in some cases those patches can't be backed out without a complete wipe and reinstall of the system, witness the recent VPN protocol "fix". As long as this is the case, people will still not install the patches no matter how easy the installation process is.
If MS wants to improve their patch process, they need to do a few things:
Insure that security and critical updates don't break existing software. At the very least, if breakage is neccesary the type and extent must be documented in the patch description.
All security-related patches must be seperate from functionality upgrades. You can roll security fixes into service packs and upgrade packages, but you must never require the latter to get the former.
All patches must be uninstallable. No exceptions. Not even for security patches. Admins must be confident that any patch can be undone if it absolutely has to be.
Patches must not change license terms. One of the reasons people avoid patches is that they change the license terms to ones they can't accept. No using security fixes as blackmail to foist terms on users that the users wouldn't agree to on their own.
Because the whole point of Google's search results is that they're not affected by advertising. That's why they're useful to Google's users. Yes, Google does ads. Notice that they're clearly and completely seperate from the search results. And what better ranking than "most relevant to query" would you suggest?
If Google discovers there's an error in their system, why should they be under any obligation to delay correcting it? And if someone's abusing their system, why should they be under any obligation to tell the abuser and allow the abuse to continue uncorrected?
I have been involved in some of these things, and I will say that SCO's claims that developers who worked on the SCO project with IBM then later moved on to work on Linux will be dangerous in a court of law. It is very common to claim that knowledge obtained in the first case will inevetably leak into the second project, and courts can and do believe it.
True, but remember IBM v. Phoenix Technologies. IBM was on the other side of this exact issue there, and got burned when Phoenix proved in court that the knowledge couldn't have been leaked. You can bet IBM learned from that and put procedures in place to insure they can prove, as Phoenix did, that NDA'd information didn't leak.
Whatever happens, it wouldn't validate the "viral GPL" theory. That theory is about the GPL "infecting" code not released under the GPL. In this case, if SCO released their IP as part of the kernel in a Linux distribution, they would have released it under the Linux kernel license (which is close enough to the GPL for practical purposes here). They may not have intended to, they may not have wanted to, but they would have. This would be exactly the same as unintentionally releasing a Windows product containing the Microsoft redistributable libraries.
Thing is, I'm not interfering with the spammer's free speech at all. They're still free to say whatever they want. What I'm doing by using a spamblock is the equivalent of declining to go listen to their speech. What the spammers are yelling about isn't that people are trying to stifle their speech via spamblocks, but that when they do speak it's to an empty hall because nobody wants to hear what the spammers want to talk about.
I'm sorry, but the right to free speech doesn't include the right to require me to listen.
I'll have to agree. The RIAA, the labels and lots of the artists want hard enforcement of copyright law (and then some) when it comes to us copying their work. Why shouldn't they be subject to the same rules when it comes to them copying someone else's work? If they want to make fair use of stuff without running afoul of copyright infringement prosecution, then they should press for protection of fair use.
The only problem here is that what made e-mail so popular and useful is the same thing that caused spam to come into existence: it doesn't cost anything (once you've got an Internet connection) to send e-mail to people. Think about all the services, like the RISKS mailing list, that are run for free by volunteers and provide valuable services. Do you think those people are going to continue providing that service if it's costing them thousands of dollars a year (eg. RISKS = $.01/message x 20,000 subscribers x 80 messages a year = $16,000/year conservatively to run the list)? No, any proposal to attach costs to e-mail has to meet one precondition: if I desire a particular person to send me e-mail, it must not cost that person anything to send me e-mail.
Actually it's the hijacking of a non-consenting third party's computer that's the illegal part. How they got into it and what they did with it can increase the sentence, but it's the breaking-in part that's criminal.
As I understand the LGPL, there are two situations:
You modify code in the LGPL'd library. You have to release the modified source code, but do not automatically have to release your application's code.
You physically include code from the LGPL'd library in your program's executable (modulo minor code in header files), rather than just linking to the seperate libraries. As a consequence you must release your application under the LGPL.
Assuming you use public-key cryptography, a DRM-enabled kernel with a public master key would still function for, as someone else noted, the stated purpose of Palladium/TCPA/etc.. You don't need to conceal the master key to securely verify signatures. It would, however, make non-user-controlled DRM (eg. DVD-CSS, the RIAA's dream of use control, etc.) impossible since those depend on the user not being able to find the master key.
Re:what ?
on
Linus on DRM
·
· Score: 4, Interesting
I think he's talking about a situation such as DVD-CSS, where content is encrypted with a product key and the product key is protected by being encrypted with a master key which is embedded in the OS itself. Then only the OS can obtain the product keys needed to decrypt the contents, and the OS can enforce any access controls it wants on the content because the user can't get at the content except by going through the OS. What he's saying is that doing that is perfectly OK under the Linux license, as long as you release the master key, in the clear, as part of the OS source just as the license requires.
Yes, that does make the master key useless for it's intended purpose.:)
Slashdot Mirror
IBM's aware of this. They have been ever since Phoenix Technologies broke the IBM monopoly on PC BIOSes way back when. They know exactly how to deal with it, and they've got lawyers who do nothing but make sure it's dealt with properly. I suspect that the work those programmers did was entirely new work not derived from SCO's work, which was then contributed to SCO's product. Any contamination there would be between IBM and Linux, not SCO and Linux. SCO might have a case against IBM if the contracts specifically said IBM would maintain confidentiality of the work, but I sincerely doubt IBM would have agreed to a contract that hamstrung them like that (and they wouldn't have contributed that code to Linux if they'd signed such a contract either).
If SCO's basing their case on the idea that they can extend rights upstream to code not derived from their code, IBM's going to hand them their heads on a platter.
The Forbes writer missed one thing: it isn't the Linux companies SCO and Canopy are suing, and against the company they are suing they're relatively small fish. IBM is the defendant named in their lawsuit. Remember the IBM-DOJ antitrust suit? The one that IBM fought to a standstill for 20 years? The one that IBM effectively won?
The Linux people may or may not be right, but IBM's saying SCO is blowing smoke and IBM has the legal department and the paper trail and audit trail procedures in place to be certain they know what they're talking about. And this suit is a direct threat to their core business, they aren't going to take it laying down nor pull any punches in dealing with it.
Playing devil's advocate, it might be fairly easy to make a case for mandatory free software in government. My argument for that would be that government, as a public entity, has special non-technical requirements. It's sufficiently important to insure that a) you know what's in that software, b) you can continue operating and accessing data for time periods literally an order of magnitude or more greater than the average software generation these days regardless of whether any single software vendor exists or supports the products you use, and c) your citizens aren't required to buy specific commercial products just to access government data and services, that those requirements trump any technical superiority of a proprietary solution.
This isn't about e-mail, it's about IP address blocks and how routes to networks are propagated through BGP from your routers through your NSP to the backbones.
Most of the big bandwidth providers don't just automatically accept any IP blocks you advertise. They want to know beforehand what blocks you'll be using. If you can't alter someone else's netblock registration to reflect your information, it makes it a lot harder to fake out the provider. Either you have to go to the trouble of forging all your documentation to look like the real owner or as soon as the provider you're trying to use checks the registration they'll see that the info for the owner of the block doesn't match what you've provided and a big red flag goes up. That stops the problem before it ever makes it into the routing table. Plus, all the provider has to do is also drop a line to the registered owner giving them all the hijacker's information and asking why the hijacker is trying to hijack those addresses and the hijacker is now in some very hot water.
Perhaps we ought to go to what we had with DNS domains back before Verisign privatized: you create a PGP public key and register it when you get your block, and from there on out any requests to change information about that block are only valid if they're signed with that key (or after some very stringent checks if you claim you've lost the key). That'd make it more difficult for hijackers to change the registration information.
Except that that's self-limiting on the programmer's side. Sooner or later there won't be any programmers who are a) stupid enough to go along and b) not yet in jail.
As a programmer you make sure you document what you promised and on what schedule. And you make sure you can deliver as promised. Then when sales starts promising more faster and gets nailed by this, you can produce the documentation showing that you were delivering on your promises. Then it'll come back on Sales for promising more than they were told would be delivered. And it'll probably be worse for them, because your documentation trail will show that they knew they were over-promising and courts tend to be harder on people who deliberately write checks they can't cash.
Simple: give them the chance to comply. If they won't voluntarily, they get a chance to explain it to a judge. They'd do the same to anyone who used their code in a product without permission (except they'd probably dkip the "give them a chance to comply" step). Sauce for the goose and all.
Complying should be simple. If they have an NDA preventing them from releasing the Broadcom drivers, they'll need to jump through the code hoops to be able to release those drivers as binary-only modules. If they can't release the drivers or their other modifications as legal binary-only modules and they can't (or won't) release them as source, then open-source was indeed a bad idea for them.
Companies need to get the message that open-source software, and GPL'd software, are the same as any other licensed software: you want to use it, you honor the license terms that let you use it. If those terms are incompatible with what you want to do, you either negotiate other terms with the creator or find other software. You don't go using it without a license and then expect the owner to sit back and let you profit from your violation of the law just because it would be inconvenient for you to not break the law.
Actually, the Vegas casinos don't cheat. They don't have to. Take roulette. They pay 35 to 1 on a winning spin. Now there's 38 numbers on an American wheel, 1-36 plus 0 and 00. That's 37 to 1 odds of winning a 35 to 1 payout. If the wheel's honest, the difference between those is 5.26%, which is the house's edge. If they don't cheat, they will get 5.26% of the money you play over the long run. This same thing applies to just about every other game on the floor, be it slots or blackjack or craps or whatnot.
It's only "just about", though. You can spot the exceptions by a simple question: who are you playing against? In craps and blackjack, for example, you're playing against the house. The house will win over the long run. In poker, OTOH, you're playing against the other players. The house just acts as bank and neutral dealer, and takes their cut from every pot. That's because in poker there's no house edge.
Sure, with computerized slots and such the casino could cheat, but why risk it? Nevada Gaming Control, believe it or not, is honest and all but incorruptible, and they've got enough experience that any cheating scheme a casino could use will be spotted pretty quick. The house gets their money, with honest games the nickel slots alone will pay the bills for the entire casino and everything else including the pit is pure profit. Why risk that gravy train for an extra fraction of a percent for maybe a year tops?
Frankly I don't much care about what they've got in a disclosure framework, as long as it meets at least a few requirements:
Sorry, Charney, it's not the patch installation software that's the problem. Sure the changes you suggest will make things a lot easier, but their absence isn't why people don't install your patches. The problem is the patches themselves.
Yes, the patches themselves. People don't install them because they break critical production software which must not be broken. And in some cases those patches can't be backed out without a complete wipe and reinstall of the system, witness the recent VPN protocol "fix". As long as this is the case, people will still not install the patches no matter how easy the installation process is.
If MS wants to improve their patch process, they need to do a few things:
Because the whole point of Google's search results is that they're not affected by advertising. That's why they're useful to Google's users. Yes, Google does ads. Notice that they're clearly and completely seperate from the search results. And what better ranking than "most relevant to query" would you suggest?
If Google discovers there's an error in their system, why should they be under any obligation to delay correcting it? And if someone's abusing their system, why should they be under any obligation to tell the abuser and allow the abuse to continue uncorrected?
I have been involved in some of these things, and I will say that SCO's claims that developers who worked on the SCO project with IBM then later moved on to work on Linux will be dangerous in a court of law. It is very common to claim that knowledge obtained in the first case will inevetably leak into the second project, and courts can and do believe it.
True, but remember IBM v. Phoenix Technologies. IBM was on the other side of this exact issue there, and got burned when Phoenix proved in court that the knowledge couldn't have been leaked. You can bet IBM learned from that and put procedures in place to insure they can prove, as Phoenix did, that NDA'd information didn't leak.
Whatever happens, it wouldn't validate the "viral GPL" theory. That theory is about the GPL "infecting" code not released under the GPL. In this case, if SCO released their IP as part of the kernel in a Linux distribution, they would have released it under the Linux kernel license (which is close enough to the GPL for practical purposes here). They may not have intended to, they may not have wanted to, but they would have. This would be exactly the same as unintentionally releasing a Windows product containing the Microsoft redistributable libraries.
A blacklist doesn't ban spam. The spammers can still send all the spam they like, to anyone they like.
Now it is an organized refusal to listen, but again nowhere does the right to free speech say anything about a guarantee of an audience.
Thing is, I'm not interfering with the spammer's free speech at all. They're still free to say whatever they want. What I'm doing by using a spamblock is the equivalent of declining to go listen to their speech. What the spammers are yelling about isn't that people are trying to stifle their speech via spamblocks, but that when they do speak it's to an empty hall because nobody wants to hear what the spammers want to talk about.
I'm sorry, but the right to free speech doesn't include the right to require me to listen.
I'll have to agree. The RIAA, the labels and lots of the artists want hard enforcement of copyright law (and then some) when it comes to us copying their work. Why shouldn't they be subject to the same rules when it comes to them copying someone else's work? If they want to make fair use of stuff without running afoul of copyright infringement prosecution, then they should press for protection of fair use.
The only problem here is that what made e-mail so popular and useful is the same thing that caused spam to come into existence: it doesn't cost anything (once you've got an Internet connection) to send e-mail to people. Think about all the services, like the RISKS mailing list, that are run for free by volunteers and provide valuable services. Do you think those people are going to continue providing that service if it's costing them thousands of dollars a year (eg. RISKS = $.01/message x 20,000 subscribers x 80 messages a year = $16,000/year conservatively to run the list)? No, any proposal to attach costs to e-mail has to meet one precondition: if I desire a particular person to send me e-mail, it must not cost that person anything to send me e-mail.
I think text-only ads as Google, for example, implements them won't die. Why?
- They're fast and non-intrusive.
- They're relevant to what the user's looking for when they're presented.
Users like these things. They'll continue to click through such ads even as they ignore unrelated banner ads, pop-ups and such.Actually it's the hijacking of a non-consenting third party's computer that's the illegal part. How they got into it and what they did with it can increase the sentence, but it's the breaking-in part that's criminal.
As I understand the LGPL, there are two situations:
Assuming you use public-key cryptography, a DRM-enabled kernel with a public master key would still function for, as someone else noted, the stated purpose of Palladium/TCPA/etc.. You don't need to conceal the master key to securely verify signatures. It would, however, make non-user-controlled DRM (eg. DVD-CSS, the RIAA's dream of use control, etc.) impossible since those depend on the user not being able to find the master key.
I think he's talking about a situation such as DVD-CSS, where content is encrypted with a product key and the product key is protected by being encrypted with a master key which is embedded in the OS itself. Then only the OS can obtain the product keys needed to decrypt the contents, and the OS can enforce any access controls it wants on the content because the user can't get at the content except by going through the OS. What he's saying is that doing that is perfectly OK under the Linux license, as long as you release the master key, in the clear, as part of the OS source just as the license requires.
Yes, that does make the master key useless for it's intended purpose. :)