What Forgent's doing has little to do with due process, and much to do with ambush and highway robbery. I'd say conditions like these are appropriate:
If a technology was outlined in an openly-published standard at the time the patent was granted, the patent is unenforceable against implementations of the standard.
If the technology has been described in an openly-published and implemented standard, and that standard has been in use for at least 2 years without objections or other action by the patent-holder against the standard or the implementations, the patent is unenforceable against implementations of that standard.
That would scuttle claims like Forgent's without harming people who held patents before a standard was published and who raised objections promptly.
That's already there. The law on patents is that if you don't act to enforce the patent for a sufficient period of time, the patent becomes unenforceable. The problem is, you still have to let the patent-holder take you to court and have the judge rule that the patent hasn't been enforced and is unenforceable. What we need is a way to short-circuit that, a set of conditions that a user of a technology can satisfy that guarantee no case can be brought against them.
Re:You're right, someone IS buying.
on
Spam Doesn't Work?
·
· Score: 2, Insightful
The only way to get the point across to the execs will come too late, when your co-lo provider shuts you down and your Web site's off the air because of the spam complaints or when your legitimate e-mails to legitimate customers and business contacts start to bounce because you've been flagged as a spammer. What nobody's figured out is how to get this cost across to the execs in a dollars-and-cents way they understand.
No, but then what do you expect when you hand unneccesary stuff on it? The correct form is simply rpm --query xemacs --list and you get the listing of what files are in the xemacs package. If you need to find a package, a standard rpm -q -a | grep -i emacs ("list all packages, select those with "emacs" in the name regardless of case") will give you the names of all packages related to emacs. The tail end of the full package name is version and release information, useful for figuring out if the "update" really is newer than what you've got installed but not important for naming the package.
Seems to me that #1 would be a big argument against RAND licensing. If the patented technology is essential to implementing a standard, once it's in isn't that a big temptation to a company looking for more revenue to jack up the licensing terms across the board? After all, everyone else can't simply drop support for the standard. This sounds like something a standards body should not be leaving open.
If you use the -v option when installing the software, it'll list out the package names as it installs them (though they should be obvious from the binary package file names).
That depends. Your whole service doesn't go down, but every single day for an hour or so someone's in the server room fixing something. If you let it go, Murphy will take over and the backup for whatever was down will go down too, taking down the whole service.
And even if it doesn't, there's still a cost in maintaining the systems that break. At my last job NCR figured their machines were good for a year before any hardware broke, even if the boxes were completely ignored and not maintained. They couldn't understand why we were shipping 4-5 boxes a week back with hardware failures and had one full-time person who did nothing but spin up and ship replacement boxes. Well, with 250+ boxes that's about 1.5 days per hardware failure, what did they expect?
Remember that downtime is related not only to reliability of each piece of equipment but the number of pieces of equipment. 99.99% uptime sounds good, less than an hour of downtime a year, right? Scale that to a 500-server farm and it's an hour and ten minutes or so of downtime a day, every single day of the year including weekends and holidays (OK, we'll give you one day off in leap years). This concept has boggled a few salescritters who don't grasp the concept of scale.
Not quite. The label doesn't get paid back out of the proceeds, they get paid back out of the artist's share of the proceeds. Say the artist is getting a 5% royalty, was fronted $20,000 to make the album and each copy sells for $15. Assume a 25% retail mark-up, ie. the label gets $11.25 per copy. Break-even is just short of 1800 copies. But the artist won't start getting a royalty at the 1800-copy point. They won't start getting a royalty until 26,667 copies have been sold, at which point their 5% has paid off the $20K advance. In between those sales points, the label is making a profit but the artist doesn't see a penny from it. The only way the label loses money is if the album doesn't even sell the 1800 copies needed to break even.
Any signed musicians out there, feel free to plug in actual advances and royalty rates. Yes, I've omitted any promotional costs the label might incur, but those come out of the artist's royalties too as I understand it.
If MS does shove Palladium in as part of a security update/bugfix, I wonder what the legal status of the agreement you give would be? It would seem coerced, much like if your car got a recall notice due to a brake failure that rendered it unsafe unless repairs were done, and they had to be done by the dealer, and the dealer required you to agree to, say, installing a system so he could control where and when you drove your car as a condition of getting the repairs done. Generally the law doesn't require you to adhere to an agreement you were coerced into, and I think you could make a good case for this being coercion.
I can't reach the guy's site so I don't know if he's added custom drivers, but Dalls Semiconductor has Linux development kits and source code for their 1-Wire stuff here.
So we should expect people to be able to sit down in a car and drive the very first time, with no instruction or anything? I don't think so. And driving a car is, relatively speaking, much simpler than most of the things people expect out of a computer. As for phone numbers, the idea of "I punch the buttons in a sequence and it connects me to someone" is easy, but the concepts of area codes, when they're needed, various dialing prefixes (direct-dial, international country codes, etc.) ain't exactly intuitive either. But by and large people find it easy enough, because they've looked in the book for how to do it and they use it every day.
It shouldn't require excessive amounts of brains to get something to do basic things, but if the user isn't willing to learn what they're doing we should no more accomodate them than we accomodate people who want to drive a car without learning how to drive.
It's not saying the link was paid for when it was that's fraud. That's what some search engines do, you type in a search and they return results based not purely on how well they match your search but biased based on how much someone paid the search engine. What the FTC's warning the engine operators about isn't that doing that is against the rules, but that doing that while trying to lead the consumer to believe they aren't is fraud.
And the FTC already does this for everything else. All they're doing is putting the search engines on notice that they have to follow the same rules as everyone else: sell what you want how you want, but you'd better say honestly what you're selling and what the terms are. If a business has a problem with that, I don't want to do business with them anyway.
Palladium and it's supporters seem to make the assumption that users don't trust the net for commerce because they don't trust the identity of the entity they're doing business with, and that giving them trust in that identity will solve the problem. I think that's a wrong assumption. I think people do trust they know who they're dealing with, and they don't trust the entities they're being asked to do business with. For good reasons, apparently, given the penchant for companies to disclaim all responsibility for broken products/services and to sell all manner of information about their customers to everyone else under the sun without concern for the consequences to the people whose information they sold. That can't be solved by just a better way of verifying identity.
As for the verified-software part, that'll last right up until the Executive Vice-President for Sales of the company can't install the latest and greatest screensaver his friend the vendor rep sent him because it's not authorized software. Then IT will be ordered to knock holes in the system for him and the whole thing will become pointless.
Then there's the whole digital-rights part of it, but that's another argument for another forum.
Actually, I know what's wrong. Theo's notice was basically "There's a hole, wait until we release a new version and then do a major version upgrade in a hurry.". ISS's notice was "Here's the hole, here's the way to close it in your existing software.". I'd rather Theo have told everybody the simple way to close the hole right off, rather than leaving everyone hanging.
Myself, I wouldn't like it. But the company should like it even less. Think about something here: what's your company's policy on employees giving out the keys to restricted areas? It's probably a termination offense. Now, suppose the company uses biometric data to control access to restricted areas. Isn't giving out that data exactly giving out the keys to those restricted areas?
And if that biometric data is also required by law to be used for things like controlling access to bank accounts, where there's legal penalties for third parties who mishandle the access-control information, the company could face some nasty legal LARTs from employees if the company gives out access-control information for their bank accounts, Social Security accounts, driver's license records and such.
This should give the company legal people migraines for a while.:)
Why, somehow, does this strike me as similar to an author having published an utterly bad, horribly stinky book that, later in life, he regrets ever having let see the printing press, and complaining that some people won't turn in their copies to him to destroy now that he wants to unpublish it? Remember that copyright isn't an unlimited right to prevent copies. IMHO most of these archival sites fall into the same category as a library that bought a newspaper, scanned it onto microfilm and then subsequently had the original newspapers destroyed in a flood: they had legitimate access to the originals, the copies were legitimate fair-use copies when made, the originals haven't been transferred to anyone else, the copies remain legitimate fair-use copies.
It may be embarrassing to the creators to have copies of their sites preserved for posterity, but copyright isn't about preventing an author from being embarrassed.
Baen's Webscriptions would contradict that. It costs about $3.75 per book delivered in electronic form through it (or more, the terms are $15/month, typically 4 books per month). It's popular enough to be making Jim Baen money on the deal. It's making the authors money in royalties. And from the letters Eric's gotten people are not only paying for the electronic versions, they're then going on to buy the paper versions too.
Note that Webscriptions meets the criteria I gave:
It offers complete books. Delivery may be over time but books don't get offered until the manuscript is in hand and it's on the way to either hardcover or paperback publication, and Baen guarantees delivery of all books ordered even if they shut down the service.
All versions are in open formats, freely copyable. No copy-protection hassles.
They're priced less than the paperback editions, but still high enough to be profitable.
I think this fails for one reason: The average internet user isn't willing to pay a meaningful amount for content.
Flint disproves this with hard numbers from royalty statements on his Prime Palaver over on the Baen Free Library. People are paying enough for the electronic forms of his books to earn him somewhat over $2K a year in royalties from the electronic versions. If people aren't willing to pay, where's those dollars in Eric's checking account coming from?
I don't know, Eric Flint and David Drake seem to be making decent money in royalties off electronic forms of their older books. Not great money, maybe 2 grand a year, but then these are older backlist titles that normally only sell 5-600 copies a year so royalties aren't that great for the paper forms either. And the copy-protected electronic forms of Drake's books barely make enough in royalties every year to pay for a decent pizza. I think it boils down to:
People won't pay per chapter for serialized works, they'd rather get it all at once.
People won't pay to deal with copy-protection hassles, but they will pay to have it readily available electronically.
People won't pay as much for the electronic form as for paper.
I think authors can live with this. See Eric Flint's essays over on the Baen Free Library.
I think this and prior attempts don't show that publishing on the Web doesn't work so much as they show that publishing books in serialized installments doesn't work.
Wouldn't section 7 cover it? If people who receive SELinux directly from SCC could not modify and redistribute the code without paying patent royalties on SCC's stuff, then SCC's stuff would violate the GPL and they lose the right to redistribute a work based on the GPL'd Linux code, no?
Except that if ICANN, who control the root servers, don't change the delegation for.za in the root zone files, nobody in the world will use the SA gov't's nameservers.
So set up Gnome or KDE on the workstations, no admin privileges to any user accounts of course, with the home directories Coda-mounted and with things locked down per standard for an ISP's shell machines (ie. tighter than a nervous virgin clam). Minimal services running, don't install dangerous things like nmap, and give them a desktop skin that resembles Windows and an xdm/gdm/kdm login box. You only have to assemble the workstation image once, then just clone it over onto workstations as needed. Kernel modules and DHCP are your friend here.
For extra evilness points, lock down their dot-files by making them owned by a special user and not writable by the account itself. This requires a bit of a balancing act, since some dot-files do need to be writable for storing state.
This is the same process needed to secure the workstations used by the CS classes, you're just talking about several thousand workstations instead of several hundred. There's more administrative overhead, but the actual things needed for each workstation are roughly the same. Just be sure to have a beefy enough fileserver (or spread the load over several) to handle the network-mounted home directories.
No conspiracy theory, just Marketing making the technical decisions. Releasing even a simple "disable Gopher protocol" patch would cost some money and be a PR hit. Ignoring the problem doesn't cost anything nor give any PR hit as long as the general public doesn't know about the hole. Any marketroid knows that means you don't fix the hole.
That's also why the spokesman was so upset, not at the hole itself, but at it's revelation: they now have to do the technically correct thing instead of the marketing correct thing.
Slashdot Mirror
What Forgent's doing has little to do with due process, and much to do with ambush and highway robbery. I'd say conditions like these are appropriate:
- If a technology was outlined in an openly-published standard at the time the patent was granted, the patent is unenforceable against implementations of the standard.
- If the technology has been described in an openly-published and implemented standard, and that standard has been in use for at least 2 years without objections or other action by the patent-holder against the standard or the implementations, the patent is unenforceable against implementations of that standard.
That would scuttle claims like Forgent's without harming people who held patents before a standard was published and who raised objections promptly.That's already there. The law on patents is that if you don't act to enforce the patent for a sufficient period of time, the patent becomes unenforceable. The problem is, you still have to let the patent-holder take you to court and have the judge rule that the patent hasn't been enforced and is unenforceable. What we need is a way to short-circuit that, a set of conditions that a user of a technology can satisfy that guarantee no case can be brought against them.
The only way to get the point across to the execs will come too late, when your co-lo provider shuts you down and your Web site's off the air because of the spam complaints or when your legitimate e-mails to legitimate customers and business contacts start to bounce because you've been flagged as a spammer. What nobody's figured out is how to get this cost across to the execs in a dollars-and-cents way they understand.
No, but then what do you expect when you hand unneccesary stuff on it? The correct form is simply rpm --query xemacs --list and you get the listing of what files are in the xemacs package. If you need to find a package, a standard rpm -q -a | grep -i emacs ("list all packages, select those with "emacs" in the name regardless of case") will give you the names of all packages related to emacs. The tail end of the full package name is version and release information, useful for figuring out if the "update" really is newer than what you've got installed but not important for naming the package.
Seems to me that #1 would be a big argument against RAND licensing. If the patented technology is essential to implementing a standard, once it's in isn't that a big temptation to a company looking for more revenue to jack up the licensing terms across the board? After all, everyone else can't simply drop support for the standard. This sounds like something a standards body should not be leaving open.
rpm --query <package-name> --list
If you use the -v option when installing the software, it'll list out the package names as it installs them (though they should be obvious from the binary package file names).
That depends. Your whole service doesn't go down, but every single day for an hour or so someone's in the server room fixing something. If you let it go, Murphy will take over and the backup for whatever was down will go down too, taking down the whole service.
And even if it doesn't, there's still a cost in maintaining the systems that break. At my last job NCR figured their machines were good for a year before any hardware broke, even if the boxes were completely ignored and not maintained. They couldn't understand why we were shipping 4-5 boxes a week back with hardware failures and had one full-time person who did nothing but spin up and ship replacement boxes. Well, with 250+ boxes that's about 1.5 days per hardware failure, what did they expect?
Remember that downtime is related not only to reliability of each piece of equipment but the number of pieces of equipment. 99.99% uptime sounds good, less than an hour of downtime a year, right? Scale that to a 500-server farm and it's an hour and ten minutes or so of downtime a day, every single day of the year including weekends and holidays (OK, we'll give you one day off in leap years). This concept has boggled a few salescritters who don't grasp the concept of scale.
Not quite. The label doesn't get paid back out of the proceeds, they get paid back out of the artist's share of the proceeds. Say the artist is getting a 5% royalty, was fronted $20,000 to make the album and each copy sells for $15. Assume a 25% retail mark-up, ie. the label gets $11.25 per copy. Break-even is just short of 1800 copies. But the artist won't start getting a royalty at the 1800-copy point. They won't start getting a royalty until 26,667 copies have been sold, at which point their 5% has paid off the $20K advance. In between those sales points, the label is making a profit but the artist doesn't see a penny from it. The only way the label loses money is if the album doesn't even sell the 1800 copies needed to break even.
Any signed musicians out there, feel free to plug in actual advances and royalty rates. Yes, I've omitted any promotional costs the label might incur, but those come out of the artist's royalties too as I understand it.
If MS does shove Palladium in as part of a security update/bugfix, I wonder what the legal status of the agreement you give would be? It would seem coerced, much like if your car got a recall notice due to a brake failure that rendered it unsafe unless repairs were done, and they had to be done by the dealer, and the dealer required you to agree to, say, installing a system so he could control where and when you drove your car as a condition of getting the repairs done. Generally the law doesn't require you to adhere to an agreement you were coerced into, and I think you could make a good case for this being coercion.
I can't reach the guy's site so I don't know if he's added custom drivers, but Dalls Semiconductor has Linux development kits and source code for their 1-Wire stuff here.
So we should expect people to be able to sit down in a car and drive the very first time, with no instruction or anything? I don't think so. And driving a car is, relatively speaking, much simpler than most of the things people expect out of a computer. As for phone numbers, the idea of "I punch the buttons in a sequence and it connects me to someone" is easy, but the concepts of area codes, when they're needed, various dialing prefixes (direct-dial, international country codes, etc.) ain't exactly intuitive either. But by and large people find it easy enough, because they've looked in the book for how to do it and they use it every day.
It shouldn't require excessive amounts of brains to get something to do basic things, but if the user isn't willing to learn what they're doing we should no more accomodate them than we accomodate people who want to drive a car without learning how to drive.
It's not saying the link was paid for when it was that's fraud. That's what some search engines do, you type in a search and they return results based not purely on how well they match your search but biased based on how much someone paid the search engine. What the FTC's warning the engine operators about isn't that doing that is against the rules, but that doing that while trying to lead the consumer to believe they aren't is fraud.
And the FTC already does this for everything else. All they're doing is putting the search engines on notice that they have to follow the same rules as everyone else: sell what you want how you want, but you'd better say honestly what you're selling and what the terms are. If a business has a problem with that, I don't want to do business with them anyway.
Palladium and it's supporters seem to make the assumption that users don't trust the net for commerce because they don't trust the identity of the entity they're doing business with, and that giving them trust in that identity will solve the problem. I think that's a wrong assumption. I think people do trust they know who they're dealing with, and they don't trust the entities they're being asked to do business with. For good reasons, apparently, given the penchant for companies to disclaim all responsibility for broken products/services and to sell all manner of information about their customers to everyone else under the sun without concern for the consequences to the people whose information they sold. That can't be solved by just a better way of verifying identity.
As for the verified-software part, that'll last right up until the Executive Vice-President for Sales of the company can't install the latest and greatest screensaver his friend the vendor rep sent him because it's not authorized software. Then IT will be ordered to knock holes in the system for him and the whole thing will become pointless.
Then there's the whole digital-rights part of it, but that's another argument for another forum.
Actually, I know what's wrong. Theo's notice was basically "There's a hole, wait until we release a new version and then do a major version upgrade in a hurry.". ISS's notice was "Here's the hole, here's the way to close it in your existing software.". I'd rather Theo have told everybody the simple way to close the hole right off, rather than leaving everyone hanging.
Myself, I wouldn't like it. But the company should like it even less. Think about something here: what's your company's policy on employees giving out the keys to restricted areas? It's probably a termination offense. Now, suppose the company uses biometric data to control access to restricted areas. Isn't giving out that data exactly giving out the keys to those restricted areas?
And if that biometric data is also required by law to be used for things like controlling access to bank accounts, where there's legal penalties for third parties who mishandle the access-control information, the company could face some nasty legal LARTs from employees if the company gives out access-control information for their bank accounts, Social Security accounts, driver's license records and such.
This should give the company legal people migraines for a while. :)
Why, somehow, does this strike me as similar to an author having published an utterly bad, horribly stinky book that, later in life, he regrets ever having let see the printing press, and complaining that some people won't turn in their copies to him to destroy now that he wants to unpublish it? Remember that copyright isn't an unlimited right to prevent copies. IMHO most of these archival sites fall into the same category as a library that bought a newspaper, scanned it onto microfilm and then subsequently had the original newspapers destroyed in a flood: they had legitimate access to the originals, the copies were legitimate fair-use copies when made, the originals haven't been transferred to anyone else, the copies remain legitimate fair-use copies.
It may be embarrassing to the creators to have copies of their sites preserved for posterity, but copyright isn't about preventing an author from being embarrassed.
Baen's Webscriptions would contradict that. It costs about $3.75 per book delivered in electronic form through it (or more, the terms are $15/month, typically 4 books per month). It's popular enough to be making Jim Baen money on the deal. It's making the authors money in royalties. And from the letters Eric's gotten people are not only paying for the electronic versions, they're then going on to buy the paper versions too.
Note that Webscriptions meets the criteria I gave:
I think this fails for one reason: The average internet user isn't willing to pay a meaningful amount for content.
Flint disproves this with hard numbers from royalty statements on his Prime Palaver over on the Baen Free Library. People are paying enough for the electronic forms of his books to earn him somewhat over $2K a year in royalties from the electronic versions. If people aren't willing to pay, where's those dollars in Eric's checking account coming from?
I don't know, Eric Flint and David Drake seem to be making decent money in royalties off electronic forms of their older books. Not great money, maybe 2 grand a year, but then these are older backlist titles that normally only sell 5-600 copies a year so royalties aren't that great for the paper forms either. And the copy-protected electronic forms of Drake's books barely make enough in royalties every year to pay for a decent pizza. I think it boils down to:
- People won't pay per chapter for serialized works, they'd rather get it all at once.
- People won't pay to deal with copy-protection hassles, but they will pay to have it readily available electronically.
- People won't pay as much for the electronic form as for paper.
I think authors can live with this. See Eric Flint's essays over on the Baen Free Library.I think this and prior attempts don't show that publishing on the Web doesn't work so much as they show that publishing books in serialized installments doesn't work.
Wouldn't section 7 cover it? If people who receive SELinux directly from SCC could not modify and redistribute the code without paying patent royalties on SCC's stuff, then SCC's stuff would violate the GPL and they lose the right to redistribute a work based on the GPL'd Linux code, no?
Except that if ICANN, who control the root servers, don't change the delegation for .za in the root zone files, nobody in the world will use the SA gov't's nameservers.
So set up Gnome or KDE on the workstations, no admin privileges to any user accounts of course, with the home directories Coda-mounted and with things locked down per standard for an ISP's shell machines (ie. tighter than a nervous virgin clam). Minimal services running, don't install dangerous things like nmap, and give them a desktop skin that resembles Windows and an xdm/gdm/kdm login box. You only have to assemble the workstation image once, then just clone it over onto workstations as needed. Kernel modules and DHCP are your friend here.
For extra evilness points, lock down their dot-files by making them owned by a special user and not writable by the account itself. This requires a bit of a balancing act, since some dot-files do need to be writable for storing state.
This is the same process needed to secure the workstations used by the CS classes, you're just talking about several thousand workstations instead of several hundred. There's more administrative overhead, but the actual things needed for each workstation are roughly the same. Just be sure to have a beefy enough fileserver (or spread the load over several) to handle the network-mounted home directories.
No conspiracy theory, just Marketing making the technical decisions. Releasing even a simple "disable Gopher protocol" patch would cost some money and be a PR hit. Ignoring the problem doesn't cost anything nor give any PR hit as long as the general public doesn't know about the hole. Any marketroid knows that means you don't fix the hole.
That's also why the spokesman was so upset, not at the hole itself, but at it's revelation: they now have to do the technically correct thing instead of the marketing correct thing.