Item One is actually wrong, as far as Linux is concerned at least and likely most other Unixes aside from Sun. On Linux and most of the *BSDs, threads are processes at the kernel level. The only thing special about them is that all the threads in a "process" happen to share address space, file descriptors and a bunch of other things. The schedule doesn't care about all that, though, to it a process with 12 threads is simply 12 processes to schedule, each with it's own priority and other scheduling characteristics.
The whole threads vs. processes dichotomy actually sprang from Windows. In Unix, processes were traditionally lightweight and fast to create. In fact, the original fork() call essentially created what today we call a thread, sharing address space with it's parent. Only after exec() did the address spaces split. Unix programmers just forked processes as needed, and the overhead wasn't much. If we needed to share address space, well, we had shared memory and mmap() and similar things that were easy enough to use when needed. Then Windows came along, with it's process model inherited from VMS. VMS and Windows processes were huge, ungainly beasts that were expensive to create. You simply couldn't create multiple processes without unacceptable overhead. So Windows invented threads to dump most of the overhead when you needed a new execution thread but could share address space and such. And everybody asked "Why doesn't Unix have threads?", and simply refused to accept "Because it doesn't need them.". So Unix finally acquired threads to satisfy the buzzwords, and Unix programmers continued doing what we'd been doing since the mid-70s, just calling pthread_create() instead of fork().
It's Posix-compliant at the most minimal level. When Microsoft designed the subsystem, it had one goal: be able to check off the "Posix compliant" item on the government purchasing checklist. It did not want Posix apps developed, because that would be against Microsoft's business interests, but it needed that compliance to technically qualify for government contracts. So it implemented the absolute minimum it had to to get the minimal certification and no more. And minimal Posix compliance is minimal indeed, being aimed at embedded devices.
It's the Windows development tools. By default they generate code that uses tons of Windows-specific APIs that aren't portable to anything but another version of Windows (and sometimes not even then). If you start with OS-specific code, then yes supporting other OSes looks difficult. Combine this with Microsoft's business need to make portability look as difficult as possible to discourage developers from aiming for it and the results are predictable.
Wouldn't really work. It'd have to be so integral to the kernel that the kernel couldn't function without it, and at the same time sufficiently seperate that (like the nVidia binary module) it could be modularized without any modifications to kernel code and without including any kernel code in the module. If that weren't the case then MS would have to comply with the only license the other copyright holders have given them to distribute their code, the GPL, or be themselves infringing on copyrights. I don't see how MS could come up with a component like that.
Section 7 of the GPL explicitly says it's not limited to any particular thing, so equivocation about "covenant" vs. "license" doesn't get either of them out of it. If Novell can't pass on to it's customers all rights needed for them to redistribute SuSE Linux, then the GPLv2 says it doesn't have a license to distribute Linux at all. If those rights come from a convenant not to sue rather than a patent license, they're still required for SuSE's customers to redistribute SuSE Linux. GPLv3 makes the point even clearer, but GPLv2 has enough language in it to make the argument. I think all Novell's managed to do here is shoot themselves in the foot, and MS won't gain any advantage from having one "blessed" distribution when that blessing calls that distribution's copyright license into question.
Where I work the ECPA wouldn't be a problem. It's made clear up-front that all e-mail and all Internet access goes through the company's servers and is filtered, logged and monitored. Moreover, it actually is monitored. Normally the logs are checked at random, but if you're generating a lot of traffic they'll be taking a closer look since it's out of the ordinary. And they may monitor more closely in two situations:
Performance issues. If you're not getting your work done but you're doing a lot on your computer, they'll be looking at your logs specifically to see what you're doing with your time. The results'll get passed on to your manager who'll discuss your performance with you and give you suggestions/directions for correcting the problem. If you don't shape up, you'll be terminated.
Unacceptable material. If the random checks or the investigation of a performance issue turns up a pattern of unacceptable material, your manager'll be told and he'll have a discussion with you about it. That discussion will include a written warning describing the unacceptable material. If it happens again after you've been warned, you'll be terminated.
I doubt the ECPA would provide any way for an employee to contest that. The active policing would probably defang any "expectation of privacy despite what the policy says" argument, for example. The problems all seem to be coming from the company making a policy and then ignoring it day-to-day until they need a justification for what they've already decided. The company actively following the policy day-to-day as well as expecting the employees to follow it seems to be the cure.
It sounds like the problem wasn't just the "oh, another form to sign" nature of the code of conduct, it was the company's behavior. Remember, the IRC said outright that, despite the company claiming a "no tolerance" policy, they didn't act like one existed up until they had to terminate this guy. Likely they, like most companies, didn't actually police the code of conduct, they just let employees do anything at all until the company finally stumbled on something bad, and then and only then did the code of conduct come up. The solution the court's looking for, I suspect, is for the company to actually routinely police the code of conduct, regularly look at employees to see whether they're following it, warn those that're starting to push the borderline and generally act like the company cares about the code of conduct before it gets to a termination situation.
I notice a few things about the article that're just plain wrong. Hardware support, for example. For the most part, when I install Linux on a computer all the hardware's autodetected and the correct drivers installed by the installer. No updates, no vendor driver discs, once the install's done everything's there. The only thing that isn't typically done is installing the proprietary video-card drivers, and even then basic drivers are installed that support the full range of the video card's capabilities other than 3D accelleration. When I had to reinstall Windows XP last week, by contrast, the install was only the start of the process. Once the install was done I had to go through the process of installing all the vendor drivers: motherboard chipset, network interface, sound, IDE, printer, scanner, keyboard, mouse. Then I had to install the video-card driver and the monitor driver, then reconfigure the display settings. None of that comes with Windows XP, all it has are the most basic generic drivers that lack support for most of the hardware's capabilities. And once that's done, there's the several-hour slog getting all of Windows' defaults changed from it's initial assumptions to ones that work on a reasonably-designed network (eg. "No you will not contact Microsoft for time, you'll query the timeserver you were told to in the DHCP response."). And this isn't some ancient system, this is a fairly recent P4-based system.
For applications, the same thing. On a Linux system I just select from a list of what I want during install, and it's installed. On Windows if I want a word processor, or a spreadsheet, or a graphics program or just about anything, I have to go to the store and get it and then walk through it's installer. When it comes to Linux apps it's just a much easier process than with Windows. The exceptions are, oddly, the stuff that isn't from the Linux community: commercial software or things like the proprietary ATI and nVidia video-card drivers. The only stuff that's hard to install on Linux is the commercial, proprietary software. Why should Linux take the heat because the big software companies with millions of dollars in revenue can't write a basic shell script that queries the system for some locations, copies files to the correct places and creates a few symlinks?
The only thing it's right on is the state of gaming. And even then, I don't think Linux is to blame so much as Windows. Doom 3, Quake 4, they run nicely on my Linux system. But they're written to use OpenGL, so it's easy to port them to things other than Windows. Games like Everquest 2 that use DirectX are all but impossible to port, so they're not ported. DirectX is, oddly, a "standard" controlled entirely by Microsoft that changes at it's whim (see DirectX 10 for an example). And of course it wasn't Linux that crippled OpenGL by giving users a choice of running OpenGL only through an emulation layer that mapped it (poorly) to DirectX or giving up the new desktop rendering system that's one of the main attractions of the latest OS release.
What method's best depends on exactly what kind of things you're doing. You don't say what your business will be, so it's hard to say what's going to work best.
The one constant, though, is that you'll always have at least one unreasonable party involved. If both parties were reasonable they'll likely come to some sort of acceptable resolution without needing to go to dispute resolution, so if they get to needing your process at least one of them's being unreasonable and ornery. Whatever process you use has to be able to handle that, and it also has to be able to handle the case when both parties are unreasonable, irrational and generally mule-headed. Any system that assumes both parties are reasonable is doomed to failure from the start.
First is the wording. When I see terms like "superstar" in a job ad, the first thing I think is a dot-com startup that wants someone with every buzzword in the book, or they want someone with 20 years experience willing to work 80-hour weeks for an entry-level salary plus stock options (which may make you a millionaire 5 years down the road, assuming you haven't gone up a bell-tower with a rifle before then, or may be worth less than toilet paper, but definitely won't pay the bills in the meantime). Needless to say, this isn't something that instantly makes me think "I want to work for these people.". One of the problems is that the better a developer is, the less likely they are to think of themselves as a superstar. All too often I look at a job description and say "Well yes, but that's the minimum you should be expecting from someone with any sort of experience at all. Do I want to work for someone who considers that exceptional?".
Then there's the fact that, like I suspect most good developers, I'm already working. I'm not likely to leave a decent job on a whim. The last job change I had, it happened only because the headhunter was one a friend of mine gave a good reference on, the job was offering a 20% salary increase just after my current employer had announced 2% raises and the call came shortly after my then-current manager had pulled a particularly nasty and uncalled-for back-stabbing move on me. If people are in a comfortable position, you may have to go looking for them rather than having them come looking for you and you may have to catch them at just the right time to get them to consider changing jobs.
That section 1076 reads like it's intended to clearly allow the President to send in the National Guard during an emergency like Katrina, even (or especially) when the state governor hasn't asked for it explicitly. Of course, during Katrina the state governor had asked, so this section wouldn't have been neccesary to allow the National Guard in...
Simple: once you've been served with a lawsuit, removing relevant data from the hard drive would be destruction of evidence and will earn you sanctions ranging from being cited for contempt of court up to having your actions held against you (eg. the judge rules that your removal of the files constitutes evidence that they were in fact copyright violations). This also applies before you're served if you know (or should reasonably know) you will be served. Basically, if you want to wipe out evidence you'd better do it before the RIAA contacts you.
I prefer to put it as the GPL takes away one "freedom" from the recipients: the freedom to make the code non-free. This is certainly a major restriction to certain people, but I liken it to laws against theft restricting the freedom of thieves to steal.
True, which is why the BSD license is still being used. It's the perfect fit if you want that. But the overwhelming majority of software projects said "We work on share and share alike. If you use our code to your benefit, the price is that we get to use your code for our benefit in return.". And IIRC it was things like finding the BSD networking stack in Windows, obviously modified but with no code being returned, that triggered a lot of the moves to the GPL. I see a parallel with Tivo there.
The question is, free for who? The BSD license grants total freedom to the recipient. The GPL grants freedom to the code. Myself, I take the position that I'm licensing anything I write under the GPL or LGPL, and if a company wants to use it without having to give their modifications back they can come talk to me and discuss payment in an alternative coin.
When I read stuff like that, I recall a lot of the same things were said about Stallman and the GPL back when it was coming out. The GPL would drive companies away from open-source software, it was said, because the terms were too radical. Well, businesses didn't like the terms, it was true. But the main thing about the GPL businesses didn't like, the fact that it prevented them from taking GPL'd code and exploiting it for their own profit without letting others do the same, attracted developers in droves. And the result was software that was just too attractive for businesses to just ignore.
I'll go out on a limb and predict that GPLv3 will follow the same path that GPLv2 and GPLv1 did. And it won't include dying.
Exactly. Spamhaus makes the spammers the ISP's direct problem. Without blocking, or with very selective blocking, the spammers aren't the ISP's problem at all. The only people who complain about them can't financially affect the ISP, so why should the ISP act against a paying customer? With netblock-level blocking, it moves the effect of the spammer onto people who are paying customers of the ISP. When they start complaining, the ISP takes action.
Spamhaus is only part of the problem for people who want to benefit financially from spammers without suffering any financial consequences for doing so.
That's the way it's supposed to work. It's a matter of leverage.
Suppose I'm receiving spam from the spammer who's buying service from you. I complain to you and ask you to take down the web site he's using to peddle his wares. What reason do you have to do anything about him? He's paying you, I'm not. As long as only his servers are blacklisted, he's going to remain in business.
Now, Spamhaus comes along and blacklists the netblock he's in. A lot of your legitimate customers now find themselves unable to send mail. They start to complain to you. Now you're facing a business decision: do you drop the one spammer, or do you watch many of your customers leave for other ISPs that don't host spammers? Action's much more likely when the people complaining are actually your paying customers.
And yes, we tried being selective. We tried for years. It didn't work. It didn't get your attention. Netblock-wide blacklisting is getting your attention.
The GPL aims to restrict only one "freedom": the freedom to restrict other people's freedoms. It says simply that if I as the original author granted everyone certain freedoms, you as a distributor or modifier of my code are not free to take away those freedoms and if you try you lose your right to be a distributor or modifier. Certainly this restricts your freedoms, but most people using the GPL don't see that as anything worse than laws against theft restricting the freedom of thieves to steal.
Not quite. See USC Title 17 Section 117 for details. 117(a)1 specifically says that it is not an infringement to make copies which are an essential step in utilizing a computer program. That means that both the copy made to the hard disk from the installation media and the copy made in RAM to execute are not infringing by law, regardless of what the copyright owner may claim. And if you raise the DMCA, see USC Title 117 1201(c)1 which says that nothing in the DMCA overrules any other portion of Title 117.
The GPL shouldn't be presented as an EULA, because it isn't one. Sections 0 and 5 both make it abundantly clear that you do not need to agree to the GPL to merely use the software. Presenting the GPL as an EULA isn't consistent with those sections.
In fact, the software's author may even argue that a distributor who presents the GPL as an EULA where declining it causes the software to not be installed is in fact violating the GPL themselves. The requirement to agree with the GPL before use would be an additional condition not required by the GPL itself, and adding that condition would violate section 4 of the GPL.
Or he could just, as per #2, be saying that he's coincidentally got some of those songs but not because he got them from any file-sharing service. More than one person has likely ripped any given song, so it's entirely possible that he's got songs ripped from his CDs that someone else also has and is sharing.
Actually Hormel has been pretty consistent in trying to enforce their trademark. They started back when spam was first becoming a popular term for unsolicited bulk e-mail. It's just that most of their efforts have failed on exactly your point: that the public's not likely to confuse e-mail with a processed meat product.
Bear in mind that your stats may be biased. The Web statistics for my site indicate >75% IE usage, <25% Mozilla-family. The server logs, though, report >50% of page hits (exclusive of images) are from Mozilla-family browsers, <50% from IE. I can't believe the browsing behavior of IE users is that radically different from Mozilla users, so the discrepancy has to be in how the browsers themselves handle the Web stats code. My bet is that the Mozilla family of browsers (or various add-ins to them) are simply better at filtering out and not executing the Web bugs that the stats-collection company uses, and that people who use Mozilla-family browsers are more likely to actually enable such filtering. I'd note also that a lot of Web-stats companies only track and report browser type and version for browsers that accept third-party cookies, and the Mozilla family make it much easier to block third-party cookies (which are almost inevitably from advertisers, not the site itself) without affecting first-party cookies (those belonging to the actual site). This alone can cause a major skew in the stats.
Slashdot Mirror
Item One is actually wrong, as far as Linux is concerned at least and likely most other Unixes aside from Sun. On Linux and most of the *BSDs, threads are processes at the kernel level. The only thing special about them is that all the threads in a "process" happen to share address space, file descriptors and a bunch of other things. The schedule doesn't care about all that, though, to it a process with 12 threads is simply 12 processes to schedule, each with it's own priority and other scheduling characteristics.
The whole threads vs. processes dichotomy actually sprang from Windows. In Unix, processes were traditionally lightweight and fast to create. In fact, the original fork() call essentially created what today we call a thread, sharing address space with it's parent. Only after exec() did the address spaces split. Unix programmers just forked processes as needed, and the overhead wasn't much. If we needed to share address space, well, we had shared memory and mmap() and similar things that were easy enough to use when needed. Then Windows came along, with it's process model inherited from VMS. VMS and Windows processes were huge, ungainly beasts that were expensive to create. You simply couldn't create multiple processes without unacceptable overhead. So Windows invented threads to dump most of the overhead when you needed a new execution thread but could share address space and such. And everybody asked "Why doesn't Unix have threads?", and simply refused to accept "Because it doesn't need them.". So Unix finally acquired threads to satisfy the buzzwords, and Unix programmers continued doing what we'd been doing since the mid-70s, just calling pthread_create() instead of fork().
It's Posix-compliant at the most minimal level. When Microsoft designed the subsystem, it had one goal: be able to check off the "Posix compliant" item on the government purchasing checklist. It did not want Posix apps developed, because that would be against Microsoft's business interests, but it needed that compliance to technically qualify for government contracts. So it implemented the absolute minimum it had to to get the minimal certification and no more. And minimal Posix compliance is minimal indeed, being aimed at embedded devices.
It's the Windows development tools. By default they generate code that uses tons of Windows-specific APIs that aren't portable to anything but another version of Windows (and sometimes not even then). If you start with OS-specific code, then yes supporting other OSes looks difficult. Combine this with Microsoft's business need to make portability look as difficult as possible to discourage developers from aiming for it and the results are predictable.
Wouldn't really work. It'd have to be so integral to the kernel that the kernel couldn't function without it, and at the same time sufficiently seperate that (like the nVidia binary module) it could be modularized without any modifications to kernel code and without including any kernel code in the module. If that weren't the case then MS would have to comply with the only license the other copyright holders have given them to distribute their code, the GPL, or be themselves infringing on copyrights. I don't see how MS could come up with a component like that.
Section 7 of the GPL explicitly says it's not limited to any particular thing, so equivocation about "covenant" vs. "license" doesn't get either of them out of it. If Novell can't pass on to it's customers all rights needed for them to redistribute SuSE Linux, then the GPLv2 says it doesn't have a license to distribute Linux at all. If those rights come from a convenant not to sue rather than a patent license, they're still required for SuSE's customers to redistribute SuSE Linux. GPLv3 makes the point even clearer, but GPLv2 has enough language in it to make the argument. I think all Novell's managed to do here is shoot themselves in the foot, and MS won't gain any advantage from having one "blessed" distribution when that blessing calls that distribution's copyright license into question.
Where I work the ECPA wouldn't be a problem. It's made clear up-front that all e-mail and all Internet access goes through the company's servers and is filtered, logged and monitored. Moreover, it actually is monitored. Normally the logs are checked at random, but if you're generating a lot of traffic they'll be taking a closer look since it's out of the ordinary. And they may monitor more closely in two situations:
- Performance issues. If you're not getting your work done but you're doing a lot on your computer, they'll be looking at your logs specifically to see what you're doing with your time. The results'll get passed on to your manager who'll discuss your performance with you and give you suggestions/directions for correcting the problem. If you don't shape up, you'll be terminated.
- Unacceptable material. If the random checks or the investigation of a performance issue turns up a pattern of unacceptable material, your manager'll be told and he'll have a discussion with you about it. That discussion will include a written warning describing the unacceptable material. If it happens again after you've been warned, you'll be terminated.
I doubt the ECPA would provide any way for an employee to contest that. The active policing would probably defang any "expectation of privacy despite what the policy says" argument, for example. The problems all seem to be coming from the company making a policy and then ignoring it day-to-day until they need a justification for what they've already decided. The company actively following the policy day-to-day as well as expecting the employees to follow it seems to be the cure.Been tried. See UCITA. Consumer outrage killed it in all but 2 states.
It sounds like the problem wasn't just the "oh, another form to sign" nature of the code of conduct, it was the company's behavior. Remember, the IRC said outright that, despite the company claiming a "no tolerance" policy, they didn't act like one existed up until they had to terminate this guy. Likely they, like most companies, didn't actually police the code of conduct, they just let employees do anything at all until the company finally stumbled on something bad, and then and only then did the code of conduct come up. The solution the court's looking for, I suspect, is for the company to actually routinely police the code of conduct, regularly look at employees to see whether they're following it, warn those that're starting to push the borderline and generally act like the company cares about the code of conduct before it gets to a termination situation.
I notice a few things about the article that're just plain wrong. Hardware support, for example. For the most part, when I install Linux on a computer all the hardware's autodetected and the correct drivers installed by the installer. No updates, no vendor driver discs, once the install's done everything's there. The only thing that isn't typically done is installing the proprietary video-card drivers, and even then basic drivers are installed that support the full range of the video card's capabilities other than 3D accelleration. When I had to reinstall Windows XP last week, by contrast, the install was only the start of the process. Once the install was done I had to go through the process of installing all the vendor drivers: motherboard chipset, network interface, sound, IDE, printer, scanner, keyboard, mouse. Then I had to install the video-card driver and the monitor driver, then reconfigure the display settings. None of that comes with Windows XP, all it has are the most basic generic drivers that lack support for most of the hardware's capabilities. And once that's done, there's the several-hour slog getting all of Windows' defaults changed from it's initial assumptions to ones that work on a reasonably-designed network (eg. "No you will not contact Microsoft for time, you'll query the timeserver you were told to in the DHCP response."). And this isn't some ancient system, this is a fairly recent P4-based system.
For applications, the same thing. On a Linux system I just select from a list of what I want during install, and it's installed. On Windows if I want a word processor, or a spreadsheet, or a graphics program or just about anything, I have to go to the store and get it and then walk through it's installer. When it comes to Linux apps it's just a much easier process than with Windows. The exceptions are, oddly, the stuff that isn't from the Linux community: commercial software or things like the proprietary ATI and nVidia video-card drivers. The only stuff that's hard to install on Linux is the commercial, proprietary software. Why should Linux take the heat because the big software companies with millions of dollars in revenue can't write a basic shell script that queries the system for some locations, copies files to the correct places and creates a few symlinks?
The only thing it's right on is the state of gaming. And even then, I don't think Linux is to blame so much as Windows. Doom 3, Quake 4, they run nicely on my Linux system. But they're written to use OpenGL, so it's easy to port them to things other than Windows. Games like Everquest 2 that use DirectX are all but impossible to port, so they're not ported. DirectX is, oddly, a "standard" controlled entirely by Microsoft that changes at it's whim (see DirectX 10 for an example). And of course it wasn't Linux that crippled OpenGL by giving users a choice of running OpenGL only through an emulation layer that mapped it (poorly) to DirectX or giving up the new desktop rendering system that's one of the main attractions of the latest OS release.
What method's best depends on exactly what kind of things you're doing. You don't say what your business will be, so it's hard to say what's going to work best.
The one constant, though, is that you'll always have at least one unreasonable party involved. If both parties were reasonable they'll likely come to some sort of acceptable resolution without needing to go to dispute resolution, so if they get to needing your process at least one of them's being unreasonable and ornery. Whatever process you use has to be able to handle that, and it also has to be able to handle the case when both parties are unreasonable, irrational and generally mule-headed. Any system that assumes both parties are reasonable is doomed to failure from the start.
First is the wording. When I see terms like "superstar" in a job ad, the first thing I think is a dot-com startup that wants someone with every buzzword in the book, or they want someone with 20 years experience willing to work 80-hour weeks for an entry-level salary plus stock options (which may make you a millionaire 5 years down the road, assuming you haven't gone up a bell-tower with a rifle before then, or may be worth less than toilet paper, but definitely won't pay the bills in the meantime). Needless to say, this isn't something that instantly makes me think "I want to work for these people.". One of the problems is that the better a developer is, the less likely they are to think of themselves as a superstar. All too often I look at a job description and say "Well yes, but that's the minimum you should be expecting from someone with any sort of experience at all. Do I want to work for someone who considers that exceptional?".
Then there's the fact that, like I suspect most good developers, I'm already working. I'm not likely to leave a decent job on a whim. The last job change I had, it happened only because the headhunter was one a friend of mine gave a good reference on, the job was offering a 20% salary increase just after my current employer had announced 2% raises and the call came shortly after my then-current manager had pulled a particularly nasty and uncalled-for back-stabbing move on me. If people are in a comfortable position, you may have to go looking for them rather than having them come looking for you and you may have to catch them at just the right time to get them to consider changing jobs.
That section 1076 reads like it's intended to clearly allow the President to send in the National Guard during an emergency like Katrina, even (or especially) when the state governor hasn't asked for it explicitly. Of course, during Katrina the state governor had asked, so this section wouldn't have been neccesary to allow the National Guard in...
Simple: once you've been served with a lawsuit, removing relevant data from the hard drive would be destruction of evidence and will earn you sanctions ranging from being cited for contempt of court up to having your actions held against you (eg. the judge rules that your removal of the files constitutes evidence that they were in fact copyright violations). This also applies before you're served if you know (or should reasonably know) you will be served. Basically, if you want to wipe out evidence you'd better do it before the RIAA contacts you.
I prefer to put it as the GPL takes away one "freedom" from the recipients: the freedom to make the code non-free. This is certainly a major restriction to certain people, but I liken it to laws against theft restricting the freedom of thieves to steal.
True, which is why the BSD license is still being used. It's the perfect fit if you want that. But the overwhelming majority of software projects said "We work on share and share alike. If you use our code to your benefit, the price is that we get to use your code for our benefit in return.". And IIRC it was things like finding the BSD networking stack in Windows, obviously modified but with no code being returned, that triggered a lot of the moves to the GPL. I see a parallel with Tivo there.
The question is, free for who? The BSD license grants total freedom to the recipient. The GPL grants freedom to the code. Myself, I take the position that I'm licensing anything I write under the GPL or LGPL, and if a company wants to use it without having to give their modifications back they can come talk to me and discuss payment in an alternative coin.
When I read stuff like that, I recall a lot of the same things were said about Stallman and the GPL back when it was coming out. The GPL would drive companies away from open-source software, it was said, because the terms were too radical. Well, businesses didn't like the terms, it was true. But the main thing about the GPL businesses didn't like, the fact that it prevented them from taking GPL'd code and exploiting it for their own profit without letting others do the same, attracted developers in droves. And the result was software that was just too attractive for businesses to just ignore.
I'll go out on a limb and predict that GPLv3 will follow the same path that GPLv2 and GPLv1 did. And it won't include dying.
Exactly. Spamhaus makes the spammers the ISP's direct problem. Without blocking, or with very selective blocking, the spammers aren't the ISP's problem at all. The only people who complain about them can't financially affect the ISP, so why should the ISP act against a paying customer? With netblock-level blocking, it moves the effect of the spammer onto people who are paying customers of the ISP. When they start complaining, the ISP takes action.
Spamhaus is only part of the problem for people who want to benefit financially from spammers without suffering any financial consequences for doing so.
That's the way it's supposed to work. It's a matter of leverage.
Suppose I'm receiving spam from the spammer who's buying service from you. I complain to you and ask you to take down the web site he's using to peddle his wares. What reason do you have to do anything about him? He's paying you, I'm not. As long as only his servers are blacklisted, he's going to remain in business.
Now, Spamhaus comes along and blacklists the netblock he's in. A lot of your legitimate customers now find themselves unable to send mail. They start to complain to you. Now you're facing a business decision: do you drop the one spammer, or do you watch many of your customers leave for other ISPs that don't host spammers? Action's much more likely when the people complaining are actually your paying customers.
And yes, we tried being selective. We tried for years. It didn't work. It didn't get your attention. Netblock-wide blacklisting is getting your attention.
Except that the GPL doesn't require acceptance of any license to merely use the software. And it says so explicitly.
The GPL aims to restrict only one "freedom": the freedom to restrict other people's freedoms. It says simply that if I as the original author granted everyone certain freedoms, you as a distributor or modifier of my code are not free to take away those freedoms and if you try you lose your right to be a distributor or modifier. Certainly this restricts your freedoms, but most people using the GPL don't see that as anything worse than laws against theft restricting the freedom of thieves to steal.
Not quite. See USC Title 17 Section 117 for details. 117(a)1 specifically says that it is not an infringement to make copies which are an essential step in utilizing a computer program. That means that both the copy made to the hard disk from the installation media and the copy made in RAM to execute are not infringing by law, regardless of what the copyright owner may claim. And if you raise the DMCA, see USC Title 117 1201(c)1 which says that nothing in the DMCA overrules any other portion of Title 117.
The GPL shouldn't be presented as an EULA, because it isn't one. Sections 0 and 5 both make it abundantly clear that you do not need to agree to the GPL to merely use the software. Presenting the GPL as an EULA isn't consistent with those sections.
In fact, the software's author may even argue that a distributor who presents the GPL as an EULA where declining it causes the software to not be installed is in fact violating the GPL themselves. The requirement to agree with the GPL before use would be an additional condition not required by the GPL itself, and adding that condition would violate section 4 of the GPL.
Or he could just, as per #2, be saying that he's coincidentally got some of those songs but not because he got them from any file-sharing service. More than one person has likely ripped any given song, so it's entirely possible that he's got songs ripped from his CDs that someone else also has and is sharing.
Actually Hormel has been pretty consistent in trying to enforce their trademark. They started back when spam was first becoming a popular term for unsolicited bulk e-mail. It's just that most of their efforts have failed on exactly your point: that the public's not likely to confuse e-mail with a processed meat product.
Bear in mind that your stats may be biased. The Web statistics for my site indicate >75% IE usage, <25% Mozilla-family. The server logs, though, report >50% of page hits (exclusive of images) are from Mozilla-family browsers, <50% from IE. I can't believe the browsing behavior of IE users is that radically different from Mozilla users, so the discrepancy has to be in how the browsers themselves handle the Web stats code. My bet is that the Mozilla family of browsers (or various add-ins to them) are simply better at filtering out and not executing the Web bugs that the stats-collection company uses, and that people who use Mozilla-family browsers are more likely to actually enable such filtering. I'd note also that a lot of Web-stats companies only track and report browser type and version for browsers that accept third-party cookies, and the Mozilla family make it much easier to block third-party cookies (which are almost inevitably from advertisers, not the site itself) without affecting first-party cookies (those belonging to the actual site). This alone can cause a major skew in the stats.