Yeah, they're trying to act like Dan Bernstein (with daemontools and qmail) and prevent forks that do things in ways they don't like. Some of that desire may be legitimate, but one real desire is probably the desire to avoid encrypted transfers becoming common place and leavingn them vulnerable to governmental complaint about un-tappable data transfers.
I can easily picture the various motion picture and software copyright lawyers sending a few dark glasses wearing "lawyers" to explain "nice little business you got here, I'd hate to see anything happen to it" to encourage Bittorrent both to avoid providing encrypted transfers and to add "load monitoring" features that ease tracking. I'm not saying this is sure to happen, but with the source closed, it wouldn't take much to add hooks to report specific downloads to the mothership.
I'd love to see them name a single case of embedding malware or spyware. Adware, I'd not be surprised by.
Worse, with a closed source application, you can't easily tell if it's what the authors published. Simply publishing a "check out the new beta of Bittorrent at www.spyware.com/idiot-download.zip" is less likely to be noticed than a "here's my source code, source and installer are at sourceforge.net" sort of package.
And being a legitimate advertiser is a lot like being a high-class escort. The business you're engaged in, as legitimate as it may be in the way you practice it, is a paid service tainted by the dangerous majority of its practicioners. You cannot reasonably talk about how "advertisers don't do this" any more than you can say "escorts are safe" without qualifying your statement, restricting it to what seem to the be the clear majority of the professionals we see out here cluttering up the sidewalks and molesting us as we try to get home.
Your business being legitimate simply isn't enough to say "advertisers are well-behaved" when the hideously large majority of the advertisement we see is sent by people who are not at all well-behaved. Even if there are relatively few such abusive advertisers, they are certainly part of your business pool.
Moreover, I'd bet dollars to donuts that you have been defrauded by your clients or had your data stolen at least once in the last year, purchasing your user data and turning right around to resell it under the table or even publicly to other fraudulent businesses. It's endemic to the industry, and painful to prosecute. $10,000 is quite a bit of money, true. But to a Russian spamming gang who just stole a mob of credit cards with their latest bank password phishing scheme, or a cracker geting paid for new mailing lists, it's merely an investment in their paid time.
By the way, your questions are good. You've done the modicum of research to ask your questions, and I applaud you for doing so. I have some old experience with tools like this that make me more aware of the vagaries of the difference betwen public source code and a genuinely open license.
The wu-imapd license is a welcome change, except that the exact same software inside the Pine package has a rather different license, in the file marked CPYRIGHT. That license for Pine (and its ramifications in wu-imapd) are among the compelling reasons it's been left out of most contemporary Linux distributions, and the imap daemon has been replaced by tools like dovecot.
So I guess it's pick and choose for your wu-imapd licenses? No, that's entirely unacceptable. And the historical ramifications of the odd licensing were displayed when people published SSL modificatons for Piine and wu-imapd, and Mark Crispin went absolutely ballistic about it. There are some intriguing behavior of pine and wu-imapd that have caused serious problems, such as wu-imapd's insistence that every file in your home directory is an email file and recursively exploding mail clients that use that same home directory. This includes pine: patches that fix wu-imapd by modifying the c-client library tend to break pine instead.
You need to actually read Dan Bernstein's license, described at http://www.thedjbway.org/license_free.html, to understand his licensing scheme. It is, in fact, quite restrictive to prevent forks of his code. You don't think "/services" should be at/, in violation of the file system hierarchy? Too bad. He won't aprove your modifications, and you can't publish them separately.
I didn't say they're evil: but they're not innocent. They're aggressively pursuing markets, and there are cases where people get badly hurt, like this one. It's hardly the only case, just the most famous.
Your "facts" don't seem to be agreed with by most folks, or may even be unsupported (as they are in your statement here). You have a strong incentive to portray your own company positively, and they may in fact be positive about these practices.
But no, *all* advertising companies do not have these policies. Or don't you count spammers, Viagra salesmen, and "my unclale left me $10,000,000" advertisers? And frankly, they have you outnumbered by far too much for your claim that "all advertising companies" follow any responsible privacy practices. The spammers are an industry, with admittedly a relatively small number of skilled tradesmen selling the spamming services, but there are a whole set of unskilled ones selling their services as well.
I'd also be very surprised indeed if your company has not sold the spammers your data, whether deliberately or by accident or through fraud on the spammers' part, so that your own customers are hit by this kind of "targeted" advertising. It's just too prevalent: as soon as any company says "we share our data with partners", you can pretty much rely on it going to the spammers.
On most days. Google's cooperation with Chinese censorship is troubling: so is the lax overall security of their mail services, which are easily obtained without a warrant or verifiable judicial review under the US "Patriot Act" legislation. So I do wonder at what happens behind closed doors there.
Their overall reputation is good, but let's be clear that they're aggressive.
You've never tried to work with wu-imapd or daemontools, have you? The restrictive licensing on both of those not only prevents forking, but prevents the application of packaging or internal compatibility patches.
Can we use it at Defcon to advertize a site with "latest root exploits"? Then watch where the clean-up staff go to find the rooms for the narcs and the script-kiddies, or at least stay away from anyone with that unfortunate smell on them?
Keeping it secret also hides the sales to spammers, scammers, and people who do follow the CAN-SPAM rules to protect themselves from lawsuit. Publishing the data would doubtless encourage legislation against many of the more nefarious practices, such as selling client lists of who bought the data and the date of its sale to other advertisers so they can plan their ads to best compete with each other, or the use of easily deniable "valid email lists" that are mostly fraudulently or misleadingly gathered.
By the way, if this is really your corporate data policy, I approve. You seem to be doing it responsibly. Unfortunately, which of your corporate partners with access to the data is not keeping it longer? How do you know they're not turning around and resellng it?
Unfortunately, you really need to take a look at the way the ads are routed through otherwise innocuous or useful sites. Finding all the CNAME's for ad.doubleclick.net is not a trivial problem: neither is filtering out the image based ads fed by what are essentially distributed web proxy services like Akamai.
You know, I wonder about Akamai: there have been plenty of published notes about using their services to get around IP based firewalls and censorship. Do they mind? Do they get supboenaed for their records to trace web use the way Google has been?
From your assessment of what a "crap job" is, I suspect that you've not put in the hours and labor to raise children, manage a company, get an MD or PhD, lead a political campaign, etc., etc. Or you're seriously overestimating the amount of "stake" needed to get people to cput in these levels of effort: ask anyone who's got a difficult thesis advisor at a tough college about hwat's involved in getting that piece of paper that says "doctor".
Sir, I'm *both* an end user and a distributor, and even a software author. While I see that there might be a lack of desire to spend time licensing patents to smaller markets such as end users like me, the SSH and PGP using communities were serious markets, and there were certainly distributors of such software who tried to get licenses to use RSA. To the best of my knowledge, they were blown off by the patent holders.
Similar issues apply to other software patents, at least in my personal experience and I believe in the market place.
No, *that* is misleading. A lot of the GPL code I personally write is often based on older GPL code: unweaving those licenses back to the original authors is difficult if not impossible, since GPL does not insist on preserving the author's name in the license or the changelogs.
Finding the original authors of the particular package is not enough if they've lifted code heavily from other projects: not having to sort out such software genealogies is part of the whole point of GPL, and why many of the BSD style licenses foundre in actual use as too complex or too burdened by attributions.
Oh, that's been available for ages. Check out the articles on the theft of hte Half-Life 2 source code, and how playable versions were available in Russia long before it was actually published in the US.
Plausible deniability. By pointing to third party repositories, the Automatix author can try to avoid responsibility or lawsuit for providing the restricted packages, such as libdvdcss and w32codecs.
Note that this is not a small problem. There are a lot of odd and restrictive licenses out there, ranging from Microsoft's "sell us the spleen of your first-born" end-user license to University of Washington's "we didn't say you could do that, even though that's exactly what the words of our license said" for wu-imapd, to Dan Bernstein's "It's open, you just can't modify it at all without my express permission" license. And that's without getting into the patent or DMCA issues.
The automatix author or authors obviously don't want to take this on. That's understandable.
I do. My boss does. My company lawyers do. If I got caught illegally installing such software for Linux users on corporate systems, I'm in direct violation of my employment contract and lose my job. It could also cost the company far more in legal fees and punitive damages than I've saved them by installating admittedly superior Linux based software to accomplish work tasks.
Mr. Stallman and the FSF's approaches, that software patents are a bad and evil thing, and that we need to protect ourselves from licenses that deny us the rights to use or modify our computers to do the things we want, continue to be a source of excellent guidance on these issues. The MP3 patents are a classic example of where software licenses break down: they not only are used to reward the authors, but to actively prevent other competitive use of related or improved products.
Seriously, we've seen exactly this sort of awful, awful bundling written for a lot of RPM repositories as well. Filtering out the badly written ones and providing work-arounds for them is really painful. I'm not surprised at all that some amateur software bundler wrote their "great idea to put it all in one place!" software but proceeded to violate all sorts of basic software standards.
For excellent examples of just this sort of conflict and mispackaging craziness, take a good look at any of the Oracle installers of the last 8 years or so, or any of the hardware vendor's driver installation tools. Serously, most of them are not as bad as this, but lord, they're not good. This is why I worship the names of DAG and DRIES, the primary third-party RPMforge repository maintainers for the RedHat based world. They just do things right and set an amazing example for this sort of repository manager wanna-be.
Unfortunately, the license authors sometimes don't want your money. Seriously, I've tried to pay money for software licenses for tools like MP3 players for Linux, DVD players, and many years ago the RSA owners to use SSH and PGP. I've tried to arrange payment for 200 players for a major office installatioin of DVD playing software for Linux: I probably wasted 24 hours on various phones and emails, overall, with no resolution.
Eventually, I had to close my eyes as someone with system root access (not me!) snuck a libdvdcss installer into the nightly cron jobs. This sort of thing is one of the reasons Linux on the desktop hasn't become more common: A real business need could not be legally met under Linux, not due to a software limitation, but due to an inane legislative restriction.
Hey, if we can get the Bittorrent guys to carry pink water pistols, can we trick Fox into reporting it and get the rest of them fired? It worked on Bill O'Reilly!
* A search engine that actually uses booleans correctly. * A policy that labels for CD or DVD images match what's on them in some consistent format, such as name, author, publisher, comments, with a matching search engine. * Published checksums for the images: this could be used to reduce or elimiinate the duplicates. * Open source or creative commons links: Bittorrent is the fastest way to get Linux CD or DVD images, but they *must* be checksum verified for security reasons. * A policy of sending 3000 volts to the fingertips of the next idiot who uses yet another format for CD or DVD images, wasting my time with bittorrents for formats that no one but some teenager in Slovenia uses.
Replace all corporate file servers with real file servres. (NetApps, Linux boxes, Solaris with ZFS, Samba, whatever fits your budget and needs.)
Run ClamAV on them.
Desktops are expendable and should be re-installed once a month: all work goes on the file servers.
Backup is not an anti-virus issue, use what fits your needs for that. Veritas is overwhelmingly complex and overpowered due to running on PC's. Throw it out and use something that actually backs up the file systems.
And it's usually your own fault it's so long. There are basic fixes, such as:
* A meaningful message saying 'we're swamped, wait time is [whatever], the big problem right now is [whatever], our email and website are at [these locations]'
* Actually connect customers with people who can address the problem. Wasting 45 minutes rebooting and tweaking the software before admitting that it's a kernel problem caused by your software and the only fix is to entirely uninstall it and wait for the next release is a tremendous waste of everyone's time, but it's happened with both Symantec and McAfee within the past year.
* When a customer gives you the workaround or the fix, publish it to your staff quickly and put it in their flow charts. This has happened repeatedly, with both Symantec and McAfee, and numerous staff have wasted their expensive time for months going through the same problem and the same failures to fix it, then finally getting notified by their colleagues that the correct fix was on our internal web pages.
* That 10-20 minutes of time you mention is usually wasted as the tech tries to shoe-horn the problem into a complex ritual of irrelevant problems before acknowledging the problem, when by listening to what the customer actually says they can leapfrog the flowchart to the actual problem.
I've been that IT staff on various occasions. I do *not* consider Symantec's call center to be helpful, and it hasn't been since long before this recent incident. It's only good by comparison to McAfee.
Slashdot Mirror
Yeah, they're trying to act like Dan Bernstein (with daemontools and qmail) and prevent forks that do things in ways they don't like. Some of that desire may be legitimate, but one real desire is probably the desire to avoid encrypted transfers becoming common place and leavingn them vulnerable to governmental complaint about un-tappable data transfers.
I can easily picture the various motion picture and software copyright lawyers sending a few dark glasses wearing "lawyers" to explain "nice little business you got here, I'd hate to see anything happen to it" to encourage Bittorrent both to avoid providing encrypted transfers and to add "load monitoring" features that ease tracking. I'm not saying this is sure to happen, but with the source closed, it wouldn't take much to add hooks to report specific downloads to the mothership.
I'd love to see them name a single case of embedding malware or spyware. Adware, I'd not be surprised by.
Worse, with a closed source application, you can't easily tell if it's what the authors published. Simply publishing a "check out the new beta of Bittorrent at www.spyware.com/idiot-download.zip" is less likely to be noticed than a "here's my source code, source and installer are at sourceforge.net" sort of package.
And being a legitimate advertiser is a lot like being a high-class escort. The business you're engaged in, as legitimate as it may be in the way you practice it, is a paid service tainted by the dangerous majority of its practicioners. You cannot reasonably talk about how "advertisers don't do this" any more than you can say "escorts are safe" without qualifying your statement, restricting it to what seem to the be the clear majority of the professionals we see out here cluttering up the sidewalks and molesting us as we try to get home.
Your business being legitimate simply isn't enough to say "advertisers are well-behaved" when the hideously large majority of the advertisement we see is sent by people who are not at all well-behaved. Even if there are relatively few such abusive advertisers, they are certainly part of your business pool.
Moreover, I'd bet dollars to donuts that you have been defrauded by your clients or had your data stolen at least once in the last year, purchasing your user data and turning right around to resell it under the table or even publicly to other fraudulent businesses. It's endemic to the industry, and painful to prosecute. $10,000 is quite a bit of money, true. But to a Russian spamming gang who just stole a mob of credit cards with their latest bank password phishing scheme, or a cracker geting paid for new mailing lists, it's merely an investment in their paid time.
By the way, your questions are good. You've done the modicum of research to ask your questions, and I applaud you for doing so. I have some old experience with tools like this that make me more aware of the vagaries of the difference betwen public source code and a genuinely open license.
Let's see:
/, in violation of the file system hierarchy? Too bad. He won't aprove your modifications, and you can't publish them separately.
The wu-imapd license is a welcome change, except that the exact same software inside the Pine package has a rather different license, in the file marked CPYRIGHT. That license for Pine (and its ramifications in wu-imapd) are among the compelling reasons it's been left out of most contemporary Linux distributions, and the imap daemon has been replaced by tools like dovecot.
So I guess it's pick and choose for your wu-imapd licenses? No, that's entirely unacceptable. And the historical ramifications of the odd licensing were displayed when people published SSL modificatons for Piine and wu-imapd, and Mark Crispin went absolutely ballistic about it. There are some intriguing behavior of pine and wu-imapd that have caused serious problems, such as wu-imapd's insistence that every file in your home directory is an email file and recursively exploding mail clients that use that same home directory. This includes pine: patches that fix wu-imapd by modifying the c-client library tend to break pine instead.
You need to actually read Dan Bernstein's license, described at http://www.thedjbway.org/license_free.html, to understand his licensing scheme. It is, in fact, quite restrictive to prevent forks of his code. You don't think "/services" should be at
I didn't say they're evil: but they're not innocent. They're aggressively pursuing markets, and there are cases where people get badly hurt, like this one. It's hardly the only case, just the most famous.
Your "facts" don't seem to be agreed with by most folks, or may even be unsupported (as they are in your statement here). You have a strong incentive to portray your own company positively, and they may in fact be positive about these practices.
But no, *all* advertising companies do not have these policies. Or don't you count spammers, Viagra salesmen, and "my unclale left me $10,000,000" advertisers? And frankly, they have you outnumbered by far too much for your claim that "all advertising companies" follow any responsible privacy practices. The spammers are an industry, with admittedly a relatively small number of skilled tradesmen selling the spamming services, but there are a whole set of unskilled ones selling their services as well.
I'd also be very surprised indeed if your company has not sold the spammers your data, whether deliberately or by accident or through fraud on the spammers' part, so that your own customers are hit by this kind of "targeted" advertising. It's just too prevalent: as soon as any company says "we share our data with partners", you can pretty much rely on it going to the spammers.
On most days. Google's cooperation with Chinese censorship is troubling: so is the lax overall security of their mail services, which are easily obtained without a warrant or verifiable judicial review under the US "Patriot Act" legislation. So I do wonder at what happens behind closed doors there.
Their overall reputation is good, but let's be clear that they're aggressive.
You've never tried to work with wu-imapd or daemontools, have you? The restrictive licensing on both of those not only prevents forking, but prevents the application of packaging or internal compatibility patches.
No, no. Use it as a security policy test panel, to remind your ocmpatriots that they should leave Javascript turned off.
Can we use it at Defcon to advertize a site with "latest root exploits"? Then watch where the clean-up staff go to find the rooms for the narcs and the script-kiddies, or at least stay away from anyone with that unfortunate smell on them?
Keeping it secret also hides the sales to spammers, scammers, and people who do follow the CAN-SPAM rules to protect themselves from lawsuit. Publishing the data would doubtless encourage legislation against many of the more nefarious practices, such as selling client lists of who bought the data and the date of its sale to other advertisers so they can plan their ads to best compete with each other, or the use of easily deniable "valid email lists" that are mostly fraudulently or misleadingly gathered.
By the way, if this is really your corporate data policy, I approve. You seem to be doing it responsibly. Unfortunately, which of your corporate partners with access to the data is not keeping it longer? How do you know they're not turning around and resellng it?
Unfortunately, you really need to take a look at the way the ads are routed through otherwise innocuous or useful sites. Finding all the CNAME's for ad.doubleclick.net is not a trivial problem: neither is filtering out the image based ads fed by what are essentially distributed web proxy services like Akamai.
You know, I wonder about Akamai: there have been plenty of published notes about using their services to get around IP based firewalls and censorship. Do they mind? Do they get supboenaed for their records to trace web use the way Google has been?
From your assessment of what a "crap job" is, I suspect that you've not put in the hours and labor to raise children, manage a company, get an MD or PhD, lead a political campaign, etc., etc. Or you're seriously overestimating the amount of "stake" needed to get people to cput in these levels of effort: ask anyone who's got a difficult thesis advisor at a tough college about hwat's involved in getting that piece of paper that says "doctor".
Sir, I'm *both* an end user and a distributor, and even a software author. While I see that there might be a lack of desire to spend time licensing patents to smaller markets such as end users like me, the SSH and PGP using communities were serious markets, and there were certainly distributors of such software who tried to get licenses to use RSA. To the best of my knowledge, they were blown off by the patent holders.
Similar issues apply to other software patents, at least in my personal experience and I believe in the market place.
No, *that* is misleading. A lot of the GPL code I personally write is often based on older GPL code: unweaving those licenses back to the original authors is difficult if not impossible, since GPL does not insist on preserving the author's name in the license or the changelogs.
Finding the original authors of the particular package is not enough if they've lifted code heavily from other projects: not having to sort out such software genealogies is part of the whole point of GPL, and why many of the BSD style licenses foundre in actual use as too complex or too burdened by attributions.
Oh, that's been available for ages. Check out the articles on the theft of hte Half-Life 2 source code, and how playable versions were available in Russia long before it was actually published in the US.
Plausible deniability. By pointing to third party repositories, the Automatix author can try to avoid responsibility or lawsuit for providing the restricted packages, such as libdvdcss and w32codecs.
Note that this is not a small problem. There are a lot of odd and restrictive licenses out there, ranging from Microsoft's "sell us the spleen of your first-born" end-user license to University of Washington's "we didn't say you could do that, even though that's exactly what the words of our license said" for wu-imapd, to Dan Bernstein's "It's open, you just can't modify it at all without my express permission" license. And that's without getting into the patent or DMCA issues.
The automatix author or authors obviously don't want to take this on. That's understandable.
I do. My boss does. My company lawyers do. If I got caught illegally installing such software for Linux users on corporate systems, I'm in direct violation of my employment contract and lose my job. It could also cost the company far more in legal fees and punitive damages than I've saved them by installating admittedly superior Linux based software to accomplish work tasks.
Mr. Stallman and the FSF's approaches, that software patents are a bad and evil thing, and that we need to protect ourselves from licenses that deny us the rights to use or modify our computers to do the things we want, continue to be a source of excellent guidance on these issues. The MP3 patents are a classic example of where software licenses break down: they not only are used to reward the authors, but to actively prevent other competitive use of related or improved products.
Seriously, we've seen exactly this sort of awful, awful bundling written for a lot of RPM repositories as well. Filtering out the badly written ones and providing work-arounds for them is really painful. I'm not surprised at all that some amateur software bundler wrote their "great idea to put it all in one place!" software but proceeded to violate all sorts of basic software standards.
For excellent examples of just this sort of conflict and mispackaging craziness, take a good look at any of the Oracle installers of the last 8 years or so, or any of the hardware vendor's driver installation tools. Serously, most of them are not as bad as this, but lord, they're not good. This is why I worship the names of DAG and DRIES, the primary third-party RPMforge repository maintainers for the RedHat based world. They just do things right and set an amazing example for this sort of repository manager wanna-be.
Unfortunately, the license authors sometimes don't want your money. Seriously, I've tried to pay money for software licenses for tools like MP3 players for Linux, DVD players, and many years ago the RSA owners to use SSH and PGP. I've tried to arrange payment for 200 players for a major office installatioin of DVD playing software for Linux: I probably wasted 24 hours on various phones and emails, overall, with no resolution.
Eventually, I had to close my eyes as someone with system root access (not me!) snuck a libdvdcss installer into the nightly cron jobs. This sort of thing is one of the reasons Linux on the desktop hasn't become more common: A real business need could not be legally met under Linux, not due to a software limitation, but due to an inane legislative restriction.
Hey, if we can get the Bittorrent guys to carry pink water pistols, can we trick Fox into reporting it and get the rest of them fired? It worked on Bill O'Reilly!
Well, let's see.
* A search engine that actually uses booleans correctly.
* A policy that labels for CD or DVD images match what's on them in some consistent format, such as name, author, publisher, comments, with a matching search engine.
* Published checksums for the images: this could be used to reduce or elimiinate the duplicates.
* Open source or creative commons links: Bittorrent is the fastest way to get Linux CD or DVD images, but they *must* be checksum verified for security reasons.
* A policy of sending 3000 volts to the fingertips of the next idiot who uses yet another format for CD or DVD images, wasting my time with bittorrents for formats that no one but some teenager in Slovenia uses.
Replace all corporate file servers with real file servres. (NetApps, Linux boxes, Solaris with ZFS, Samba, whatever fits your budget and needs.)
Run ClamAV on them.
Desktops are expendable and should be re-installed once a month: all work goes on the file servers.
Backup is not an anti-virus issue, use what fits your needs for that. Veritas is overwhelmingly complex and overpowered due to running on PC's. Throw it out and use something that actually backs up the file systems.
And it's usually your own fault it's so long. There are basic fixes, such as:
* A meaningful message saying 'we're swamped, wait time is [whatever], the big problem right now is [whatever], our email and website are at [these locations]'
* Actually connect customers with people who can address the problem. Wasting 45 minutes rebooting and tweaking the software before admitting that it's a kernel problem caused by your software and the only fix is to entirely uninstall it and wait for the next release is a tremendous waste of everyone's time, but it's happened with both Symantec and McAfee within the past year.
* When a customer gives you the workaround or the fix, publish it to your staff quickly and put it in their flow charts. This has happened repeatedly, with both Symantec and McAfee, and numerous staff have wasted their expensive time for months going through the same problem and the same failures to fix it, then finally getting notified by their colleagues that the correct fix was on our internal web pages.
* That 10-20 minutes of time you mention is usually wasted as the tech tries to shoe-horn the problem into a complex ritual of irrelevant problems before acknowledging the problem, when by listening to what the customer actually says they can leapfrog the flowchart to the actual problem.
I've been that IT staff on various occasions. I do *not* consider Symantec's call center to be helpful, and it hasn't been since long before this recent incident. It's only good by comparison to McAfee.