The SSL connection with authentication should not be made over port 25. Port 25 is for standard (non-SSL, non-Auth) connections. While it might accept the other connections, it is not the preferred port for this.
The big change that might need to be made is to support SMTP Auth over port 587. However, I suspect that they already do this (its part of the SSL/Auth setup). This should just be a matter of changing client configuration to go there. No VPN needed.
They can't reduce the clauses of the GPL (which prohibit restriction of redistribution) by separate agreement. If they could, they could just make a separate agreement (for anything) with you that said, "We distributed the software under the GPL, but if you exercise your GPL rights (of modification or redistribution), you must pay us one billion dollars."
The kind of clause you mention would put the burden on you to prove that the cancellation was distribution related, but if you could, they could not redistribute software under the GPL anymore (just like SCO).
Employment also has that "at will" clause, but you still can't terminate because of someone's race.
Your missing the point. If I lose something because I redistributed, then I am restricted from redistributing. Yes, I can accept the loss and redistribute, but this is not freedom. It's like saying that you are free to distribute drugs in the US; you just go to jail afterwards. Or a better analogy would be if you could go to jail for criticizing the President. That's not free speech; this isn't free software.
You may be correct and the current license would not regard this as a restriction. That's a legal issue. I disagree (based on my interpretation of the word restriction), but your interpretation could certainly be correct, IANAL. My point is that this should *not* be allowed under the GPL. If it is, then the GPL is toothless.
The fact that the loss is of updates (which aren't and shouldn't be covered by the GPL) is irrelevant. My water company can't (or at least shouldn't be able to) turn my water off for redistributing GPLed programs and still distribute GPLed programs itself either.
"Look at it a different way, would you be "ok" with this described situation if it wasn't a GPL program?"
Sure. I might not like it, but it would probably be legal (note: those agreements don't always hold up in court; consumers have various fair use rights that can negate them). Note that I'm not arguing that support should be required for modified code (or refrigerators). That agreement *is* entirely separate. What I'm saying is that if you buy two refrigerators and resell one, that doesn't mean that you lose support on your first refrigerator. I'm not sure if that (losing support for this unit based on sale of another unit) would hold up in court on the face of it; I'm positive that it wouldn't be compliant with a license that had similar clauses to section 6 of the GPL.
The issue is that software allows exact copies. If I could buy one refrigerator, copy it, and still have the original refrigerator, I would expect support on the original refrigerator (I wouldn't expect anything for the copy). With software, you buy an infinite number of identical units. Under the GPL, you can redistribute as many of them as you want *without added restriction*. Removing upgrades or other forms of support from you because you redistributed is certainly not within the spirit of the GPL, and I don't believe that it is within the letter either.
They can. They just can't selectively refuse updates because someone redistributed the source. It's not selectively refusing updates that is the problem; it's linking it to source redistribution that causes the conflict.
Another analogy. The GPL doesn't oblige you to distribute your program for free. Why can't you collect $10 every time someone else redistributes the program? It's the same clause in the GPL: charging for redistribution is a restriction; cancelling their update privileges *as a result of distribution* is a restriction on distribution.
Or look at the original Linksys issue. Sveasoft would not currently have the code if Linksys had said that anyone who distributed the code had to return their Linksys hardware. As soon as Sveasoft had distributed their first beta, by your logic, Linksys could have reposessed their hardware (the GPL doesn't oblige you to offer hardware after all). Sveasoft would have had to stop development without hardware for testing.
If this stands, it is a gaping hole through the GPL. Just bundle your GPLed program with anything. If they utilize their GPL rights, they lose the other part of the bundle.
You need to read http://www.fsf.org/licenses/gpl-faq.html#WhatDoesW rittenOfferValid or section 3b of the GPL. I've quoted it elsewhere in this same thread, so I won't quote it again.
If they do not distribute the source with the binary, they must offer it to *anyone* under the same terms as they offer it to people to whom they distributed the binary.
"Now under the terms of the license for access to the server they can cancel your server account if you redistribute."
It's still a restriction on *distribution* which they can't do and be complying with the GPL. The fact that the FTP server access is separate from the GPL is irrelevant. There is nothing in the license saying that the distribution restriction clause only applies to the GPL agreement. As I read it, the clause prevents them from restricting distribution in *any* agreement they might make. Again, the FTP server access could be restricted based on all sorts of other reasons without invoking the GPL. By bringing up the GPLed redistribution though, the separate agreement invokes (and conflicts with) the GPL.
The third party clause can't be good just once. If you receive the binary under 3b and redistribute to to two people, then it must be good for *each* of them. The two can be generalized out to any number. Further, the two can each redistribute under 3c. Once the company does not comply with 3a (distribute the source with the binary), it's stuck giving the source to anyone who requests it. Once they have distributed to a particular person, they might not have to distribute to that particular person again; however, they would still have to give the source to any new person who asked.
IANAL either, but please reread the 3b that you posted, where it says "any third party." Anyone can request the source and it must be provided (for no more than media/distribution cost) if it was not provided originally (3a). 3c does not apply to Sveasoft, just to those who distribute binaries from Sveasoft that they originally obtained under the terms of 3b (3c says they must pass on the source code offer). Sveasoft both modified the source and provided the binary commercially.
This one ( http://www.fsf.org/licenses/gpl.html ):
* b) Accompany it with a written offer, valid for at least three years, to give any third party, for a charge no more than your cost of physically performing source distribution, a complete machine-readable copy of the corresponding source code, to be distributed under the terms of Sections 1 and 2 above on a medium customarily used for software interchange; or,
----- If they do not provide the source with the binary (which is what 3a covers) and modified the original source code (section 3c covers unmodified binaries for non-commercial use; they would also get caught on the non-commercial use), then they must do b (and they currently do not seem to be). Note the "any third party" clause. That is the same as "anyone," which is what I said.
They are certainly allowed to charge any price they wish for the initial transfer and any warranty they may provide. Afterwards however, they can't charge more for the source, as the distribution cost has already been set. (I said that they needed to offer the source for free, but that is incorrect, they can charge a media/distribution charge.) They can't claim that they can distribute multiple binaries for $20 but that it costs $50 to distribute a single copy of the source code. It's an absurd claim.
In section 6, the GPL says, "You may not impose any further restrictions on the recipients' exercise of the rights granted herein." Revoking the right they bought to get updates does this if you do it *because* they redistributed the program. They could cancel it for any number of other reasons, but not for redistribution of code.
If one does not interpret the GPL this way, then it raises all sorts of problems. For example, see the hardware/support vendor example in this post: http://slashdot.org/comments.pl?sid=115310&cid=976 7498
Yes, but they were under an obligation to provide you updates under the $20 subscription. They remove the right to updates on update of the source.
Consider the following scenario (that I posted elsewhere):
IBM (or whomever) sells someone a system with a three year support contract. The system includes some custom versions of GPLed programs (not originally written by IBM). By your interpretation, IBM could put a clause in their contract that says that if you redistribute the modified versions of the GPLed programs, IBM can terminate your support contract and take back the hardware. Support and hardware are not covered by the GPL right? Those are separate rights that are being restricted (for actions you take with the programs). Once that hole is open, it is open wide enough to drive a truck through it.
You are correct that the GPL doesn't require updates. However, by linking getting updates with not redistributing the programs, they are still violating the GPL. Once they distribute the program, they cannot restrict its distribution in any way. Cancelling an existing agreement is a restriction.
Note: if Sveasoft stopped offering updates to *everyone*, that would be fine with the GPL. However, they can't selectively refuse them to those who redistribute the program.
There are other issues here. For example, they have stopped distributing the source with the binaries. As a result, they shift from section 3a (which covers packages that include the source with the binaries) of the GPL to section 3b (which covers binary only distributions). With 3a, they only have to give the source to those who receive the binary; with 3b, they have to provide the source to anyone who asks. Further, they are charging $50 for the source distribution, which would seem to violate the requirement that they only charge enough to cover their distribution/media costs ($10 is high for a CD plus shipping).
No, if Sveasoft (or whomever) gives you a copy of the binary without the source, then they must make the source available to anyone who asks, as per section 3b of the GPL.
Your scenario only works if they gave *you* (and everyone else to whom they distributed the binary) the source as well as the binary (this is section 3a). If they only give the binary, then I can ask them direct for the source (back to 3b). Further, I do not have to prove that I obtained the binary to be able to force them to supply the source if they did not provide the source with the binary (an offer to supply the source is not enough; the two must actually go together in the same package).
Yes, but that right is being terminated *for* redistribution. The GPL doesn't provide any right to updates, but it does demand that there not be any restrictions on source redistribution. Its the link between redistribution and termination of the subscription that is not allowed. The subscription could be terminated for any number of unrelated reasons without violating the GPL, but this reason is a problem.
Consider the following scenario:
IBM (or whomever) sells someone a system with a three year support contract. The system includes some custom versions of GPLed programs (not originally written by IBM). By your interpretation, IBM could put a clause in their contract that says that if you redistribute the modified versions of the GPLed programs, IBM can terminate your support contract and take back the hardware. Support and hardware are not covered by the GPL right? Those are separate rights that are being restricted (by actions you take with the programs). Once that hole is open, it is open wide enough to drive a truck through it.
"You are then free to redistribute that source, but doing so bans you from receiving libGPLfoo.so.2"
This violates the GPL. They can *not* link the ban to source/binary distribution. They can ban you for various other reasons, just not for redistributing the source. They were under no obligation to provide libGPLfoo.so.2 under the GPL, but they sold it as part of their subscription. They cannot then remove that right or privilege if you distribute the source, as this is an added restriction on redistribution.
It was a nice try at GPL evasion, but I don't think that it will fly. If it does, the next version of the GPL will contain a few "fixes."
If Sveasoft (or anyone) transfers a GPLed binary to you without transferring the source at the same, then they must offer the source for free to *anyone* who requests it (as they might have received the binary from you). They appear to be violating this.
Sveasoft may not penalize you in *any* way for redistributing the source (or binary). Even though the login info had nothing to do with the GPL previously, revoking it for redistributing the source is a violation of the GPL (you can revoke for any number of other reasons freely, just not for redistributing the source).
Sveasoft could charge $50 for the source, but they can't charge $10 for the binaries and then charge $50 to get the source (the amounts are irrelevant). Once they distribute the binaries, they must give source access.
Your numbers are off. There are roughly two hundred spammers (not thousands). Most are located in the US (although they use relays from outside the US). Those who are not collect money in the US (at least those who send spam in the US do). Thus, they are reachable in the US...or at least their money is. Even if the spammer walks free, they aren't going to continue to spam if they can't get paid.
"Automatic filters will block messages where the sender's domain doesn't match the IP only if you set it to do so. It's not always safe to assume that a mis-match like this means spam."
Actually, the way the filter works is it looks for various common spam characteristics and only blocks if several are met. This just happened to be what put it over the edge. Further, it is worth pointing out that I don't configure the filter...the mail server administrator does. As I pointed out elsewhere in this thread, mail administrators do not always accept email just because it might be legitimate.
"If I had a domain hosted as a virtual domain sharing an IP with similar domains there'd be no way for me to do otherwise."
There is no reason why multiple domains can't share the same IP or even IPs. The DNS looks ugly but is not impossible.
"robbing someone with a gun is somehow more punishable than without a gun."
I won't talk about the others, but this is sensible. Using a gun greatly increases the chances that the robbery will end up in injury to someone other than the robber (and probably increases the robber's chance of injury as well, but who cares).
Compare to drunk driving laws: being drunk is not illegal; driving is not illegal; driving while drunk is illegal for the same reason as robbing with a gun--it greatly increases the chances of someone getting hurt.
I think that people are missing the real point of this law. Previously, it was illegal to play a "pirated" disc on your console; however, it was difficult to catch someone *while* playing the disc. With this law, you don't have to catch them "in the act." It is sufficient to catch them with the equipment to commit the act. It's not so much to pile on the sentences as to make a sentence possible at all. It is much easier to prove possession of a mod chip than use.
Open relay blacklists are flawed (they reject legitimate mail) but still obtained wide use. I remember back in 2001, the mail server that I helped administer was blacklisted because it would relay mail for a departmental mail server that was an open relay. Were we able to ignore ORBS? No, a football coach was unable to send email to one of his correspondents, so we had to make the department fix its mail server. We weren't offered the luxury of saying that it was the receiving mail server's fault for blocking us based on dubious information (and we weren't allowed to blacklist the departmental mail server, which was my suggestion).
Microsoft and AOL have already agreed to support SPF. In fact, from http://spf.pobox.com/adoption.html "AOL is also currently requesting all of their whitelist partners to switch to SPF to remain on their whitelist." Perhaps you can afford to not send email to AOL addresses, but I (and many others) can't.
Automatic checkers (SpamAssassin, SPF) read the headers (and block the message) *before* you determine that it's a legit message. The end user still won't know the difference...but they won't read your message either.
I've found mail in my SpamAssassin junk box that did essentially what you describe. It's the wrong way to do it, and the recent trend of aggressive spam blocking by AOL, HotMail, Yahoo, etc. is soon going to make it an unsuccessful way in the near future.
There is substantial prior art on updating over networks without HTML (Debian's apt, GNU Stow, and the older programs on which they were based come to mind). Given that many people were converting programs from custom interfaces to an HTML interface (well before this patent), combining the two *is* obvious. To be non-obvious, it would have to do some particularly insightful thing as part of the implementation. However, like most software patents, it doesn't include a real implementation (implementations are the only things that are patentable, not ideas or theories).
Also, what long time between the patent and when MS and Apple started using a similar system? Most of the patent claims are from 2000, roughly the same time as MS was implementing its system. It's not out of the range of possibility to say that the claims were added because Microsoft's system was accomplishing them.
Microsoft's monopoly status would make it difficult for them to enforce such patents if they owned them. Looking at the SCO case, it's more likely that they would find a patsy to act for them (e.g. BayStar). Think about it. If Microsoft owned SCO...
"but when I send mail on that address it goes through my ISP's SMTP server."
That's the wrong way to do it. You should be using SMTP Auth over port 587 to connect to a mail server for your actual domain instead. SPF will make your life much more difficult unless you make this switch.
The only reason to turn on port 25 is to run your own mail exchanger. Unfortunately, most ISPs don't have the ability to turn ports on or off on a per IP (or better: per MAC) basis. They block too far up. Thus, "off by default" is not possible for most ISPs; they can either turn off or on for *everyone*. Thus the author's suggestion to put blocking at the cable modem level, so it will be per connection.
Why rate limit? Just shut off the port altogether. Unless they are running a mail exchanger, cable/DSL users should not be using port 25; they should use SMTP Auth over port 587 instead. If they are running a mail exchanger, then that person should have the port open for as much traffic as they need.
Slashdot Mirror
"I can't see why they could not supply soldiers with some non-hydrated calory-rich stuff like M&Ms instead."
They need water more than they need calories. It takes a long time to die from lack of calories. One can die from lack of water in a few days.
http://spftools.infinitepenguins.net/register.php
It also adds you to the adoption list. There are a couple more at the bottom of http://spf.pobox.com/faq.html
SPF also says that they will have their own at http://spf.pobox.com/certification.html
The SSL connection with authentication should not be made over port 25. Port 25 is for standard (non-SSL, non-Auth) connections. While it might accept the other connections, it is not the preferred port for this.
The big change that might need to be made is to support SMTP Auth over port 587. However, I suspect that they already do this (its part of the SSL/Auth setup). This should just be a matter of changing client configuration to go there. No VPN needed.
They can't reduce the clauses of the GPL (which prohibit restriction of redistribution) by separate agreement. If they could, they could just make a separate agreement (for anything) with you that said, "We distributed the software under the GPL, but if you exercise your GPL rights (of modification or redistribution), you must pay us one billion dollars."
The kind of clause you mention would put the burden on you to prove that the cancellation was distribution related, but if you could, they could not redistribute software under the GPL anymore (just like SCO).
Employment also has that "at will" clause, but you still can't terminate because of someone's race.
Your missing the point. If I lose something because I redistributed, then I am restricted from redistributing. Yes, I can accept the loss and redistribute, but this is not freedom. It's like saying that you are free to distribute drugs in the US; you just go to jail afterwards. Or a better analogy would be if you could go to jail for criticizing the President. That's not free speech; this isn't free software.
You may be correct and the current license would not regard this as a restriction. That's a legal issue. I disagree (based on my interpretation of the word restriction), but your interpretation could certainly be correct, IANAL. My point is that this should *not* be allowed under the GPL. If it is, then the GPL is toothless.
The fact that the loss is of updates (which aren't and shouldn't be covered by the GPL) is irrelevant. My water company can't (or at least shouldn't be able to) turn my water off for redistributing GPLed programs and still distribute GPLed programs itself either.
"Look at it a different way, would you be "ok" with this described situation if it wasn't a GPL program?"
Sure. I might not like it, but it would probably be legal (note: those agreements don't always hold up in court; consumers have various fair use rights that can negate them). Note that I'm not arguing that support should be required for modified code (or refrigerators). That agreement *is* entirely separate. What I'm saying is that if you buy two refrigerators and resell one, that doesn't mean that you lose support on your first refrigerator. I'm not sure if that (losing support for this unit based on sale of another unit) would hold up in court on the face of it; I'm positive that it wouldn't be compliant with a license that had similar clauses to section 6 of the GPL.
The issue is that software allows exact copies. If I could buy one refrigerator, copy it, and still have the original refrigerator, I would expect support on the original refrigerator (I wouldn't expect anything for the copy). With software, you buy an infinite number of identical units. Under the GPL, you can redistribute as many of them as you want *without added restriction*. Removing upgrades or other forms of support from you because you redistributed is certainly not within the spirit of the GPL, and I don't believe that it is within the letter either.
"Why can't they selectively refuse updates?"
They can. They just can't selectively refuse updates because someone redistributed the source. It's not selectively refusing updates that is the problem; it's linking it to source redistribution that causes the conflict.
Another analogy. The GPL doesn't oblige you to distribute your program for free. Why can't you collect $10 every time someone else redistributes the program? It's the same clause in the GPL: charging for redistribution is a restriction; cancelling their update privileges *as a result of distribution* is a restriction on distribution.
Or look at the original Linksys issue. Sveasoft would not currently have the code if Linksys had said that anyone who distributed the code had to return their Linksys hardware. As soon as Sveasoft had distributed their first beta, by your logic, Linksys could have reposessed their hardware (the GPL doesn't oblige you to offer hardware after all). Sveasoft would have had to stop development without hardware for testing.
If this stands, it is a gaping hole through the GPL. Just bundle your GPLed program with anything. If they utilize their GPL rights, they lose the other part of the bundle.
You need to read http://www.fsf.org/licenses/gpl-faq.html#WhatDoesW rittenOfferValid or section 3b of the GPL. I've quoted it elsewhere in this same thread, so I won't quote it again.
If they do not distribute the source with the binary, they must offer it to *anyone* under the same terms as they offer it to people to whom they distributed the binary.
"Now under the terms of the license for access to the server they can cancel your server account if you redistribute."
It's still a restriction on *distribution* which they can't do and be complying with the GPL. The fact that the FTP server access is separate from the GPL is irrelevant. There is nothing in the license saying that the distribution restriction clause only applies to the GPL agreement. As I read it, the clause prevents them from restricting distribution in *any* agreement they might make. Again, the FTP server access could be restricted based on all sorts of other reasons without invoking the GPL. By bringing up the GPLed redistribution though, the separate agreement invokes (and conflicts with) the GPL.
The third party clause can't be good just once. If you receive the binary under 3b and redistribute to to two people, then it must be good for *each* of them. The two can be generalized out to any number. Further, the two can each redistribute under 3c. Once the company does not comply with 3a (distribute the source with the binary), it's stuck giving the source to anyone who requests it. Once they have distributed to a particular person, they might not have to distribute to that particular person again; however, they would still have to give the source to any new person who asked.
IANAL either, but please reread the 3b that you posted, where it says "any third party." Anyone can request the source and it must be provided (for no more than media/distribution cost) if it was not provided originally (3a). 3c does not apply to Sveasoft, just to those who distribute binaries from Sveasoft that they originally obtained under the terms of 3b (3c says they must pass on the source code offer). Sveasoft both modified the source and provided the binary commercially.
This one ( http://www.fsf.org/licenses/gpl.html ):
6 7498
* b) Accompany it with a written offer, valid for at least three years, to give any third party, for a charge no more than your cost of physically performing source distribution, a complete machine-readable copy of the corresponding source code, to be distributed under the terms of Sections 1 and 2 above on a medium customarily used for software interchange; or,
-----
If they do not provide the source with the binary (which is what 3a covers) and modified the original source code (section 3c covers unmodified binaries for non-commercial use; they would also get caught on the non-commercial use), then they must do b (and they currently do not seem to be). Note the "any third party" clause. That is the same as "anyone," which is what I said.
They are certainly allowed to charge any price they wish for the initial transfer and any warranty they may provide. Afterwards however, they can't charge more for the source, as the distribution cost has already been set. (I said that they needed to offer the source for free, but that is incorrect, they can charge a media/distribution charge.) They can't claim that they can distribute multiple binaries for $20 but that it costs $50 to distribute a single copy of the source code. It's an absurd claim.
In section 6, the GPL says, "You may not impose any further restrictions on the recipients' exercise of the rights granted herein." Revoking the right they bought to get updates does this if you do it *because* they redistributed the program. They could cancel it for any number of other reasons, but not for redistribution of code.
If one does not interpret the GPL this way, then it raises all sorts of problems. For example, see the hardware/support vendor example in this post: http://slashdot.org/comments.pl?sid=115310&cid=97
Yes, but they were under an obligation to provide you updates under the $20 subscription. They remove the right to updates on update of the source.
Consider the following scenario (that I posted elsewhere):
IBM (or whomever) sells someone a system with a three year support contract. The system includes some custom versions of GPLed programs (not originally written by IBM). By your interpretation, IBM could put a clause in their contract that says that if you redistribute the modified versions of the GPLed programs, IBM can terminate your support contract and take back the hardware. Support and hardware are not covered by the GPL right? Those are separate rights that are being restricted (for actions you take with the programs). Once that hole is open, it is open wide enough to drive a truck through it.
You are correct that the GPL doesn't require updates. However, by linking getting updates with not redistributing the programs, they are still violating the GPL. Once they distribute the program, they cannot restrict its distribution in any way. Cancelling an existing agreement is a restriction.
Note: if Sveasoft stopped offering updates to *everyone*, that would be fine with the GPL. However, they can't selectively refuse them to those who redistribute the program.
There are other issues here. For example, they have stopped distributing the source with the binaries. As a result, they shift from section 3a (which covers packages that include the source with the binaries) of the GPL to section 3b (which covers binary only distributions). With 3a, they only have to give the source to those who receive the binary; with 3b, they have to provide the source to anyone who asks. Further, they are charging $50 for the source distribution, which would seem to violate the requirement that they only charge enough to cover their distribution/media costs ($10 is high for a CD plus shipping).
No, if Sveasoft (or whomever) gives you a copy of the binary without the source, then they must make the source available to anyone who asks, as per section 3b of the GPL.
Your scenario only works if they gave *you* (and everyone else to whom they distributed the binary) the source as well as the binary (this is section 3a). If they only give the binary, then I can ask them direct for the source (back to 3b). Further, I do not have to prove that I obtained the binary to be able to force them to supply the source if they did not provide the source with the binary (an offer to supply the source is not enough; the two must actually go together in the same package).
Yes, but that right is being terminated *for* redistribution. The GPL doesn't provide any right to updates, but it does demand that there not be any restrictions on source redistribution. Its the link between redistribution and termination of the subscription that is not allowed. The subscription could be terminated for any number of unrelated reasons without violating the GPL, but this reason is a problem.
Consider the following scenario:
IBM (or whomever) sells someone a system with a three year support contract. The system includes some custom versions of GPLed programs (not originally written by IBM). By your interpretation, IBM could put a clause in their contract that says that if you redistribute the modified versions of the GPLed programs, IBM can terminate your support contract and take back the hardware. Support and hardware are not covered by the GPL right? Those are separate rights that are being restricted (by actions you take with the programs). Once that hole is open, it is open wide enough to drive a truck through it.
"You are then free to redistribute that source, but doing so bans you from receiving libGPLfoo.so.2"
This violates the GPL. They can *not* link the ban to source/binary distribution. They can ban you for various other reasons, just not for redistributing the source. They were under no obligation to provide libGPLfoo.so.2 under the GPL, but they sold it as part of their subscription. They cannot then remove that right or privilege if you distribute the source, as this is an added restriction on redistribution.
It was a nice try at GPL evasion, but I don't think that it will fly. If it does, the next version of the GPL will contain a few "fixes."
If Sveasoft (or anyone) transfers a GPLed binary to you without transferring the source at the same, then they must offer the source for free to *anyone* who requests it (as they might have received the binary from you). They appear to be violating this.
Sveasoft may not penalize you in *any* way for redistributing the source (or binary). Even though the login info had nothing to do with the GPL previously, revoking it for redistributing the source is a violation of the GPL (you can revoke for any number of other reasons freely, just not for redistributing the source).
Sveasoft could charge $50 for the source, but they can't charge $10 for the binaries and then charge $50 to get the source (the amounts are irrelevant). Once they distribute the binaries, they must give source access.
"Very few spammers are reachable legally."
Your numbers are off. There are roughly two hundred spammers (not thousands). Most are located in the US (although they use relays from outside the US). Those who are not collect money in the US (at least those who send spam in the US do). Thus, they are reachable in the US...or at least their money is. Even if the spammer walks free, they aren't going to continue to spam if they can't get paid.
"Automatic filters will block messages where the sender's domain doesn't match the IP only if you set it to do so. It's not always safe to assume that a mis-match like this means spam."
Actually, the way the filter works is it looks for various common spam characteristics and only blocks if several are met. This just happened to be what put it over the edge. Further, it is worth pointing out that I don't configure the filter...the mail server administrator does. As I pointed out elsewhere in this thread, mail administrators do not always accept email just because it might be legitimate.
"If I had a domain hosted as a virtual domain sharing an IP with similar domains there'd be no way for me to do otherwise."
There is no reason why multiple domains can't share the same IP or even IPs. The DNS looks ugly but is not impossible.
"robbing someone with a gun is somehow more punishable than without a gun."
I won't talk about the others, but this is sensible. Using a gun greatly increases the chances that the robbery will end up in injury to someone other than the robber (and probably increases the robber's chance of injury as well, but who cares).
Compare to drunk driving laws: being drunk is not illegal; driving is not illegal; driving while drunk is illegal for the same reason as robbing with a gun--it greatly increases the chances of someone getting hurt.
I think that people are missing the real point of this law. Previously, it was illegal to play a "pirated" disc on your console; however, it was difficult to catch someone *while* playing the disc. With this law, you don't have to catch them "in the act." It is sufficient to catch them with the equipment to commit the act. It's not so much to pile on the sentences as to make a sentence possible at all. It is much easier to prove possession of a mod chip than use.
Open relay blacklists are flawed (they reject legitimate mail) but still obtained wide use. I remember back in 2001, the mail server that I helped administer was blacklisted because it would relay mail for a departmental mail server that was an open relay. Were we able to ignore ORBS? No, a football coach was unable to send email to one of his correspondents, so we had to make the department fix its mail server. We weren't offered the luxury of saying that it was the receiving mail server's fault for blocking us based on dubious information (and we weren't allowed to blacklist the departmental mail server, which was my suggestion).
Microsoft and AOL have already agreed to support SPF. In fact, from http://spf.pobox.com/adoption.html "AOL is also currently requesting all of their whitelist partners to switch to SPF to remain on their whitelist." Perhaps you can afford to not send email to AOL addresses, but I (and many others) can't.
Automatic checkers (SpamAssassin, SPF) read the headers (and block the message) *before* you determine that it's a legit message. The end user still won't know the difference...but they won't read your message either.
I've found mail in my SpamAssassin junk box that did essentially what you describe. It's the wrong way to do it, and the recent trend of aggressive spam blocking by AOL, HotMail, Yahoo, etc. is soon going to make it an unsuccessful way in the near future.
There is substantial prior art on updating over networks without HTML (Debian's apt, GNU Stow, and the older programs on which they were based come to mind). Given that many people were converting programs from custom interfaces to an HTML interface (well before this patent), combining the two *is* obvious. To be non-obvious, it would have to do some particularly insightful thing as part of the implementation. However, like most software patents, it doesn't include a real implementation (implementations are the only things that are patentable, not ideas or theories).
Also, what long time between the patent and when MS and Apple started using a similar system? Most of the patent claims are from 2000, roughly the same time as MS was implementing its system. It's not out of the range of possibility to say that the claims were added because Microsoft's system was accomplishing them.
Microsoft's monopoly status would make it difficult for them to enforce such patents if they owned them. Looking at the SCO case, it's more likely that they would find a patsy to act for them (e.g. BayStar). Think about it. If Microsoft owned SCO...
"but when I send mail on that address it goes through my ISP's SMTP server."
That's the wrong way to do it. You should be using SMTP Auth over port 587 to connect to a mail server for your actual domain instead. SPF will make your life much more difficult unless you make this switch.
The only reason to turn on port 25 is to run your own mail exchanger. Unfortunately, most ISPs don't have the ability to turn ports on or off on a per IP (or better: per MAC) basis. They block too far up. Thus, "off by default" is not possible for most ISPs; they can either turn off or on for *everyone*. Thus the author's suggestion to put blocking at the cable modem level, so it will be per connection.
Why rate limit? Just shut off the port altogether. Unless they are running a mail exchanger, cable/DSL users should not be using port 25; they should use SMTP Auth over port 587 instead. If they are running a mail exchanger, then that person should have the port open for as much traffic as they need.