What you need is something you can point to a judge and say, "see? Clearly any reasonable human being wouldn't think this was infringing."
That's the case in the example cited at the top of the article. It's not the case in what you're proposing.
You don't want to be able to point to the lawyers and say "see, they're technically wrong." You need to be able to point to them and say "see, they're completely nuts and out of control." Remember, the law is run by humans, and most humans have a relatively short attention span. Don't appear to be taunting the lawyers who send you threat letters. Make their actions obviously unreasonable.
Do this first, and get legal precedent established to the effect the lawyers having to take some due diligence to determine which things really are infringing, and on whose copyrights. Then, push the edge a little bit. I do think that if you keep pushing slowly you can eventually get to the point where automated lawyergrams in response to the files you describe would cause trouble for the lawyers. However, the time is not yet right for taunting honeypots.
Fortunately, the lawyers use some really stupid bots, so all we may need at this point is some sort of central clearing house to coordinate all these blatantly false DMCA actions. Either that, or get a Congressional representative to introduce a provision that allows for a small claims court action to recover, say, $500 for each false claim. (For the defamation suffered) But in that event, the claim will have to be such that no reasonable and awake person could have made it; your taunting filenames still wouldn't work.
The EFF could then publish guides on filing such claims. This results in a legal DDOS on firms with stupid bots.
The result? Fewer lawyerbots, or significantly smarter ones, or both.
WindowsUpdate is very unlikely to go down. MS not only has a lot of money to spend on servers, but they have warning of the problem too. They can even induce test cases.
Right; they had warning, the bastards. A truly effective worm wouldn't give warning. It'd trigger the DDOS as soon as it was sufficiently deployed.
So how would a worm do that, absent a central point of communication? I suppose it could track reinfection attempts, and switch to DDOS mode when the number of reinfection attempts/minute gets high enough. Or I suppose it could keep some sort of generational counter that increments with every new infection, switching to DDOS mode when it has travelled through enough hosts. Of course, you wouldn't want to make it too easy for the authorities to track down patient 0...
Another idea is to read top news sites and look for certain strings - when the news media finds out, get nasty. Since this would probably cause the news media to use all sorts of euphemisms to avoid the trigger strings, maybe it should hunt through the slashdot comments - because someone will certainly post a comment of the form "I've analyzed the worm, here are the strings it's looking for:...". Such a post will inevitably be modded up.
I guess a fourth option is for the worm author (or someone associated with the worm author) to trigger it themselves. Say, when the worm connects to port 4444 to send the command to tftp over a copy, they get back a string saying "it's time". Then that host (and any host which later tries to reinfect it, etc.) switches to DDOS mode. Since this would only be necessary once, it'd be almost untraceable. (Especially if done through one of those wide open socks proxies the spammers are always using) This option, combined with a procedure for cryptographically signing updates, actually has some possibilities for generic updates to the worm.
It occurs to me that the worm author needn't have targetted windows update. Imagine if this worm appeared to have originated from inside Microsoft and targetted Microsoft's large enemies (IBM, RedHat, the AG office of the states who are still suing them, some EU agencies, etc.) I wonder if the political fallout from that would be noticeable?
I've never, to this date, had an issue with Hello World.
You link it statically, right? Because there have occasionally been buffer overflow issues in ld.so...
Even avoiding ld.so overflows, there's still the libc5 to libc6 transition, and a hello world compiled under libc5 just won't run on a modern (libc5 compatibility removed) linux box.
As for static binaries becoming obsolete, I suppose we'll have to wait for a kernel that has dropped a.out support. That will probably happen at some point.
It is a significantly more gray area if you were to listen for attempts on your machine and, after receiving an active probe (not just a SYN packet, because single SYNs are very fakeable), hit the attacking machine with something that used this vulnerability to wipe out the virus.
If you want to stretch things, it might even be acceptable to then download and install the microsoft security patch (although that's pushing things a bit). Maybe. Much more acceptable would be to replace the worm with something that looked sufficiently like the worm to prevent re-infection, but did nothing.
However, creating and releasing a "beneficial virus" is just flat out illegal and dangerous. Have you ever written code that worked exactly as it was supposed to, on systems you've never seen? Have you ever gotten a piece of code bug-free before the first large test? Have you ever created a binary that someone could look at and easily verify behaved exactly as advertised?
The idea is that so long as you are disarming a machine that has directly attacked one of your machines, you are on defensible moral (IANAL, so I won't talk about legal) ground. However, forcing an update on a third party, or even doing more than the minimum necessary to disarm the machine attacking you, places you in the same category as the original virus writer - you cannot know all the effects of your actions, therefore doing more than the absolute minimum necessary is irresponsible.
I do wonder what kind of krakk kokane your software engineering staff has to be smoking for them ship an operating system that, in its default configuration, allows an unauthenticated tcp message from any random spot on the internet to display a dialog on a client workstation, but, as I mentioned earlier, that's not where I want to go today.
Probably the same stuff that was being smoked near any place shipping a unix operating system - remember "talk"? The internet used to be a much calmer place. (Actually, I haven't done a default install of any linux distro in ages - does redhat install talk-server by default?)
Now, had you added "in 2003" or "in this day and age" to your comment... maybe. But being open to messages from the outside by default has a long and proud history.
Re:Some things to point out.
on
Perl 1.0?
·
· Score: 1
See, now I'd inline the whole table if you're only using it once:
print "Would you use a hash as a switch statement? (y/n) ";
my $answer = <STDIN>;
if ($answer !~/^[yn]$/i) {
print "You've reached the default\n";
} else {
chomp $answer;
{
'y' => sub {print "You code too much perl!\n";},
'n' => sub {print "You don't use enough perl!\n";}
}->{lc $answer}->();
}
Probably not, but his statement of the situation squares with my experience when I talked to an FBI agent after having discovered (and logged) some IRC kiddies who were constructing a DDOS network out of sub7-infected machines.
I'd created a sub7 honeypot on my linux box with a little perl script; after that collected the IRC server ip and channel name, I connected with a random username (pretending to be a bot) and just logged the conversation.
The FBI agent interviewed me very carefully to make certain that my setting up monitoring, etc., was not in any way instigated by a law enforcement officer. (No, I'd just gotten annoyed at random SYN packets) Then, he had no trouble with it. I don't know if this makes the evidence I provided useable legally, but it never came to that. As he explained it, the question was whether I was acting as an agent of the state when setting up the honeypot. Committing entrapment is not anything that non-state actors ever need worry about.
Not that this lets you off the hook entirely - there may be charges of wiretapping involved; monitoring your own machine should be safe legal ground, but connecting to the IRC network (as I did) is a slight bit more dicey legally, and shouldn't be done if you have any reason to believe that the relevant prosecutor would like to hang something on you as well.
Because they have lawyers sending out the letters who very carefully know the barratry statutes in the different states they're sending these letters to. I'm willing to bet that any "pay up or else" letter (the existence of which I am beginning to doubt, by the way) would be very carefully worded to be just on the legal side of the statutes.
There's a specific legal term for threatening baseless legal action: barratry.
The precise legal definitions of barratry vary from state to state, and I'm not in any kind of position to evaluate whether SCO might or might not be in violation of one of those laws. (Being neither a lawyer nor someone who has gotten a "pay up or else" notice for use of Linux)
Ok, I think I see the difference in our positions: if I'm getting paid for a copy of my code, I don't really care what the user does with it. They still can't redistribute it to someone else (legally), and are free to attack it with a hex editor all they want. (Just so long as they don't expect me to put it back together) Note that it doesn't make a difference to Id Software if someone patches their own DOOM wad files so that the bad guys look like Barney.
Similarly, if I had enough woodworking skill to build a chair I doubt I'd care if the customer who bought it went out and spray-painted it a hiddeous shade of lime green, though the color itself might keep me away from their living room. Likewise, with people buying a book and then whiting out passages they disagree with - so long as they do it to their own copy, no harm done. (except possibly to themselves)
I look at it this way: the right you're arguing over is the right of a customer to take a hex editor to files sitting for the moment on their own computer. This is something they're going to do anyway. You need to accept this, just as you need to accept the idea that people will look at the html source of your web pages. The lack of a legal right to do so (some sites' user agreements try to remove this) isn't going to make one bit of difference. Until they redistribute something, 1) there's no way you're going to know, and 2) they haven't entered into activity that is covered by copyright law anyway. (cf. home censoring of DVD movies)
Note that the right to modify stuff privately is very, very different from the right to redistribute the modified or original code in any way. Requiring the right to modify personal copies is not at all the same as requiring you "to give it away." Going back to the example of the Barney Doom patches, their existence (and, to some extent, toleration) did not in any way weaken Id's protections over their software or their bottom line.
Also, I will note a slight misunderstanding in your view of the GPL: private modifications need not be released. If you have a GPLed program, and modify it in some cool way, and even share the modifications with a few friends, you do not need to distribute the modified code except to those few friends. You do not need to tell the original author that you liked his code, that you're using it, or how you modified it. Note that the requirement that private modifications be released to the original author was one of the issues RMS had with some of the early versions of the NPL.
As you appear to be concerned about the position of a shareware games developer, note that under the LGPL section 6 it would be perfectly acceptable to distribute an application and say "you may modify this for your own use on your own machine, but you can only give away a copy of the unmodified version". (possibly at this point specifying checksums and archive filenames) If your game is distributed as a single self-installing executeable, this line is easy enough to draw: they can't redistribute what gets put on their disk during installation, but are free to pass along the original executeable.
Or, in this day and age, "you may modify this but you can't redistribute it - instead, point your friends to http://www.mysite.com for the latest trial version. Encourage your friends to register, too!"
That's what the command montage, part of the IM suite, is for. Check (as always) the man page for montage, and look at the -chop option (which lets you cut out rows or columns from one of the images before sticking them together).
I see. So the fact that it is difficult for them to do so (you didn't after all hand them the source) makes no difference?
That is, you appear to be placing great emotional weight on the idea that the user should not have the legal right to modify their copy of the bits that constitute your work.
Is it the fact that the user might change their copy what offeends you?
Or is it the second half of that sentence, that the user might while debugging discover the full details of how your software works?
Or is it the legal hassle that many proprietary libraries (and/or management) will impose a "must forbid reverse engineering" clause on you while the LGPL imposes a "must allow reverse engineering sufficient to debug modifications" clause?
If your normal software license is of the draconian "modify a single bit of this software only under pain of death" type, then you have to modify your license to allow the user some basic freedoms. (The right to modify the binary code on their machine and the right to reverse engineer to the extent necessary to debug said modifications)
Of course, depending on country and state laws where the consumer is, they may have this freedom already. And even if they don't, a legal notice isn't going to stop someone with a hex editor.
Could you kindly tell me what exactly this hole is?
Is it really that important to you that your clients/customers be unable to discover that you used a piece of LGPL'ed code? Is it important that they be unable to discover how you used that library?
As I see it (prizog, please correct this), the situation is this:
If you create a single distribution file containing both your own work and a LGPL'ed java library, then you must also provide a way for the user to replace the LGPL'ed portion with any subsequent version of that library. (where "subsequent version" means "any binary-compatible library the user has access to")
The means to do this would depend on exactly how you created the distribution file. If, as with some things we have made at work that used java, it is just a big zip file of java classes, a jre install, and a wrapper program to invoke java with all the appropriate arguments, then nothing need be done. (standard zip-manipulation tools let the user replace the library)
We've also occasionally done things that already had the java code in several different jar files. In this case, it's straight 6b usage and nothing extra is needed either. (but I recognize that's not what you're talking about)
If the format were some proprietary thing including signed code for tamper-resistance, then you might need to provide the user with a utility (or would it be sufficient to provide a written offer for such a utility?) that would allow them to swap out any LGPL covered portions and replace them with versions they prefer to use.
And of course there's the requirement to mention the use of the library wherever you'd normally acknowledge such things or remind the user of license terms. (about box, splash screen, etc.) However, that's not an undesireable stigma, is it?
On the other hand, if you taste Salsa Baja and say "Oh - that taste is oregano; I'll have to start adding oregano to my salsa", they won't come after you with lawyers screaming about the contract printed on your menu.
While I must admit that I found Bowling for Columbine far more amusing than illuminating, but Michael Moore would likely have a shotgun or hunting rifle.
You do realize that he's a member of the NRA, and has been since a young age? And furthermore, that Bowling for Columbine is not a multiple hour rant about the need to ban all guns everywhere?
Go watch the movie. It's fun, and it's good to see a master (and Moore is a master muckraker) at his craft.
Second, Unicode tends to have all kinds of implications deep into the implementation of a language. They touch reflection, language syntax, regular expressions, file system, pickling, I/O etc. You can call it "just" a "missing feature" but it is one big feature. I would be surprised if Ruby got proper (i.e. integrated) Unicode support before the pretty major rewrite that will also add native threads.
Actually, this is one place where I think ruby is ahead of your average scripting language currently in the not-yet-supporting-Unicode state. The whole reason that Ruby exists (as in, the original itch the creator was scratching) is that when it was created, existing scripting languages handled Japanese exceedingly poorly. As a consequence, ruby has never been developed in a "all the world is ASCII, and what isn't is latin1" environment. This gives me hope that it will be much easier to add unicode support to ruby than you might think.
In addition to what everyone else here has said, may I suggest that storing the/usr/dict/words in a list is not at all the same thing as what perl would be doing? I'm not lisper (and I welcome feadback from people who are), but it seems to me that you'd be much better off with:
(with-open-file (infile "/usr/share/dict/words")
(do ((result (make-array 100:fill-pointer 0:adjustable t) (vector-push-extend next result))
(next (read-line infile nil 'eof) (read-line infile nil 'eof)))
((equal next 'eof) result) ))
This at least lets you compare apples to apples, since a lisp vector corresponds to a perl array.
I must admit though that I've never cared too much for lisp myself - my mind just has trouble properly parsing sexps without an editor that'll show me all the matches, and on top of that looking at the dizzying array of required functions/macros/etc. for common lisp reminds me of bad times in college trying to memorize page after page of kanji characters.
The GPL specifically allows distributors (i.e., people who have accepted the GPL) to provide their own warranties or guarantees with GPL'ed software that they sell or distribute. It's one of those business models that RMS imagined would be profitable that never was (yet).
Note that this guarantee does not transfer if the person you sell GPLed software to resells/redistributes it. You get to decide your own terms for your waranties.
SUSE could easily provide a waranty for SUSE Linux that satisfied the minimum necessary requirements under German law, assuming that German law is even satisfiable. (some of the comments here make me believe that it may well be impossible to completely satisfy German law when distributing software)
Lately I've been seeing an increase in apostrophe usage pedants on slashdot. The thing is, I can't understand where they're coming from: in forming the plural of abbreviations it is perfectly acceptable to use the apostrophe. I get this from http://www.askoxford.com/asktheexperts/faq/aboutsp elling/pizza. (I admit that using an apostrophe to pluralize abbreviations that do not contain internal punctuation is not the preferred way to do it, but is still acceptable)
Now as for the use of an apostrophe in "Dell's" and "Mac's", that has a point. But please, let's keep our grammar pedantry in check; there's no need to whine about "G5's" or "TP's". After all, there are certainly enough posts that still confuse "you're" and "your" or "its" and "it's"; surely those provide much more fertile ground for grammar complaints.
Real lawyers probably would have told you about Section 117 (a) of US copyright law. Part 1 of that section specifically deals with the legal logic that the in-memory copy created by the computer when you execute a given program requires a license from the publisher.
Then again, I'm not a real lawyer, so what do I know?
This (the idea that the in-memory copy of a program made as an ordinary and essential step in using the program constitutes an action prohibited under copyright law unless you agree to a license from the publisher) is a seriously harmful meme, and as long as people accept it as true companies will be able to put any language they want in their EULA's and everyone will just shrug and say "well, that's the way it goes."
The thing is, this hasn't been true at the very least since 1987, and whether or not it was true before then is something that was never completely settled. (There was some thinking that the courts were leaning towards expanding fair use to cover this)
Barring the anti-circumvention provisions of the DMCA, you are not a criminal if you use a copy of a program lawfully obtained without agreeing to a license from the publisher. (Ever notice how the Gnu GPL very specifically does not impose any restrictions on use at all, but only on copying and redistribution? This is one of the reasons.)
Also, ever notice how most EULAs gratiously let you make a backup copy? You were already allowed to do that, before you agreed to the EULA.
The relevant piece of US law is in the copyright code, section 117 (a). It's readable online.
Slashdot Mirror
What you need is something you can point to a judge and say, "see? Clearly any reasonable human being wouldn't think this was infringing."
That's the case in the example cited at the top of the article. It's not the case in what you're proposing.
You don't want to be able to point to the lawyers and say "see, they're technically wrong." You need to be able to point to them and say "see, they're completely nuts and out of control." Remember, the law is run by humans, and most humans have a relatively short attention span. Don't appear to be taunting the lawyers who send you threat letters. Make their actions obviously unreasonable.
Do this first, and get legal precedent established to the effect the lawyers having to take some due diligence to determine which things really are infringing, and on whose copyrights. Then, push the edge a little bit. I do think that if you keep pushing slowly you can eventually get to the point where automated lawyergrams in response to the files you describe would cause trouble for the lawyers. However, the time is not yet right for taunting honeypots.
Fortunately, the lawyers use some really stupid bots, so all we may need at this point is some sort of central clearing house to coordinate all these blatantly false DMCA actions. Either that, or get a Congressional representative to introduce a provision that allows for a small claims court action to recover, say, $500 for each false claim. (For the defamation suffered) But in that event, the claim will have to be such that no reasonable and awake person could have made it; your taunting filenames still wouldn't work.
The EFF could then publish guides on filing such claims. This results in a legal DDOS on firms with stupid bots.
The result? Fewer lawyerbots, or significantly smarter ones, or both.
So how would a worm do that, absent a central point of communication? I suppose it could track reinfection attempts, and switch to DDOS mode when the number of reinfection attempts/minute gets high enough. Or I suppose it could keep some sort of generational counter that increments with every new infection, switching to DDOS mode when it has travelled through enough hosts. Of course, you wouldn't want to make it too easy for the authorities to track down patient 0...
Another idea is to read top news sites and look for certain strings - when the news media finds out, get nasty. Since this would probably cause the news media to use all sorts of euphemisms to avoid the trigger strings, maybe it should hunt through the slashdot comments - because someone will certainly post a comment of the form "I've analyzed the worm, here are the strings it's looking for:
I guess a fourth option is for the worm author (or someone associated with the worm author) to trigger it themselves. Say, when the worm connects to port 4444 to send the command to tftp over a copy, they get back a string saying "it's time". Then that host (and any host which later tries to reinfect it, etc.) switches to DDOS mode. Since this would only be necessary once, it'd be almost untraceable. (Especially if done through one of those wide open socks proxies the spammers are always using) This option, combined with a procedure for cryptographically signing updates, actually has some possibilities for generic updates to the worm.
It occurs to me that the worm author needn't have targetted windows update. Imagine if this worm appeared to have originated from inside Microsoft and targetted Microsoft's large enemies (IBM, RedHat, the AG office of the states who are still suing them, some EU agencies, etc.) I wonder if the political fallout from that would be noticeable?
You link it statically, right? Because there have occasionally been buffer overflow issues in ld.so...
Even avoiding ld.so overflows, there's still the libc5 to libc6 transition, and a hello world compiled under libc5 just won't run on a modern (libc5 compatibility removed) linux box.
As for static binaries becoming obsolete, I suppose we'll have to wait for a kernel that has dropped a.out support. That will probably happen at some point.
In the form you described, yes.
It is a significantly more gray area if you were to listen for attempts on your machine and, after receiving an active probe (not just a SYN packet, because single SYNs are very fakeable), hit the attacking machine with something that used this vulnerability to wipe out the virus.
If you want to stretch things, it might even be acceptable to then download and install the microsoft security patch (although that's pushing things a bit). Maybe. Much more acceptable would be to replace the worm with something that looked sufficiently like the worm to prevent re-infection, but did nothing.
However, creating and releasing a "beneficial virus" is just flat out illegal and dangerous. Have you ever written code that worked exactly as it was supposed to, on systems you've never seen? Have you ever gotten a piece of code bug-free before the first large test? Have you ever created a binary that someone could look at and easily verify behaved exactly as advertised?
The idea is that so long as you are disarming a machine that has directly attacked one of your machines, you are on defensible moral (IANAL, so I won't talk about legal) ground. However, forcing an update on a third party, or even doing more than the minimum necessary to disarm the machine attacking you, places you in the same category as the original virus writer - you cannot know all the effects of your actions, therefore doing more than the absolute minimum necessary is irresponsible.
Probably the same stuff that was being smoked near any place shipping a unix operating system - remember "talk"? The internet used to be a much calmer place. (Actually, I haven't done a default install of any linux distro in ages - does redhat install talk-server by default?)
Now, had you added "in 2003" or "in this day and age" to your comment
See, now I'd inline the whole table if you're only using it once:
/^[yn]$/i) {
print "Would you use a hash as a switch statement? (y/n) ";
my $answer = <STDIN>;
if ($answer !~
print "You've reached the default\n";
} else {
chomp $answer;
{
'y' => sub {print "You code too much perl!\n";},
'n' => sub {print "You don't use enough perl!\n";}
}->{lc $answer}->();
}
It links to a non-existant page. Is there another source for what you were pointing to?
Probably not, but his statement of the situation squares with my experience when I talked to an FBI agent after having discovered (and logged) some IRC kiddies who were constructing a DDOS network out of sub7-infected machines.
I'd created a sub7 honeypot on my linux box with a little perl script; after that collected the IRC server ip and channel name, I connected with a random username (pretending to be a bot) and just logged the conversation.
The FBI agent interviewed me very carefully to make certain that my setting up monitoring, etc., was not in any way instigated by a law enforcement officer. (No, I'd just gotten annoyed at random SYN packets) Then, he had no trouble with it. I don't know if this makes the evidence I provided useable legally, but it never came to that. As he explained it, the question was whether I was acting as an agent of the state when setting up the honeypot. Committing entrapment is not anything that non-state actors ever need worry about.
Not that this lets you off the hook entirely - there may be charges of wiretapping involved; monitoring your own machine should be safe legal ground, but connecting to the IRC network (as I did) is a slight bit more dicey legally, and shouldn't be done if you have any reason to believe that the relevant prosecutor would like to hang something on you as well.
Why isn't that illegal?
Because they have lawyers sending out the letters who very carefully know the barratry statutes in the different states they're sending these letters to. I'm willing to bet that any "pay up or else" letter (the existence of which I am beginning to doubt, by the way) would be very carefully worded to be just on the legal side of the statutes.
There's a specific legal term for threatening baseless legal action: barratry.
The precise legal definitions of barratry vary from state to state, and I'm not in any kind of position to evaluate whether SCO might or might not be in violation of one of those laws. (Being neither a lawyer nor someone who has gotten a "pay up or else" notice for use of Linux)
Estonia especially, since he mentioned Finnish and Hungarian, the other two European descendants of what was once Mongolian.
Ok, I think I see the difference in our positions: if I'm getting paid for a copy of my code, I don't really care what the user does with it. They still can't redistribute it to someone else (legally), and are free to attack it with a hex editor all they want. (Just so long as they don't expect me to put it back together) Note that it doesn't make a difference to Id Software if someone patches their own DOOM wad files so that the bad guys look like Barney.
Similarly, if I had enough woodworking skill to build a chair I doubt I'd care if the customer who bought it went out and spray-painted it a hiddeous shade of lime green, though the color itself might keep me away from their living room. Likewise, with people buying a book and then whiting out passages they disagree with - so long as they do it to their own copy, no harm done. (except possibly to themselves)
I look at it this way: the right you're arguing over is the right of a customer to take a hex editor to files sitting for the moment on their own computer. This is something they're going to do anyway. You need to accept this, just as you need to accept the idea that people will look at the html source of your web pages. The lack of a legal right to do so (some sites' user agreements try to remove this) isn't going to make one bit of difference. Until they redistribute something, 1) there's no way you're going to know, and 2) they haven't entered into activity that is covered by copyright law anyway. (cf. home censoring of DVD movies)
Note that the right to modify stuff privately is very, very different from the right to redistribute the modified or original code in any way. Requiring the right to modify personal copies is not at all the same as requiring you "to give it away." Going back to the example of the Barney Doom patches, their existence (and, to some extent, toleration) did not in any way weaken Id's protections over their software or their bottom line.
Also, I will note a slight misunderstanding in your view of the GPL: private modifications need not be released. If you have a GPLed program, and modify it in some cool way, and even share the modifications with a few friends, you do not need to distribute the modified code except to those few friends. You do not need to tell the original author that you liked his code, that you're using it, or how you modified it. Note that the requirement that private modifications be released to the original author was one of the issues RMS had with some of the early versions of the NPL.
As you appear to be concerned about the position of a shareware games developer, note that under the LGPL section 6 it would be perfectly acceptable to distribute an application and say "you may modify this for your own use on your own machine, but you can only give away a copy of the unmodified version". (possibly at this point specifying checksums and archive filenames) If your game is distributed as a single self-installing executeable, this line is easy enough to draw: they can't redistribute what gets put on their disk during installation, but are free to pass along the original executeable.
Or, in this day and age, "you may modify this but you can't redistribute it - instead, point your friends to http://www.mysite.com for the latest trial version. Encourage your friends to register, too!"
That's what the command montage, part of the IM suite, is for. Check (as always) the man page for montage, and look at the -chop option (which lets you cut out rows or columns from one of the images before sticking them together).
I see. So the fact that it is difficult for them to do so (you didn't after all hand them the source) makes no difference?
That is, you appear to be placing great emotional weight on the idea that the user should not have the legal right to modify their copy of the bits that constitute your work.
Is it the fact that the user might change their copy what offeends you?
Or is it the second half of that sentence, that the user might while debugging discover the full details of how your software works?
Or is it the legal hassle that many proprietary libraries (and/or management) will impose a "must forbid reverse engineering" clause on you while the LGPL imposes a "must allow reverse engineering sufficient to debug modifications" clause?
If your normal software license is of the draconian "modify a single bit of this software only under pain of death" type, then you have to modify your license to allow the user some basic freedoms. (The right to modify the binary code on their machine and the right to reverse engineer to the extent necessary to debug said modifications)
Of course, depending on country and state laws where the consumer is, they may have this freedom already. And even if they don't, a legal notice isn't going to stop someone with a hex editor.
Could you kindly tell me what exactly this hole is?
Is it really that important to you that your clients/customers be unable to discover that you used a piece of LGPL'ed code? Is it important that they be unable to discover how you used that library?
As I see it (prizog, please correct this), the situation is this:
If you create a single distribution file containing both your own work and a LGPL'ed java library, then you must also provide a way for the user to replace the LGPL'ed portion with any subsequent version of that library. (where "subsequent version" means "any binary-compatible library the user has access to")
The means to do this would depend on exactly how you created the distribution file. If, as with some things we have made at work that used java, it is just a big zip file of java classes, a jre install, and a wrapper program to invoke java with all the appropriate arguments, then nothing need be done. (standard zip-manipulation tools let the user replace the library)
We've also occasionally done things that already had the java code in several different jar files. In this case, it's straight 6b usage and nothing extra is needed either. (but I recognize that's not what you're talking about)
If the format were some proprietary thing including signed code for tamper-resistance, then you might need to provide the user with a utility (or would it be sufficient to provide a written offer for such a utility?) that would allow them to swap out any LGPL covered portions and replace them with versions they prefer to use.
And of course there's the requirement to mention the use of the library wherever you'd normally acknowledge such things or remind the user of license terms. (about box, splash screen, etc.) However, that's not an undesireable stigma, is it?
No, they aren't.
On the other hand, if you taste Salsa Baja and say "Oh - that taste is oregano; I'll have to start adding oregano to my salsa", they won't come after you with lawyers screaming about the contract printed on your menu.
While I must admit that I found Bowling for Columbine far more amusing than illuminating, but Michael Moore would likely have a shotgun or hunting rifle.
You do realize that he's a member of the NRA, and has been since a young age? And furthermore, that Bowling for Columbine is not a multiple hour rant about the need to ban all guns everywhere?
Go watch the movie. It's fun, and it's good to see a master (and Moore is a master muckraker) at his craft.
Actually, this is one place where I think ruby is ahead of your average scripting language currently in the not-yet-supporting-Unicode state. The whole reason that Ruby exists (as in, the original itch the creator was scratching) is that when it was created, existing scripting languages handled Japanese exceedingly poorly. As a consequence, ruby has never been developed in a "all the world is ASCII, and what isn't is latin1" environment. This gives me hope that it will be much easier to add unicode support to ruby than you might think.
I must admit though that I've never cared too much for lisp myself - my mind just has trouble properly parsing sexps without an editor that'll show me all the matches, and on top of that looking at the dizzying array of required functions/macros/etc. for common lisp reminds me of bad times in college trying to memorize page after page of kanji characters.
The GPL specifically allows distributors (i.e., people who have accepted the GPL) to provide their own warranties or guarantees with GPL'ed software that they sell or distribute. It's one of those business models that RMS imagined would be profitable that never was (yet).
Note that this guarantee does not transfer if the person you sell GPLed software to resells/redistributes it. You get to decide your own terms for your waranties.
SUSE could easily provide a waranty for SUSE Linux that satisfied the minimum necessary requirements under German law, assuming that German law is even satisfiable. (some of the comments here make me believe that it may well be impossible to completely satisfy German law when distributing software)
Lately I've been seeing an increase in apostrophe usage pedants on slashdot. The thing is, I can't understand where they're coming from: in forming the plural of abbreviations it is perfectly acceptable to use the apostrophe. I get this from http://www.askoxford.com/asktheexperts/faq/aboutsp elling/pizza. (I admit that using an apostrophe to pluralize abbreviations that do not contain internal punctuation is not the preferred way to do it, but is still acceptable)
Now as for the use of an apostrophe in "Dell's" and "Mac's", that has a point. But please, let's keep our grammar pedantry in check; there's no need to whine about "G5's" or "TP's". After all, there are certainly enough posts that still confuse "you're" and "your" or "its" and "it's"; surely those provide much more fertile ground for grammar complaints.
Real lawyers probably would have told you about Section 117 (a) of US copyright law. Part 1 of that section specifically deals with the legal logic that the in-memory copy created by the computer when you execute a given program requires a license from the publisher.
Then again, I'm not a real lawyer, so what do I know?
This (the idea that the in-memory copy of a program made as an ordinary and essential step in using the program constitutes an action prohibited under copyright law unless you agree to a license from the publisher) is a seriously harmful meme, and as long as people accept it as true companies will be able to put any language they want in their EULA's and everyone will just shrug and say "well, that's the way it goes."
The thing is, this hasn't been true at the very least since 1987, and whether or not it was true before then is something that was never completely settled. (There was some thinking that the courts were leaning towards expanding fair use to cover this)
Barring the anti-circumvention provisions of the DMCA, you are not a criminal if you use a copy of a program lawfully obtained without agreeing to a license from the publisher. (Ever notice how the Gnu GPL very specifically does not impose any restrictions on use at all, but only on copying and redistribution? This is one of the reasons.)
Also, ever notice how most EULAs gratiously let you make a backup copy? You were already allowed to do that, before you agreed to the EULA.
The relevant piece of US law is in the copyright code, section 117 (a). It's readable online.