Optimality is measured (when it is computationally possible) by precise mathematical metrics. Correctness is determined not by asthetic appeal, creativity, or insight, but by nothing more than the solution being provably correct through the employment of established mathematical techniques.
This is true only within a tiny branch of computer science, and thoroughly false for programming in general. In the real world, we deal not with the empty and valueless mathematics of pure logic, but with values which stem from our needs and desires. Many of those values are not easily amenable to logic -- such as clarity and ease of maintenance, which are subjective and arguably aesthetic values.
By "valueless" I do not mean that logic is worthless, but rather that it provides no values in itself. It is empty. Logic allows us to draw relations between sentences, for instance, but it cannot tell us if our premises are true or false -- nor if our arguments are well-written and convincing, or our conclusions admirable or vile. It likewise can tell us if our programs generate results consistent with our assumptions, but it cannot tell us if those assumptions are worth anything -- nor if anyone can stand to look at our code.
Two programs may be equally correct in the mathematical sense, but a programmer may still be correct in preferring one over the other. Mathematical equivalence does not mandate indifference. (Indeed, this is true of pure mathematics as well as programming -- mathematicians can recognize two proofs of the same theorem as equivalent, but agree that one is elegant and the other a mess of kludges.)
There are all sorts of values besides strict mathematical correctness which go into judging the optimality of a program. Correctness is necessary, of course, but it is by no means sufficient. When others must read it, a program's clarity is valuable, as is its self-descriptiveness. (The statements x += 60; and seconds_till_alarm += 60; are mathematically equivalent, but one is to be preferred in certain contexts.) Likewise we may appreciate a particular method used, a turn of phrase as it were, which may make the program neither more correct nor more efficient, but more fitting to the way people think about the problem domain.
Is a program poetry? No, not usually. People do, after all, write programs for their effects when run. However, by no means are these the only relevant considerations, any more than the logical validity of the arguments made by a public speaker be the only consideration in whether the speech was good or bad -- or laudable or ignoble.
Please, please don't bounce your spam. I've been buried by emailers bouncing spam back to me that have been spoofed. Also, this kind of bouncing significantly increases bandwidth usage.
I was unclear. A blocking system does not accept the message, then generate a bounce message back to the apparent sender -- the behavior you are describing. Rather, a blocking system rejects the message during the SMTP transaction, with an error code. It is then up to the sending system to handle the error, which may lead to the sending of a bounce message.
It is bad behavior for an MTA to accept in the SMTP transaction a message which it knows it will not attempt to deliver -- for instance, to accept a message from a known spam source and then delete it. This is because SMTP operates on an assumption of best effort: when an MTA accepts a message, it is agreeing to do its best to deliver that message. Saying that you will try to deliver when you know you won't is dishonest, and leads to problems -- such as the spurious bounces you describe.
Generally, spammer software is unable to handle SMTP error codes, and does not generate bounce messages anyhow. However, legitimate MTAs do handle error codes and generate bounce messages when real mail is not deliverable. By using blocking techniques (and sending error codes) one does the right thing both with spam and with the occasional false positive: the spam is simply rejected, rather than bounced to a forged sender; and the legitimate message is returned as undeliverable.
Most spam is sent through compromised machines (check the millions infected with SOBIG for details) or through open proxies. There is no way to track these fuckers down.
Sure there is. After all, many of the spammers who use these open proxies are being tracked down and documented in ROKSO, part of the Spamhaus Project. However, this tracking does require using resources other than just header analysis and traceroute.
The investigators use methods more akin to a private detective's or law office's methods than to a network administrator's. For instance, they follow the money. The majority of spam messages are trying to sell something, so they need an avenue to collect payments. Or they use public records: many spam messages flog Web sites, which may well have spurious whois contact information, but are registered in the name of a legally-established corporation or LLC. (Spammers incorporate for the same reason anyone else does: when they get sued, it protects their personal assets.) In this case, the investigators can go to the state corporations records. These are public records, which list the officers of the corporation -- in other words, the spammers.
Take a look at the ROKSO records for any major spammer, like Eddy Marin or Ronnie Scelson. ROKSO records are compiled entirely from public information -- corporate records, legal filings, domain registrations, and so forth. They also represent a tremendous amount of work on the part of Steve Linford, Shiksaa, and other investigators. Tracking spammers is not necessarily something you can do from your xterm, but it is possible, and it is being done.
According to RFC 821 (sections 4.3 and 4.2.2), the server can respond to new connections in with a 220 ("let's dance") or a 421 ("go away, I have a headache") response. Not a 554 ("you're lousy in bed") code.
You're citing an out-of-date RFC. 821 was superseded by RFC 2821, which makes it clear that 554 is a valid connection-opening response, to indicate that mail service is not available. (Indeed, 2821 spells out two codes for use at connection establishment -- 220 to accept, or 554 to reject access.) AOL is correctly using 554 to indicate that it will not provide mail service to your IP address.
A 4xx code would be improper in this case. 4xx codes indicate temporary failures. They mean that the client should queue its messages and retry them later, rather than returning a bounce message to the sender. That's not what is intended here -- the server doesn't want you to retry, it wants you to not try. A 5xx error code is correct.
I'd rather spam filtering be left to myself. Any decent e-mail client has the capability for filtering, and by doing that way, I have control over what gets thrown out and what doesn't.
There are substantial disadvantages to a client-side filtering only spam defense as opposed to a server-side blocking only defense. It is, of course, fully possible to use both; I merely wish to point out some factors you may not have considered.
For the definitions of "filtering" and "blocking", please see this Wikipedia article. Roughly, DNSBLs and Sendmail's milter feature are blocking tools -- they take effect during the SMTP transaction. Client-side tools are filtering tools -- they take effect when you check your mail.
Consider:
Client-side filtering destroys false positives rather than bouncing them. Any spam defense can have false positives, in which non-spam email is incorrectly classed as spam. When a mail server doing blocking experiences a false positive, it returns an SMTP error to the sending system. Ultimately, the human sender sees a bounce message, which indicates that their message did not make it to the intended recipient. The sender can then attempt to get around the block (by sending from another site) or can try to contact the recipient by other means. However, when a client-side filter has a false positive, the mail is either deleted or filed in a rarely-seen "spam folder". The sender gets no notification that it will not be seen (or not seen promptly). Since false positives do happen, it is better that they not happen silently!
Client-side filtering isolates and hides useful information. A mail site, particularly a large one such as AOL, is in a position to gather a great deal of information about spam sources and patterns. Users complain about receiving spam. If a site can cause these complaints to be expressed in a useful way (such as sending full headers to an abuse address) rather than a useless one (such as cussing out the helpdesk), the site can aggregate a huge amount of information about spam offenders, which can be used to the whole site's spam defenses (or to mount litigation or prosecution of spam offenders). In contrast, your client-side filtering is informed chiefly by your own experience, and has no access to the experience of the other bazillion people on your ISP or mail site.
Client-side filtering doesn't alleviate large mail sites' resource problems. A site such as AOL dedicates significant amounts of disk space, backup capacity, and network bandwidth to email. Since over half of AOL's incoming email is spam, if AOL did no blocking then it would probably spend over twice as much money on these resources than it would on a spamless Internet. In client-side filtering, mail must be delivered to the user's mailbox on disk, and the user must then check his mail, before any spam is removed from disk. If that spam were blocked at SMTP time, however, it would never have occupied AOL's disk and never consumed those resources.
However, as I mentioned above, it is possible to combine blocking and filtering in useful ways. A mixed strategy is what I prefer for my own site: we use a number of blocking strategies (such as DNSBLs and regular-expression patterns matching common spam elements), but we also use SpamAssassin and encourage users to filter with its scores or other criteria.
4) The author encourages the reader to use a computer to enter, run and debug the book's programming examples. I concur with this advice, though it isn't absolutely necessary.
I remember the first edition of Practical C++ Programming. Readers who wished to get something out of that book should've noticed that it was absolutely necessary to debug the book's programming examples first.
That is a lot of questions but the essence is "What happens when one breaks the GPL, unrepentantly?"
It is less than accurate to say that one can break or violate the GPL, since the GPL is neither a law nor a contract: it is a limited grant of permission. One cannot violate it like a contract, but one can exceed the bounds of the permission granted. If one does so, one is infringing upon copyright: one is violating copyright law. In the case of a registered copyright, such violation carries statutory damages.
Consider: Suppose that we lived in a society with strict and unforgiving trespassing laws: anyone who walks on another's land without permission is both guilty of the crime of trespassing, and liable to the landowner for statutory damages.
Under this regime, Fred grants Barney permission to walk across his front lawn, but not his back lawn. This is a limited permission: it spells out what Barney may do which he otherwise mayn't, and also clearly notes what he still mayn't do. (Likewise, the GPL spells out that one may copy and distribute with source, but not without.)
If Barney strays, and walks across Fred's back lawn, is he in violation of the Fred Lawn-Walking License? No, not at all. He is simply in violation of the trespassing laws, for he has no permission to cross Fred's back lawn. The fact that he does have permission to cross the front does not militate against his conviction and liability: he took an action (crossing Fred's back lawn) which requires permission, which permission he did not have.
To bring the matter back to SCO: SCO, and other Linux distributors, do not contract with Linux and Samba authors under the GPL. It is not a contract; thus, it may not be violated. Rather, the GPL is the instrument by which the Linux and Samba authors grant SCO and others permission to do something they otherwise would be forbidden from doing: copying and redistributing Linux and Samba.
When a distributor strays beyond the bounds of that permission -- for instance, by distributing binaries and refusing to distribute source; or failing to distribute derivative works under the same license as the original -- the distributor is a common copyright violator. The very same laws that make Joe College liable for running off copies of the RIAA's favorite tunes, make the infringing distributor likewise liable.
That's copyright. Copyright law is about obtaining permission from authors before you may copy and redistribute their works. That permission needn't be in the form of a contract, and indeed in the case of GPL works it is not. A distributor who "violates the GPL" by failing to distribute sources is overstepping the bounds of their permission -- and is, in the vulgar argot, a software pirate.
The GPL expressly disclaims covering a "freedom to use", stating rather the following:
Activities other than copying, distribution and modification are not covered by this License; they are outside its scope. The act of running the Program is not restricted...."
What does this mean? Not only does the GPL provide authors no handle by which to prevent someone from using the covered code, it also presumes that a user does not need additional permission from the copyright holder to use a copy which is legitimately obtained. If you buy a copy of a work, it becomes your property and you may use it; you need permission and licensure only when you wish to make and distribute copies.
The scammers behind proprietary licenses have come up with all sort of language to mask this fact: "licensed, not sold"; "you own the media, not the work"; and so forth, as if it were possible to deprive someone of a purchase retroactively by declaring it to have not taken place. (It isn't; if you walk into a store, and the store's staff and you carry out the overt ritual of selling and purchasing a given item, then you have purchased the item, even if a paper inside the box describes it as "licensed, not sold". Naturally, you have not purchased the copyright, but the copy you have purchased is yours to use or abuse.)
Vice versa, there is no way that SCO's post facto claims that the GPL is worthless can cause the GPL to be worthless to SCO. They may rail against it for years, and it will still be sufficient to grant them the right to copy and distribute binaries and source together. You can waive many sorts of right merely by saying you do, but the GPL isn't such a right. Rather, it is a grant of permission, which remains efficacious even if you deny it. No matter how much SCO says, "The GPL is worthless," they still have and hold the rights granted them under it.
Additionally, recently Debian has decided that the GNU Free Documentation License isn't free enough for them, and that therefore many GNU manuals have to go to non-free. If this isn't a huge holier-than-thou contest, I don't know.
From what I can tell, RMS sees these things in terms of abstract principles, whereas Debian sees them as guarantees that it can offer its users and society at large. Hence RMS comes off sounding "religious" to some, while Debian hies to a document it calls its "Social Contract".
Because it's in the business of offering assurance to its users that they will be able to redistribute and modify the packaged software, Debian has to be exceedingly careful of license conflicts and the like. They took a good deal of heat for excluding KDE until Qt's license ceased to conflict with the GPL. (It's a myth, by the way, that Debian demanded Qt be GPLed. In fact, the problem was that while KDE components were GPLed and Qt's license was also Free, Qt's license and the GPL on KDE could not be simultaneously satisfied.)
The difficulry arises with the GNU FDL because people can add sections called "Invariant Sections" to covered documents. These are portions excluded from the freedom of the license -- portions which future maintainers may not modify. Debian guarantees that the materials you get from its mainline distribution are things you may modify, so obviously Debian can't include FDL Invariant Sections in its mainline distribution.
It isn't a matter of fanaticism, advocacy, or holiness. It's a matter of plain and simple contradiction: Debian can't give something away as freely modifiable software if its license says it isn't -- and an FDL Invariant Section is no more freely modifiable than is Microsoft Word.
If someone says, "I'm making a CD of software that's all BSD-licensed," then obviously they aren't going to include gcc in it. Calling them fanatical or "holier-than-thou" for simply keeping their word, makes you seem to be fanatically advocating hypocrisy and deceit.
What's next, neurosurgeons complaining that patients don't know as much as them? Of course end users don't know much about tech - that's what they're paying support workers for! Just like drivers pay auto mechanics, and anyone who has a bathroom pays a plumber.
Let's not confuse the roles of a repairman and an instructor, both of which can come into play in technical support. The repairman is paid to come in, fix something, and leave. You don't care how the Roto-Rooter guy cleans out your pipes, or what goes into the tar-paper the roofer uses to repair your leaking roof. However, when you call technical support and ask how to do something, you are not asking for repair -- you're asking for instruction. You are asking to be taught: perhaps only to be taught a specific, limited task (like defragging your hard drive, or getting your cable modem to sync) -- but this is still very different from asking for repair.
Repair doesn't involve your understanding or acceptance -- just get out of the way and let the repairman do his job. However, teaching doesn't work that way. In order to learn, you must be receptive -- willing to learn. You must already know the prerequisites to whatever it is you're being taught. And you must not willfully resist instruction -- as by being impatient, calling your teacher rude names, or demeaning the subject at hand: "I don't need to know what a hard drive is, I'm not some kind of nerd. Just tell me what to do to maaake it goooo!"
Think about the question you are asking the tech-support guy. Whenever that question begins with "How do I... ?" you are asking to be taught. Make sure that you are ready to be a good student.
Then why does almost everything Linux do (and I'm talking about the larger scope of Linux, not just the kernal) attempt to emulate Windows?
This is exactly the sort of thing I was referring to, actually. There are small portions of Linux systems where the designers have attempted to follow Windows or Macintosh GUI designs in order to make life easier for new adopters. However, because the Windows user is focused on the GUI and considers it to represent the sum-total of the software system, these small parts' importance is exaggerated. They look bigger than they are -- and consequently, make the real system look smaller and weaker -- precisely because that is what you expect.
You see these components as failing to meet your Windows-based expectations because they are so often thin imitations. The Windows user who looks for these thin, artificial correspondences to Windows features is like the tourist who doesn't understand the language of the foreign city he is in, and relies upon a phrasebook. Naturally his speech seems stilted to the native speaker, and his understanding limited -- he is using an artificial set of correspondences which don't really map that well to the native way of speaking and thinking.
Here's an example a coworker and I thought of this morning while discussing this problem with regards to a client of ours who is moving from Windows to Linux rather slowly: What is the natural way, on Windows and then on Linux, to copy all the.txt files in a directory, to a directory on another host? How does the Windows user come up with a solution to this problem? What's the shallow phrasebook "translation" of that solution in Linux, and how does it compare to the "native speaker"'s equivalent?
Here's what we came up with:
Windows: Open Windows Explorer on the source computer. Enter the share name of the destination directory on the destination host, e.g. \\DESTHOST\DEST\PATH. Open the source directory. Sort the source directory by file type, select all the text documents, and drag them to the destination directory.
"Phrasebook" Linux translation: Open a GUI file browser, such as Nautilus or Konqueror. Enter the URL for the destination directory on the destination host, e.g. smb://desthost/dest/path/. Open the source directory. Sort the source directory by file type, select all the text documents, and drag them to the destination directory.
"Native" Linux translation: Express the source and destination directories as pathnames, and the list of files to be copied as the wildcard *txt. Use OpenSSH's scp command to copy the files, e.g. scp/source/path/*txt desthost:/dest/path/.
Now, I will guarantee you that the phrasebook translation on Linux is much less reliable than the original Windows instructions. Why? Because the software components it relies on are those thin imitations I mentioned. The file browsers in Nautilus and Konqueror, and the SMB access libraries underneath, aren't native functionality in Linux -- they're mock-ups of the Windows way to do things. They certainly aren't how a "native Linux speaker" is likely to do it. (They can also a bloody pain to set up if your SMB network is weird.)
In contrast, I can assure you that the "native" Linux translation accomplishes the very same job -- copying some files to the very same destination -- and will do so far more reliably. It uses the "Linux-ish" (okay, "OpenBSD-ish") SSH service to do so, rather than the "Windows-ish" SMB service. It doesn't require any weird setup in advance, provided that sshd is already running on the destination host -- which it is by default on most Linux distributions, just as SMB is there by default on Windows.
(An aside: Please note that I'm not comparing the native-Windows and native-Linux ways of doing things. I'm not saying
This is a contract. Each party gets something, each party agrees to something. Given that this is a contract, and that the GPL is the very first contract of its kind, it very well may be tossed out in court. Toss out Point 2, above, and leave the rest of the GPL standing, and you've almost got a public domain declaration.
Point 2 stands, but fails to make the GPL a contract. Why? Because the licensee is not thereby giving anything to the licensor. Absent the GPL, the licensee has no right to copy and distribute the covered work. Thus, the licensee cannot give up the right to distribute copies without source -- since he does not have that right.
The default state of a work is for copyright to vest in the creator, and for nobody else to have the right to copy and distribute without the creator's permission. What the GPL grants you is the right to distribute certain kinds of copies, but not others. It grants a restricted permission to copy. That is not the same as granting you blanket permission to copy, in exchange for something else -- since in the case of the GPL, the licensee doesn't have that "something else" to offer. You can't be offering "your agreement to only distribute copies with source" -- since, absent the GPL, you don't have any right to distribute copies, with or without source.
Remember: Under copyright, all rights to copy and distribute vest with the creator, not the recipient of a copy. Two things follow from this: First, any distribution-right that the recipient has is one granted by the creator. Second, the recipient cannot give up a distribution-right that he does not have; and thus cannot give up such a right as part of a contract.
"I'll lend you my baseball, but you have to lend it to Joe if he asks" is a limited grant of permission for you to use my property. The GPL is kind of like that. You're trying to turn the GPL into something like "I'll lend you my baseball, in exchange for which, you agree not to hit me in the head with it," and call that a contract. Since you don't have any right to commit assault and battery upon me, for you to "give up" that "right" isn't consideration.
I'd like to suggest that any form of It doesn't work like Windows! is a poor example of a "Linux annoyance". Problems of this form do not represent anything wrong with Linux (and often not anything wrong with Windows, either), but rather usually differences in design between the two systems.
Trying to understand Linux as a "Windows substitute" is a doomed prospect. Their differences aren't just a matter of tradeoffs: they are radically different kinds of system, much as an MP3 player is different from a turntable. If you found two people arguing over whether an MP3 player or a turntable was "better" -- or a turntable user saying that MP3 players were "annoying" due to the lack of an RPM control -- you would of course recognize this as nonsense.
An example of this sort of difference between Linux and Windows is the difference in the handling of drives. Windows uses drive letters; Linux uses mount points in a single filesystem. While there may be advantages to each, they are more a design difference than a set of tradeoffs. Another example is the difference in balance between CLI and GUI. Windows (or, moreso, Macintosh) users who come to Linux looking for that kind of carefully tuned GUI are likely to be disappointed -- and pushing the KDE control panels on them as "almost as good" is inviting their disappointment. There is a difference in design intention between GUI-focused and CLI-focused systems. The new user just has to un-learn old assumptions, just as the turntable user needs not to be looking for an RPM switch if he wants to become familiar with the MP3 player.
Things I would describe as "Linux annoyances" are points which remain difficult, problematic, or simply grating even for the already-familiar Linux user. Many of these will sound entirely foreign to the Linux novice or non-user, since they are matters that only occur to the already-familiar. These are points which seem out of place, or insufficiently regular or predictable, even to the expert.
Some examples of what I mean:
Differences in regular expression syntax. Regular expressions are common enough, but the various programs which make use of them accept different syntax. Contrast vi's regular expressions with grep's, and those with Perl's. They are all different; can you remember which one has which features? Thankfully, most newer software that uses regular expressions (like Postfix's mail filtering) uses the Perl-compatible PCRE library, which makes life much easier.
Lack of consistent readline support. I use a lot of command-line interactive programs -- programs that aren't just run from the shell, but have their own command prompt and language. Sometimes for licensing reasons, and sometimes because the creator did not think of it, many of these programs don't use readline. This makes command entry unnecessarily bothersome. There is the rlwrap program which makes a good attempt at adding readline support, but it's still irritating to have to remember which programs need it and which don't -- especially when working on someone else's system.
Inconsistent scroll wheel support. Hey, Windows users -- this is a Linux GUI annoyance!:) Most current X11 applications that I use understand the scroll wheel and support it. Some don't. That irks.
...and they still can't make an sqlplus client that supports readline.
Have you tried rlwrap? It effectively adds readline support to command-line interactive programs that don't have it. I've used it successfully with SBCL and other relatively complicated command-lines -- so I'm going to guess it'll work with Oracle's too.
Recently, Something Awful has been having issues with the SPEWS list, a popular spam blacklister, who according to Something Awful blacklisted a whole chunk of IP addresses that happened to include their own unabused server without offering recourse or explanation simply because it had the misfortune of sharing address space unknowingly and unwillingly.
And what did the administrators of SomethingAwful do? Did they contact their ISP, whose support of spammers led to its netblocks being boycotted far and wide by other networks and mail server operators? No. Instead, they posted a solicitation for their own users (the "SA Forum Goons") to attempt to obtain the personal information of the operators of SPEWS, for the purposes of signing said operators up on spam mailing lists. They also instructed the goons to flood a spam-related USENET newsgroup with crude messages -- which was done.
In short, SomethingAwful's operators specifically encouraged criminal activities and abuse of the network. Reportedly, readers of the flooded USENET group did the right thing in response -- rather than counterattacking with a flood of their own, they reported the criminal activity to the offending user's sites (including universities). At least some of the offenders' accounts were terminated for their criminal activity. The undergrads who thought they were clever to post "fuck you goatse spam whores" a bazillion times from their university accounts won't think they are so clever when they are brought up on disciplinary charges for malicious use of university resources.
SomethingAwful deserves no sympathy. In response to a legal boycott of their ISP's network -- stemming from their ISP's willful continuing to host egregious spammers -- the owners and operators of SomethingAwful committed and advocated criminal acts. Their actions are criminal no less than the spammers' themselves.
The US Government has deemed smoking as pretty bad, yet smoking does not cause drunk driving, nor does it cause men to go home and beat their wives.
It's interesting you chose that particular slander for your post, since it was the early 20th-century equivalent of "reefer madness". One of the driving rhetorical points of Prohibitionism, and the reason that it was embraced by some elements of what became the women's movement, was just that: "Alcohol causes our responsible men to become irresponsible and beat their wives. If we get rid of booze, there will be no wife-beating!"
Naturally, it didn't work that way. Sober men are just as capable of rage as drunk ones, and neither beer nor gin can make a violent man from a peaceable one. Moreover, blaming a man's misdeeds on the drugs he consumes, rather than on his own character, does nothing to cause him to correct himself. A violent person who can excuse his behavior the next morning by saying, "It was the bottle talking," sees no reason to become less violent.
The remedy for domestic violence is not to dissuade men from drinking, but to convince them (as has thankfully been done in society at large, thanks chiefly to feminism and the law) that domestic violence is wrong, shameful, and criminal. Only by ascribing responsibility solely to the individual -- not to his drug, and not to "society" -- can the problem be corrected. Why? Simple: The booze doesn't make decisions; individuals do.
Leave beer alone, for -- as with marijuana -- the vast majority of users enjoy it responsibly. Lay the blame for wrongdoing on the wrongdoers -- and shame on you, if you let them blame it on the bottle.
Since we have the four elements of a contract: offer, acceptance, intention, and consdideration, guess that what that means? Yes, under the law we have a CONTRACT.
There is no consideration, since you are not giving the author anything he did not already have. Your "agreement" not to distribute the code in violation of the terms of the GPL does not constitute giving the author anything... since you were already obligated not to distribute it in violation of copyright law. You cannot give the author your agreement not to violate copyright law as consideration, since you had no right to violate it.
Here's a parallel: Let us say that we live in a town with strict, absolute trespassing laws, such that if I cross your property without your permission, I am guilty of trespassing. Now, let us say that you generously grant me permission to cross your front lawn, but you make it clear -- in the terms of that permission -- that I am not permitted to cross your back lawn. The permission you grant is limited, not absolute: I am allowed to do some things that would be illegal without your permission, but not others. My not crossing your back lawn is not a consideration that I give to you, because it was not a right I possessed in the first place!
A more blatant parallel: "If you give me twenty bucks, I will not shoot you." This is not an offer of contract, since I have no right to shoot you. To claim that the software recipient gives the author consideration in "accepting" the GPL is to claim that the recipient means, "If you give me this software, I will not violate copyright law upon it." That's not consideration.)
The GPL is not a contract. It is a grant of permission. Copyright says, "You may not copy without the author's permission." (Note, it doesn't say that permission has to be in the form of a contract -- it can be in the form of a unilateral grant of permission.) By placing a work under the GPL, the author says, "You have my permission to copy, but only in certain ways." The default condition -- lack of permission, hence normal copyright law -- applies if you violate those terms.
There's a lot more to "non commercial software" than just one OS kernel, you know.
There sure is. Not only that, but "Linux" -- or rather, the universe of free-software Unix-like components -- is not entirely a noncommercial space. It contains a lot of commercial competitors to Microsoft, such as Red Hat, Zope Corporation, IBM, and so forth -- it isn't just volunteers hacking code for fun. It's these commercial competitors -- not a bunch of random hackers -- who will eat Microsoft's lunch if they get the chance.
("Commercial" is not the same as "proprietary". There is plenty of commerce possible, and existent, in the world of free software.)
Also remember that Linux is a bigger threat to Unix vendors than it is to MS, because the barriers to migration are lower. I would be very surprised if Sun didn't consider "Lintel" to be its #1 threat.
It doesn't have to be that way. Because the portability barriers between GNU/Linux and Solaris are low, customers can migrate easily, yes -- but so can good code. For instance, Apache is often thought of as "Linux software" by people who don't know very much, but it also ships with Solaris.
Sun has to compete more closely with free-software systems than Microsoft does... but Sun can also benefit much more easily from free-software innovation than Microsoft can.
(Of course, portability is not the only reason for this; ideology is, as well. One of the planks of Fundamentalist Gatesism is that free software doesn't do anyone any good. And they call us fanatics?)
Not necessarily. You bought the license to the (for instance), vinyl version of the music, not the CD version.
#include "disclaimer.h"
#undef LEGAL_ADVICE
No, I didn't buy a license to anything -- I bought a copy. I have the right to use that copy as a piece of my property: I lack the right to make and redistribute copies of it, since that is the creator's exclusive right under copyright and I have no license (i.e. permission) to do so.
Copyright does not include the idea of a "license to use". It is concerned only with the right (or lack of a right) to make and distribute copies, derivative works, and suchlike. The rights that a creator receives under copyright are rights to restrict others' copying and the making of derivative works -- not rights to restrict others' noncopying use of legally-obtained copies.
Licensure enters the picture only when copying enters the picture. I do not need a license from J. K. Rowling or her publisher to read The Order of the Phoenix. I also do not need a license to take my purchased copy, cut it up, and make paper airplanes from it -- or to lend it to my friend. I would need a license to legally scan it into my computer, make a PDF of it, and distribute it online -- a license that Rowling et al. have no interest in selling me, certainly.
It is trivially simple to debunk the claim that purchasers of copies of media are purchasing "licenses to use" the media: licenses are always explicit. When authors and publishers negotiate the publisher's purchase of rights to a book (a license), that license is written out as part of a contract. The publisher does not simply accept the physical manuscript pages and pay the author (purchasing a copy, albeit the only copy perhaps): an assignment of copyright licensure is in a contract, entered into knowingly by both sides. Thus, if a media purchaser has no demonstrable contract with a copyright owner, no license can be said to exist... and you cannot unknowingly or unintentionally enter into a contract!
(Further, a license and the violation thereof is not necessary to make copyright violation illegal: it is illegal already, as the default state of works is to be copyrighted. Copyright is not a matter of violation of contract; it is a matter of violation of the law.)
Copyright is really simple: don't copy and distribute stuff you didn't create, without the creator's permission. Trying to complicate things with "licenses" for the common reader or listener is nothing short of villainy.
Someone (by someone, I mean companies that put out SMTP servers with a large share of the market) should strike while the iron is hot and take it a step further by airing some simple PSA's during a small assortment of shows. Maybe some must see TV "The More You Know" type thing...
[Fade in on dim interior of grimy trailer packed with disused computer equipment and swimsuit calendars. Greasy-looking SPAMMER puts down a half-eaten slice of cold pizza and starts dialing the phone.]
SPAMMER: Hello, is this Ms. Smith? I was wondering, would you mind if I used your computer to put some pirated pornography on the Web? [click, dial tone in background] Hello? Ms. Smith?
[Cut among views of SPAMMER on the phone, sleazy as ever.]
SPAMMER: Could I borrow your computer to send millions of spam emails? [click]
SPAMMER:... just want to use it to run a quick scam -- [click]
SPAMMER: Uh, Mr. Jones, could I steal passwords -- [click]
SPAMMER:... I want to crack into eBay and rip people off, could I use your computer for that? [click]
[SPAMMER looks sweatier and nervous, impatient and guilty.]
SPAMMER: [click] Hello? Hello?
[SPAMMER puts the phone down and starts typing, face illuminated by the screen.]
JAMES EARL JONES VOICEOVER: In the real world, spammers and Internet criminals don't ask your permission. They use viruses and insecure computers world-wide to steal from people. To find out what you can do to protect yourself and your family from crime on the Internet, log on to computer security dot gov.
[Fade out to black screen:]
http://computersecurity.gov/ Take a byte out of crime.
JAMES EARL JONES VOICEOVER: Brought to you by the FBI and the SANS Institute.
British Bloodletters' Association and the Snake Oil Forum have issued a joint statement decrying the use of surgery and medicine in UK hospitals.
Mercenaries Union has called for a more aggressive foreign policy "to protect national interests".
The Direct Marketers' Association is continuing to lobby against effective anti-spam regulations on the grounds that they "will prevent the expansion of your penis^W^Wour industry."
The Royal Mad Scientists Society has petitioned for an end to BSE prevention efforts, staging street protests with the slogan "prions are people too!"
Re:O'Reilly's worst dud was also about Linux clust
on
Linux Clustering
·
· Score: 1
I thought it was pretty obvious that those reviewers never actually attempted to do anything with the book, or particularly the CD-ROM; they just browsed the former and never let the latter touch their Windows systems. From a cursory (read: sloppy and shallow) first impression it is not nearly as bad as it is on a closer look, and a trade-rag pseudojournalist with enough cocaine in his system would probably find it quite impressive.
Re:O'Reilly's worst dud was also about Linux clust
on
Linux Clustering
·
· Score: 1
I bought that book... any idea how to get a refund?
Waited a while, didn't you? That book was withdrawn from sale two years ago. People who wrote to O'Reilly customer service at the time did get free books (an up-to-date copy of Linux in a Nutshell in my case, twice as thick and more useful for clubbing lusers^W^Winforming coworkers with)... but I don't know if they'd do anything for it now.
O'Reilly's worst dud was also about Linux clusters
on
Linux Clustering
·
· Score: 5, Interesting
How bad was it? It came with a CD-ROM that was supposed to automate the process of setting up a Beowulf cluster. None of the software on the CD-ROM worked. Running the install script printed out a message telling you to go to a Web site and download the newest beta version of the software. No such software was available... ever. O'Reilly shortly withdrew the book... and, reportedly at least, fired the editor who approved it for publication.
Want more details? Here you go. Waiting for this book, and then discovering slowly just how awful it was, set back a clustering project at my workplace by several months, by the way.
Slashdot Mirror
This is true only within a tiny branch of computer science, and thoroughly false for programming in general. In the real world, we deal not with the empty and valueless mathematics of pure logic, but with values which stem from our needs and desires. Many of those values are not easily amenable to logic -- such as clarity and ease of maintenance, which are subjective and arguably aesthetic values.
By "valueless" I do not mean that logic is worthless, but rather that it provides no values in itself. It is empty. Logic allows us to draw relations between sentences, for instance, but it cannot tell us if our premises are true or false -- nor if our arguments are well-written and convincing, or our conclusions admirable or vile. It likewise can tell us if our programs generate results consistent with our assumptions, but it cannot tell us if those assumptions are worth anything -- nor if anyone can stand to look at our code.
Two programs may be equally correct in the mathematical sense, but a programmer may still be correct in preferring one over the other. Mathematical equivalence does not mandate indifference. (Indeed, this is true of pure mathematics as well as programming -- mathematicians can recognize two proofs of the same theorem as equivalent, but agree that one is elegant and the other a mess of kludges.)
There are all sorts of values besides strict mathematical correctness which go into judging the optimality of a program. Correctness is necessary, of course, but it is by no means sufficient. When others must read it, a program's clarity is valuable, as is its self-descriptiveness. (The statements x += 60; and seconds_till_alarm += 60; are mathematically equivalent, but one is to be preferred in certain contexts.) Likewise we may appreciate a particular method used, a turn of phrase as it were, which may make the program neither more correct nor more efficient, but more fitting to the way people think about the problem domain.
Is a program poetry? No, not usually. People do, after all, write programs for their effects when run. However, by no means are these the only relevant considerations, any more than the logical validity of the arguments made by a public speaker be the only consideration in whether the speech was good or bad -- or laudable or ignoble.
I was unclear. A blocking system does not accept the message, then generate a bounce message back to the apparent sender -- the behavior you are describing. Rather, a blocking system rejects the message during the SMTP transaction, with an error code. It is then up to the sending system to handle the error, which may lead to the sending of a bounce message.
It is bad behavior for an MTA to accept in the SMTP transaction a message which it knows it will not attempt to deliver -- for instance, to accept a message from a known spam source and then delete it. This is because SMTP operates on an assumption of best effort: when an MTA accepts a message, it is agreeing to do its best to deliver that message. Saying that you will try to deliver when you know you won't is dishonest, and leads to problems -- such as the spurious bounces you describe.
Generally, spammer software is unable to handle SMTP error codes, and does not generate bounce messages anyhow. However, legitimate MTAs do handle error codes and generate bounce messages when real mail is not deliverable. By using blocking techniques (and sending error codes) one does the right thing both with spam and with the occasional false positive: the spam is simply rejected, rather than bounced to a forged sender; and the legitimate message is returned as undeliverable.
Sure there is. After all, many of the spammers who use these open proxies are being tracked down and documented in ROKSO, part of the Spamhaus Project. However, this tracking does require using resources other than just header analysis and traceroute.
The investigators use methods more akin to a private detective's or law office's methods than to a network administrator's. For instance, they follow the money. The majority of spam messages are trying to sell something, so they need an avenue to collect payments. Or they use public records: many spam messages flog Web sites, which may well have spurious whois contact information, but are registered in the name of a legally-established corporation or LLC. (Spammers incorporate for the same reason anyone else does: when they get sued, it protects their personal assets.) In this case, the investigators can go to the state corporations records. These are public records, which list the officers of the corporation -- in other words, the spammers.
Take a look at the ROKSO records for any major spammer, like Eddy Marin or Ronnie Scelson. ROKSO records are compiled entirely from public information -- corporate records, legal filings, domain registrations, and so forth. They also represent a tremendous amount of work on the part of Steve Linford, Shiksaa, and other investigators. Tracking spammers is not necessarily something you can do from your xterm, but it is possible, and it is being done.
You're citing an out-of-date RFC. 821 was superseded by RFC 2821, which makes it clear that 554 is a valid connection-opening response, to indicate that mail service is not available. (Indeed, 2821 spells out two codes for use at connection establishment -- 220 to accept, or 554 to reject access.) AOL is correctly using 554 to indicate that it will not provide mail service to your IP address.
A 4xx code would be improper in this case. 4xx codes indicate temporary failures. They mean that the client should queue its messages and retry them later, rather than returning a bounce message to the sender. That's not what is intended here -- the server doesn't want you to retry, it wants you to not try. A 5xx error code is correct.
There are substantial disadvantages to a client-side filtering only spam defense as opposed to a server-side blocking only defense. It is, of course, fully possible to use both; I merely wish to point out some factors you may not have considered.
For the definitions of "filtering" and "blocking", please see this Wikipedia article. Roughly, DNSBLs and Sendmail's milter feature are blocking tools -- they take effect during the SMTP transaction. Client-side tools are filtering tools -- they take effect when you check your mail.
Consider:
However, as I mentioned above, it is possible to combine blocking and filtering in useful ways. A mixed strategy is what I prefer for my own site: we use a number of blocking strategies (such as DNSBLs and regular-expression patterns matching common spam elements), but we also use SpamAssassin and encourage users to filter with its scores or other criteria.
I remember the first edition of Practical C++ Programming. Readers who wished to get something out of that book should've noticed that it was absolutely necessary to debug the book's programming examples first.
Errata? 'Er sure smella like it!
It is less than accurate to say that one can break or violate the GPL, since the GPL is neither a law nor a contract: it is a limited grant of permission. One cannot violate it like a contract, but one can exceed the bounds of the permission granted. If one does so, one is infringing upon copyright: one is violating copyright law. In the case of a registered copyright, such violation carries statutory damages.
Consider: Suppose that we lived in a society with strict and unforgiving trespassing laws: anyone who walks on another's land without permission is both guilty of the crime of trespassing, and liable to the landowner for statutory damages.
Under this regime, Fred grants Barney permission to walk across his front lawn, but not his back lawn. This is a limited permission: it spells out what Barney may do which he otherwise mayn't, and also clearly notes what he still mayn't do. (Likewise, the GPL spells out that one may copy and distribute with source, but not without.)
If Barney strays, and walks across Fred's back lawn, is he in violation of the Fred Lawn-Walking License? No, not at all. He is simply in violation of the trespassing laws, for he has no permission to cross Fred's back lawn. The fact that he does have permission to cross the front does not militate against his conviction and liability: he took an action (crossing Fred's back lawn) which requires permission, which permission he did not have.
To bring the matter back to SCO: SCO, and other Linux distributors, do not contract with Linux and Samba authors under the GPL. It is not a contract; thus, it may not be violated. Rather, the GPL is the instrument by which the Linux and Samba authors grant SCO and others permission to do something they otherwise would be forbidden from doing: copying and redistributing Linux and Samba.
When a distributor strays beyond the bounds of that permission -- for instance, by distributing binaries and refusing to distribute source; or failing to distribute derivative works under the same license as the original -- the distributor is a common copyright violator. The very same laws that make Joe College liable for running off copies of the RIAA's favorite tunes, make the infringing distributor likewise liable.
That's copyright. Copyright law is about obtaining permission from authors before you may copy and redistribute their works. That permission needn't be in the form of a contract, and indeed in the case of GPL works it is not. A distributor who "violates the GPL" by failing to distribute sources is overstepping the bounds of their permission -- and is, in the vulgar argot, a software pirate.
The GPL expressly disclaims covering a "freedom to use", stating rather the following:
What does this mean? Not only does the GPL provide authors no handle by which to prevent someone from using the covered code, it also presumes that a user does not need additional permission from the copyright holder to use a copy which is legitimately obtained. If you buy a copy of a work, it becomes your property and you may use it; you need permission and licensure only when you wish to make and distribute copies.
The scammers behind proprietary licenses have come up with all sort of language to mask this fact: "licensed, not sold"; "you own the media, not the work"; and so forth, as if it were possible to deprive someone of a purchase retroactively by declaring it to have not taken place. (It isn't; if you walk into a store, and the store's staff and you carry out the overt ritual of selling and purchasing a given item, then you have purchased the item, even if a paper inside the box describes it as "licensed, not sold". Naturally, you have not purchased the copyright, but the copy you have purchased is yours to use or abuse.)
Vice versa, there is no way that SCO's post facto claims that the GPL is worthless can cause the GPL to be worthless to SCO. They may rail against it for years, and it will still be sufficient to grant them the right to copy and distribute binaries and source together. You can waive many sorts of right merely by saying you do, but the GPL isn't such a right. Rather, it is a grant of permission, which remains efficacious even if you deny it. No matter how much SCO says, "The GPL is worthless," they still have and hold the rights granted them under it.
That is, of course, one of its strengths.
From what I can tell, RMS sees these things in terms of abstract principles, whereas Debian sees them as guarantees that it can offer its users and society at large. Hence RMS comes off sounding "religious" to some, while Debian hies to a document it calls its "Social Contract".
Because it's in the business of offering assurance to its users that they will be able to redistribute and modify the packaged software, Debian has to be exceedingly careful of license conflicts and the like. They took a good deal of heat for excluding KDE until Qt's license ceased to conflict with the GPL. (It's a myth, by the way, that Debian demanded Qt be GPLed. In fact, the problem was that while KDE components were GPLed and Qt's license was also Free, Qt's license and the GPL on KDE could not be simultaneously satisfied.)
The difficulry arises with the GNU FDL because people can add sections called "Invariant Sections" to covered documents. These are portions excluded from the freedom of the license -- portions which future maintainers may not modify. Debian guarantees that the materials you get from its mainline distribution are things you may modify, so obviously Debian can't include FDL Invariant Sections in its mainline distribution.
It isn't a matter of fanaticism, advocacy, or holiness. It's a matter of plain and simple contradiction: Debian can't give something away as freely modifiable software if its license says it isn't -- and an FDL Invariant Section is no more freely modifiable than is Microsoft Word.
If someone says, "I'm making a CD of software that's all BSD-licensed," then obviously they aren't going to include gcc in it. Calling them fanatical or "holier-than-thou" for simply keeping their word, makes you seem to be fanatically advocating hypocrisy and deceit.
Let's not confuse the roles of a repairman and an instructor, both of which can come into play in technical support. The repairman is paid to come in, fix something, and leave. You don't care how the Roto-Rooter guy cleans out your pipes, or what goes into the tar-paper the roofer uses to repair your leaking roof. However, when you call technical support and ask how to do something, you are not asking for repair -- you're asking for instruction. You are asking to be taught: perhaps only to be taught a specific, limited task (like defragging your hard drive, or getting your cable modem to sync) -- but this is still very different from asking for repair.
Repair doesn't involve your understanding or acceptance -- just get out of the way and let the repairman do his job. However, teaching doesn't work that way. In order to learn, you must be receptive -- willing to learn. You must already know the prerequisites to whatever it is you're being taught. And you must not willfully resist instruction -- as by being impatient, calling your teacher rude names, or demeaning the subject at hand: "I don't need to know what a hard drive is, I'm not some kind of nerd. Just tell me what to do to maaake it goooo!"
Think about the question you are asking the tech-support guy. Whenever that question begins with "How do I ... ?" you are asking to be taught. Make sure that you are ready to be a good student.
This is exactly the sort of thing I was referring to, actually. There are small portions of Linux systems where the designers have attempted to follow Windows or Macintosh GUI designs in order to make life easier for new adopters. However, because the Windows user is focused on the GUI and considers it to represent the sum-total of the software system, these small parts' importance is exaggerated. They look bigger than they are -- and consequently, make the real system look smaller and weaker -- precisely because that is what you expect.
You see these components as failing to meet your Windows-based expectations because they are so often thin imitations. The Windows user who looks for these thin, artificial correspondences to Windows features is like the tourist who doesn't understand the language of the foreign city he is in, and relies upon a phrasebook. Naturally his speech seems stilted to the native speaker, and his understanding limited -- he is using an artificial set of correspondences which don't really map that well to the native way of speaking and thinking.
Here's an example a coworker and I thought of this morning while discussing this problem with regards to a client of ours who is moving from Windows to Linux rather slowly: What is the natural way, on Windows and then on Linux, to copy all the .txt files in a directory, to a directory on another host? How does the Windows user come up with a solution to this problem? What's the shallow phrasebook "translation" of that solution in Linux, and how does it compare to the "native speaker"'s equivalent?
Here's what we came up with:
Windows: Open Windows Explorer on the source computer. Enter the share name of the destination directory on the destination host, e.g. \\DESTHOST\DEST\PATH. Open the source directory. Sort the source directory by file type, select all the text documents, and drag them to the destination directory.
"Phrasebook" Linux translation: Open a GUI file browser, such as Nautilus or Konqueror. Enter the URL for the destination directory on the destination host, e.g. smb://desthost/dest/path/. Open the source directory. Sort the source directory by file type, select all the text documents, and drag them to the destination directory.
"Native" Linux translation: Express the source and destination directories as pathnames, and the list of files to be copied as the wildcard *txt. Use OpenSSH's scp command to copy the files, e.g. scp /source/path/*txt desthost:/dest/path/.
Now, I will guarantee you that the phrasebook translation on Linux is much less reliable than the original Windows instructions. Why? Because the software components it relies on are those thin imitations I mentioned. The file browsers in Nautilus and Konqueror, and the SMB access libraries underneath, aren't native functionality in Linux -- they're mock-ups of the Windows way to do things. They certainly aren't how a "native Linux speaker" is likely to do it. (They can also a bloody pain to set up if your SMB network is weird.)
In contrast, I can assure you that the "native" Linux translation accomplishes the very same job -- copying some files to the very same destination -- and will do so far more reliably. It uses the "Linux-ish" (okay, "OpenBSD-ish") SSH service to do so, rather than the "Windows-ish" SMB service. It doesn't require any weird setup in advance, provided that sshd is already running on the destination host -- which it is by default on most Linux distributions, just as SMB is there by default on Windows.
(An aside: Please note that I'm not comparing the native-Windows and native-Linux ways of doing things. I'm not saying
Point 2 stands, but fails to make the GPL a contract. Why? Because the licensee is not thereby giving anything to the licensor. Absent the GPL, the licensee has no right to copy and distribute the covered work. Thus, the licensee cannot give up the right to distribute copies without source -- since he does not have that right.
The default state of a work is for copyright to vest in the creator, and for nobody else to have the right to copy and distribute without the creator's permission. What the GPL grants you is the right to distribute certain kinds of copies, but not others. It grants a restricted permission to copy. That is not the same as granting you blanket permission to copy, in exchange for something else -- since in the case of the GPL, the licensee doesn't have that "something else" to offer. You can't be offering "your agreement to only distribute copies with source" -- since, absent the GPL, you don't have any right to distribute copies, with or without source.
Remember: Under copyright, all rights to copy and distribute vest with the creator, not the recipient of a copy. Two things follow from this: First, any distribution-right that the recipient has is one granted by the creator. Second, the recipient cannot give up a distribution-right that he does not have; and thus cannot give up such a right as part of a contract.
"I'll lend you my baseball, but you have to lend it to Joe if he asks" is a limited grant of permission for you to use my property. The GPL is kind of like that. You're trying to turn the GPL into something like "I'll lend you my baseball, in exchange for which, you agree not to hit me in the head with it," and call that a contract. Since you don't have any right to commit assault and battery upon me, for you to "give up" that "right" isn't consideration.
Trying to understand Linux as a "Windows substitute" is a doomed prospect. Their differences aren't just a matter of tradeoffs: they are radically different kinds of system, much as an MP3 player is different from a turntable. If you found two people arguing over whether an MP3 player or a turntable was "better" -- or a turntable user saying that MP3 players were "annoying" due to the lack of an RPM control -- you would of course recognize this as nonsense.
An example of this sort of difference between Linux and Windows is the difference in the handling of drives. Windows uses drive letters; Linux uses mount points in a single filesystem. While there may be advantages to each, they are more a design difference than a set of tradeoffs. Another example is the difference in balance between CLI and GUI. Windows (or, moreso, Macintosh) users who come to Linux looking for that kind of carefully tuned GUI are likely to be disappointed -- and pushing the KDE control panels on them as "almost as good" is inviting their disappointment. There is a difference in design intention between GUI-focused and CLI-focused systems. The new user just has to un-learn old assumptions, just as the turntable user needs not to be looking for an RPM switch if he wants to become familiar with the MP3 player.
Things I would describe as "Linux annoyances" are points which remain difficult, problematic, or simply grating even for the already-familiar Linux user. Many of these will sound entirely foreign to the Linux novice or non-user, since they are matters that only occur to the already-familiar. These are points which seem out of place, or insufficiently regular or predictable, even to the expert.
Some examples of what I mean:
Have you tried rlwrap? It effectively adds readline support to command-line interactive programs that don't have it. I've used it successfully with SBCL and other relatively complicated command-lines -- so I'm going to guess it'll work with Oracle's too.
And what did the administrators of SomethingAwful do? Did they contact their ISP, whose support of spammers led to its netblocks being boycotted far and wide by other networks and mail server operators? No. Instead, they posted a solicitation for their own users (the "SA Forum Goons") to attempt to obtain the personal information of the operators of SPEWS, for the purposes of signing said operators up on spam mailing lists. They also instructed the goons to flood a spam-related USENET newsgroup with crude messages -- which was done.
In short, SomethingAwful's operators specifically encouraged criminal activities and abuse of the network. Reportedly, readers of the flooded USENET group did the right thing in response -- rather than counterattacking with a flood of their own, they reported the criminal activity to the offending user's sites (including universities). At least some of the offenders' accounts were terminated for their criminal activity. The undergrads who thought they were clever to post "fuck you goatse spam whores" a bazillion times from their university accounts won't think they are so clever when they are brought up on disciplinary charges for malicious use of university resources.
SomethingAwful deserves no sympathy. In response to a legal boycott of their ISP's network -- stemming from their ISP's willful continuing to host egregious spammers -- the owners and operators of SomethingAwful committed and advocated criminal acts. Their actions are criminal no less than the spammers' themselves.
It's interesting you chose that particular slander for your post, since it was the early 20th-century equivalent of "reefer madness". One of the driving rhetorical points of Prohibitionism, and the reason that it was embraced by some elements of what became the women's movement, was just that: "Alcohol causes our responsible men to become irresponsible and beat their wives. If we get rid of booze, there will be no wife-beating!"
Naturally, it didn't work that way. Sober men are just as capable of rage as drunk ones, and neither beer nor gin can make a violent man from a peaceable one. Moreover, blaming a man's misdeeds on the drugs he consumes, rather than on his own character, does nothing to cause him to correct himself. A violent person who can excuse his behavior the next morning by saying, "It was the bottle talking," sees no reason to become less violent.
The remedy for domestic violence is not to dissuade men from drinking, but to convince them (as has thankfully been done in society at large, thanks chiefly to feminism and the law) that domestic violence is wrong, shameful, and criminal. Only by ascribing responsibility solely to the individual -- not to his drug, and not to "society" -- can the problem be corrected. Why? Simple: The booze doesn't make decisions; individuals do.
Leave beer alone, for -- as with marijuana -- the vast majority of users enjoy it responsibly. Lay the blame for wrongdoing on the wrongdoers -- and shame on you, if you let them blame it on the bottle.
There is no consideration, since you are not giving the author anything he did not already have. Your "agreement" not to distribute the code in violation of the terms of the GPL does not constitute giving the author anything ... since you were already obligated not to distribute it in violation of copyright law. You cannot give the author your agreement not to violate copyright law as consideration, since you had no right to violate it.
Here's a parallel: Let us say that we live in a town with strict, absolute trespassing laws, such that if I cross your property without your permission, I am guilty of trespassing. Now, let us say that you generously grant me permission to cross your front lawn, but you make it clear -- in the terms of that permission -- that I am not permitted to cross your back lawn. The permission you grant is limited, not absolute: I am allowed to do some things that would be illegal without your permission, but not others. My not crossing your back lawn is not a consideration that I give to you, because it was not a right I possessed in the first place!
A more blatant parallel: "If you give me twenty bucks, I will not shoot you." This is not an offer of contract, since I have no right to shoot you. To claim that the software recipient gives the author consideration in "accepting" the GPL is to claim that the recipient means, "If you give me this software, I will not violate copyright law upon it." That's not consideration.)
The GPL is not a contract. It is a grant of permission. Copyright says, "You may not copy without the author's permission." (Note, it doesn't say that permission has to be in the form of a contract -- it can be in the form of a unilateral grant of permission.) By placing a work under the GPL, the author says, "You have my permission to copy, but only in certain ways." The default condition -- lack of permission, hence normal copyright law -- applies if you violate those terms.
There sure is. Not only that, but "Linux" -- or rather, the universe of free-software Unix-like components -- is not entirely a noncommercial space. It contains a lot of commercial competitors to Microsoft, such as Red Hat, Zope Corporation, IBM, and so forth -- it isn't just volunteers hacking code for fun. It's these commercial competitors -- not a bunch of random hackers -- who will eat Microsoft's lunch if they get the chance.
("Commercial" is not the same as "proprietary". There is plenty of commerce possible, and existent, in the world of free software.)
It doesn't have to be that way. Because the portability barriers between GNU/Linux and Solaris are low, customers can migrate easily, yes -- but so can good code. For instance, Apache is often thought of as "Linux software" by people who don't know very much, but it also ships with Solaris.
Sun has to compete more closely with free-software systems than Microsoft does ... but Sun can also benefit much more easily from free-software innovation than Microsoft can.
(Of course, portability is not the only reason for this; ideology is, as well. One of the planks of Fundamentalist Gatesism is that free software doesn't do anyone any good. And they call us fanatics?)
#include "disclaimer.h"
#undef LEGAL_ADVICE
No, I didn't buy a license to anything -- I bought a copy. I have the right to use that copy as a piece of my property: I lack the right to make and redistribute copies of it, since that is the creator's exclusive right under copyright and I have no license (i.e. permission) to do so.
Copyright does not include the idea of a "license to use". It is concerned only with the right (or lack of a right) to make and distribute copies, derivative works, and suchlike. The rights that a creator receives under copyright are rights to restrict others' copying and the making of derivative works -- not rights to restrict others' noncopying use of legally-obtained copies.
Licensure enters the picture only when copying enters the picture. I do not need a license from J. K. Rowling or her publisher to read The Order of the Phoenix. I also do not need a license to take my purchased copy, cut it up, and make paper airplanes from it -- or to lend it to my friend. I would need a license to legally scan it into my computer, make a PDF of it, and distribute it online -- a license that Rowling et al. have no interest in selling me, certainly.
It is trivially simple to debunk the claim that purchasers of copies of media are purchasing "licenses to use" the media: licenses are always explicit. When authors and publishers negotiate the publisher's purchase of rights to a book (a license), that license is written out as part of a contract. The publisher does not simply accept the physical manuscript pages and pay the author (purchasing a copy, albeit the only copy perhaps): an assignment of copyright licensure is in a contract, entered into knowingly by both sides. Thus, if a media purchaser has no demonstrable contract with a copyright owner, no license can be said to exist ... and you cannot unknowingly or unintentionally enter into a contract!
(Further, a license and the violation thereof is not necessary to make copyright violation illegal: it is illegal already, as the default state of works is to be copyrighted. Copyright is not a matter of violation of contract; it is a matter of violation of the law.)
Copyright is really simple: don't copy and distribute stuff you didn't create, without the creator's permission. Trying to complicate things with "licenses" for the common reader or listener is nothing short of villainy.
[Fade in on dim interior of grimy trailer packed with disused computer equipment and swimsuit calendars. Greasy-looking SPAMMER puts down a half-eaten slice of cold pizza and starts dialing the phone.]
SPAMMER: Hello, is this Ms. Smith? I was wondering, would you mind if I used your computer to put some pirated pornography on the Web? [click, dial tone in background] Hello? Ms. Smith?
[Cut among views of SPAMMER on the phone, sleazy as ever.]
SPAMMER: Could I borrow your computer to send millions of spam emails? [click]
SPAMMER: ... just want to use it to run a quick scam -- [click]
SPAMMER: Uh, Mr. Jones, could I steal passwords -- [click]
SPAMMER: ... I want to crack into eBay and rip people off, could I use your computer for that? [click]
[SPAMMER looks sweatier and nervous, impatient and guilty.]
SPAMMER: [click] Hello? Hello?
[SPAMMER puts the phone down and starts typing, face illuminated by the screen.]
JAMES EARL JONES VOICEOVER: In the real world, spammers and Internet criminals don't ask your permission. They use viruses and insecure computers world-wide to steal from people. To find out what you can do to protect yourself and your family from crime on the Internet, log on to computer security dot gov.
[Fade out to black screen:]
http://computersecurity.gov/
Take a byte out of crime.
JAMES EARL JONES VOICEOVER: Brought to you by the FBI and the SANS Institute.
The one about the DMA is true.
I thought it was pretty obvious that those reviewers never actually attempted to do anything with the book, or particularly the CD-ROM; they just browsed the former and never let the latter touch their Windows systems. From a cursory (read: sloppy and shallow) first impression it is not nearly as bad as it is on a closer look, and a trade-rag pseudojournalist with enough cocaine in his system would probably find it quite impressive.
Waited a while, didn't you? That book was withdrawn from sale two years ago. People who wrote to O'Reilly customer service at the time did get free books (an up-to-date copy of Linux in a Nutshell in my case, twice as thick and more useful for clubbing lusers^W^Winforming coworkers with) ... but I don't know if they'd do anything for it now.
How bad was it? It came with a CD-ROM that was supposed to automate the process of setting up a Beowulf cluster. None of the software on the CD-ROM worked. Running the install script printed out a message telling you to go to a Web site and download the newest beta version of the software. No such software was available ... ever. O'Reilly shortly withdrew the book ... and, reportedly at least, fired the editor who approved it for publication.
Want more details? Here you go. Waiting for this book, and then discovering slowly just how awful it was, set back a clustering project at my workplace by several months, by the way.