In other words open source that REQUIRES closed source to use is not open source at all.
That certainly depends on what you mean by requires. If the license says, you must use it together with a closed source product, then it does not match the definition of open source. But if an open source product happen to technically depend on some Windows API, but is released under an open source license, then it is still open source. Anybody are allowed to take such a product and remove the dependencies on that API and make it work on some other systems (known as porting). And being allowed to do things like that is exactly what open source is all about.
I wonder if it would be easy to port it to windows and macosx? IT would be cool for hardware makers to have a driver that works with all operating systems with minimal effort in porting. Costs are one of the issues besides the difficulty in porting windows drivers to linux which many makers do not bother doing.
It might help a bit. But for a lot of hardware they are not going to be shipping this driver for Windows. If possible they are going to ship a user mode driver to be able to claim that their hardware works with "every" operating system. And they are going to be shipping a real Windows driver. And "everybody" is going to say Linux performance sucks because Linux only have user mode drivers, where Windows have real kernel drivers. (Of course the same people are going to blame Microsoft for every time the driver crash their system).
Of course for some hardware performance is not all that important. As long as the driver will be locked in memory, it won't matter if something like a keyboard driver was done in user mode. Hell, in recent years lots of hardware have been designed that will require the driver to spend loads of CPU time, because that could shave a few cents of the hardware cost. Such hardware would be slow on any operating system, kernel driver or not.
When dealing with the physical world, even on a quantum level, it is often hard to get a perfectly even probability split between two (or more) values.
That is actually not a problem, as long as you can repeat the meassurement and get independent equally distributed results. The simplest solution is the following: Take two bits from your source, if they are identical throw them away. If they are different, output the first and throw the second away. Your output will obviously be shorter, at least a factor of four, and even more on a skewed input. But the output will have ones and zeros with the same probability. The approach can be generalized to working with more bits at a time, but then gets more complicated.
Decide on a fixed length of blocks to split your original bits into. When given a block of bits, compute the number of possible permutations of those exact bits, and use the binary representation to group the permutations into sets of sizes a power of two. Then by numbering the elements in this set you get the output bits to produce. It may be easier to follow from an example. I take groups of four input bits. If I happen to get something with two ones and two zeros, I compute that there are six possible permutations. That is 4+2 so I have one group of four equally likely permutations that will give me two output bits, and another of just two that will give me one output bit:
0011 => 00
0101 => 01
0110 => 10
1001 => 11
1010 => 0
1100 => 1
OTOH if I got only a single one and three bits in the input there are exactly four distributions, and I always get two bits of output:
0001 => 00
0010 => 01
0100 => 10
1000 => 11
Likewise if I got a single zero and three ones. If I were so unlucky to get four identical bits there is only a single permutation, which means I get zero output bits. So in the end if the input happened to have zero and one equally likely you would get 1.625 output bits for every four output bits, which is 62.5% better than with half the block size. Of course again, with a skewed input the gain will decrease. As the block size grows, your gain will converge towards the real entropy of your input (even if you don't know how large that is). But larger blocks means you'd have to do more computation or have larger lookup tables. So there may be a limit to how large blocks you can use. The block size does not change the quality of your result, only the quantity.
Patents were never supposed to make money
on
Patents Don't Pay
·
· Score: 5, Insightful
The purpose of patents were to improve inovation and make the results available to society. Before patents were introduced, people would try to protect their inventions by keeping the details as secret as possible. Patents are supposed to get them to reveal the details by getting a timelimited monopoly in return. Then others can keep inovating by building on top and eventually the inventions will become free for everybody to use. And anybody who sticked with the old habbit of keeping the details secret rather than patenting it would run the risk of somebody else being granted a patent on the intention.
That is how it was supposed to work in the theory.
In reality we see abuse such as companies patenting things they didn't really invent, companies patenting trivialities, and patents that don't include all the details which were the purpose of patents in the first place. If software patents weren't bad enough in itself, it is made even worse by them not containing the full source of a working implementation. If patent applications were really being treated within the original spirit of patents, any software patent application not comming with the full source would be rejected. And of course once the patent is granted, the source is published available for anybody to use as long as they have a licensee for the patent. Once the patent expires, the source can be used essentially the same way you can use BSD licensed source.
Somebody seems to have forgotten why patents were introduced. And some companies seems to want to not only keep, but also extent patents (and copyright as well) because they want to make money from it. If making money is the only reason for keeping those kinds of protections in place, they should be abandoned. But for gods sake, don't make the big mistake of abandoning them only for economical reasons. Rather think the system over again and adjust it to serve its original purpose, even if that means companies will make less money on average.
US Citizens would get the first interval for free, and always be one multiple of $10 behind non-citizens which includes corporations. [...] But these are just minor details, and I'll be glad to tweak them however you like if it will get your vote:-)
In that case let's make it EU citizens, then you can get my vote.
Re:I was hooked until the guy showed his ls skills
on
iPods Don't Run OS X
·
· Score: 1
-f supposedly omits the default alphabetical sorting (though it doesn't seem to have any effect when I tried it).
What file system are you using? A file system can achieve the best performance if it sorts the names internally, but it doesn't have to be alphabetically though, might as well be based on the length of the file name and a hash of the characters. Using ls with -f is going to be kernel and file system dependent. Even if you happen to be using one of those file systems that doesn't sort file names, it could also be the case, that you were in a directory where the files had been copied to in alphabetical order.
What you are saying is probably right, but I really wouldn't worry about that. So what if somebody can take a 14 year old version of a piece of open source software and use it in a closed product. In reallity a lot of improvements will have happened over that time, and the new code will still be covered by copyright. If no improvements have happened, it would mean one of two things. Either it has been abandoned because it is obsolete, or it has finally become perfect such that there is no way to improve it anymore. The later is of course highly unlikely to happen, but if a piece of code actually did become perfect,you wouldn't need the source anyway.
I like the idea except that I think the first five years should be free. First of all it will save a lot of bureaucracy, and the 1$ is just symbolic anyway (but the later payments are not). But much more important is the fact that it takes time to produce a work. What if you let somebody see an unfinished version? Could they freely copy it, because you had not payed the one dollar yet? But after five years you can decide if you have something, which can really be considered a work, and whether it is worth paying 10$ for protecting. And if you are not yet finished after five years, I sure hope you are sure the final result is going to be worth more than 10$, because otherwise, I'd say you had been wasting a lot of time.
"fork while fork" won't have the exponential effect, since fork returns 0 (false) in the child process, terminating the loop and causing growth to only be linear.
It only terminates every other time, so you'd still get exponential grow. Actually if you wanted to be a bit more nasty, you'd terminate the parent after every second fork. Because then there would be less connection between your processes, and you'd still get exponential growth, but no single process lives for more than a few system calls.
Free Software Foundation, The holder of Linux Copyrights
Linux is copyrighted by the people who wrote it. FSF has nothing to do with it. If somebody want to use Linux in a way not permitted by the license, they need to get permission from every single developer, otherwise any developer can sue.
The objective of the game would be to develop the best program to play the game.
That kind of games are fun for those of us who know how to code. Most of the gamers out there wouldn't stand a chance in a game that involved coding in order to play it. But there still remains a few questions, do you run the program on your own machine talking to a server? If so, is the program supposed to play by itself, or is each player going to be a person and a program cooperating? Are people with a beafy machine and a fast Internet connection supposed to have an advantage? You probably cannot design it such that they will not have an advantage. Alternatively, you submit your program, and everything is then run in a controlled environment.
Getting one proprietary product to play well with others can be a challenge. You want to proprietary products from two different vendors to play well together. I'm afraid you are not in for an easy task. Your problem is exactly the reason why people are talking so much about openness.
I suspect a lot of that can be attributed to the market demand, rather than an actual technological limit. The size of the hard-drive is it's main metric, and the only thing that consumers look at
It is not just a question of demand, but also what specs are actually provided. In many cases it doesn't say anywhere what the transfer rate on the disk is, that is something you will only know once you have bought the disk. If the manufacturers wanted to, they could tell what the minimum guaranteed transfer speed was. Eventually customers will have to consider this, because if the current trend continues, at some point the capacity will no longer matter when the transfer speed is too slow to fill the entire disk within its lifetime. Of course that is still far away, too far away for most people to worry.
At the end of the day, what would you rather have
With those options, I'd take an array of IDE disks rather than SCSI any day. Let's for a momemnt consider what are the advantages of that SCSI disk over an IDE disk. Maybe the transfer rate is higher, but it is not twice as high, so an array of IDE disks would still be able to match the transfer rate of the SCSI disk. The SCSI disk may have lower seek times, but like I already said, that is less of a concern for me. A sequential read of the SCSI disk will probably be significantly faster than the IDE disk, but that is mainly because the SCSI disk is going to have a smaller capacity. I really don't see that as an advantage:-)
Without eliminating one or both of these delays, I don't see how this leads to faster secondary storage access in practice.
Those delays may be a bit inconvenient, but they are not a major problem. For more than a decade, we have more or less known how to deal with them. Yes, a bit of research is still happening in this area, mainly for two reasons. We want to do things with disks that we didn't always do, such as virtual memory. The other reason is, that as CPU spees have grown faster than disk speeds, the most efficient file system designs are not the same as a decade ago.
Currently we have a much greater problem than seek times. Disk capacity is growing faster than transfer speed! That means the time to read (or write) a disk from end to end (that means without seeks) will grow with every new generation of disks. A decade ago you could read an entire disk sequentially in about 20 minutes, today it takes hours. During the last decade the transfer speeds have not grown by a factor of 100. A decade ago a new disk could transfer a few MB/s. Today they I have not yet come across a single disk that could do 100MB/s. If the next decade will give us a 100 times improvement in transfer speeds, it is much welcome, because we need it.
Sure it may mean we want to do file systems with larger block sizes. They already have grown from a typical 512 bytes to 4KB now being typical. (At some point 32KB was common, but was so because of shortcommings in the file system rather than performance reasons). Sure we'll have to solve problems such as how to boot an operating system or load an application with as few seeks as possible, but we are slowly getting there already. And once we get computers with 128GB of RAM, it will be nice being able to suspend to disk and resume from disk in less than 20 seconds.
Is your ISP going to be able to get a cert issued to them with the hostname "www.bankofamerica.com"? Unlikely.
My ISP happens to also be a CA, and my bank happens to be using that CA. How difficult would it be for that ISP to generate certificates on the fly? Of course it would be difficult to do so without anybody noticing, and as soon as such a practice got known, all browsers should pull their root certificate, which could be the end of their CA business. But of course CAs getting away with bad practices is not unheard of. I guess nobody wants to be the first to remove a root certificate, as from the user's point of view, this could look as lost functionality.
However, what the ISP could do is just strip the SSL protection.
That only works for those 90% of the users who doesn't understand how https works. Those 10% who understands how it works will notice, or even just use https from the very beginning leaving no opertunity to force it back to http.
I suspect that MS will wind up using partnerships with hardware vendors to write proprietary Linux hardware drivers, release them binary-only and compile them into the kernels of their minion-distributions by default, thus giving the sell-out distros an functional advantage over the pure distros.
Doing so would be a very clear violation of copyright. If anybody starts selling such a distribution, I predict they will receive a cease and desist letter from some Linux developers. (I might consider writing it myself, but probably some larger contributor would do so before me).
Furthermore, users of the pure distros won't be able to swipe or reverse-engineer the binaries without being at risk for infringement lawsuits.
That depends on where they live. There are countries that have a law that clearly states such reverse engineering is legal, and the right to reverse engineer cannot be given up by a contract.
In effect you are suggesting that the copyright violator sues the copyright owners over something the owners does with their own code, which would be legal in many parts of the world even if they didn't own the code in the first place.
Yeah, if you've gotten past Newtonian physics you'll realize that maintaining that 1 G is a wee bit of a problem as v approaches c.
That depend on which point of view you see the acceleration from? Having the space ship accelerate at 1G as seen from an observer on board the space ship, shouldn't be that much of a problem (assuming you have enough fuel). But seen from an observer on Earth, the acceleration will slow down. Seen from either point of view, the speed at which the two objects move away from each other will never actually reach c no matter for how long you accelerate at 1G.
I found that the answers I could find in other postings were all slightly inaccurate. So here goes my attempt at answering as accurate as I can possibly do.
1. Can I do it with Linux today (GPL2)
If you really don't link against any third party libraries and only depnd on the kernel, no problem at all, you can just go ahead and do it. The license coming with Linux clearly states that this is OK. And my interpretation is, that they couldn't have forbidden you from doing this, even if they wanted to.
and tomorrow (GPL3)?
Since Linux is explictly licensed under GPL version 2 only, nothing is likely to change. After all changing Linux from GPL version 2 to GPL version 3 would require every author's permission. (Or the code would have to be identified and replaced).
Even if the kernel or libraries you depend on are switching to GPL version 3, you could still be using the old GPL version 2 versions to build your software. If it happens to still work with later versions (and if you depend only on the kernel it is very likely to work), that is none of your fault. It is the users who decide to run your software together with some GPL version 3 code. And it is highly unlikely that the user would be doing anything illegal by doing so, since forbidding that would go completely against the spirit of the GPL.
2. Can I statically link the code with Linux libraries?
Strictly speaking there is nothing called Linux libraries. What you have in mind is probably glibc, which is licensed under LGPL. This license allows static linking provided that you allow the end user to relink it against a different version of the library. So you'd have to include not only the linked executable, but also the.o files, such that the user can do the final linking step against a different version. If you are going to ship the software on a CD, do the customer a favor and include the original tarball of the glibc version used (I'm not sure if you are legally required to include it). If the user downloads it over the Internet, give them a link from where they can download the tarball if they want to.
(My own experience shows that dynamic linking is too much to bear.)
If you are talking about glibc, keep in mind that it is not easy to link statically. If you try, you are very likely to end up with only parts of glibc linked statically and other parts still linked dynamically. This is going to break if the user is using a different version of glibc, because internal interfaces may have changed.
Relying on dynamic linking might be a much easier way to go. If you are unsure avoid linking against GPL libraries. People disagree on whether a closed source program is allowed to dynamically link against a GPL library (I believe it is legal, but IANAL). Statically linking a GPL library into a closed source program is clearly a copyright violation.
3. Can I obfuscate my code (e.g. encode it)?
What would the point be in that if you only intend to publish the compiled code?
4. Could I be forced to publish this code by some 3-d party?
Probably not. If you are violating a third party's copyright, they can sue you. But only the author whose copyright you violated can sue you. In such a case you should obviously be stopped from distributing violating code, and may have to pay some compensation. But as long as you are able to pay a reasonable compensation, I don't see how you could be forced to give them code as well.
5. Am I correct that programming in and selling BSD-based boxes won't raise any of the above problems?
I'd say you are unlikely to run into problems in that case as well. It all comes down to which libraries you link against. If you use the same libraries on both platforms, you will have the same potential problems.
Only if the median happens to be identical to the average, which is by no means guaranteed. My guess is the average is higher than the median. There will be a few very briliant people to pull up the average. There could also be a few very stupid people to pull down the average, but they won't have this profession. So I guess the majority is just a bit below average.
Exactly. SMTP already does this. Problem is, in the name of spam fighting, people started randomly and silently dropping emails. If you don't want to deliver an email at least produce an appropriate error response. It's not that hard to respond with an error code at the end of DATA, if you don't want to deliver it. That way the sender will at least know why it was not delivered. And before anybody starts complaining, that this will just produce lots of invalid bounces, I'd like to point out, that they are easy to prevent. A bounce is easy to identify from the empty sender, when you see one look inside the data for a Message-ID matching one that was sent from this account in the last 14 days. If none is found this is a bounce of a mail with a forged sender address, refuse to accept the mail. Oh, and if you see log entries on your own mail server indicating, that it couldn't deliver bounces, then at least you are one step closer to the source, that the person who rejected them. That means it is time to figure out why your mail server accepted the messages in the first place. Eventually the spam will be stopped at the source.
Well, that is the theory at least. The problems are: People don't respect the protocols. Very few actually try to stop the spam at the source, since you don't make a lot of money from that. And for ISPs being a good netcitizen have a far lower priority than making money.
Sure but how many users have that installed already? It's a matter of native support if they want mass adoption, not some third party option being available that grandma won't or can't figure out how to load.
Considering that just about every USB unit one can by nowadays come with a driver disk for Windows, it doesn't seem anybody would consider that a problem. Besides if this is standardized, systems will soon start including the necesarry driver by default. Keep using FAT16 isn't an option anyway since it only supports devices smaller than 2GB.
Now my opinion is that if it works at all it must be a valid email address character, can any email junkies comment?
It is a valid character in the local part of an email address. The original RFC allowed all 7-bit ascii characters (yes all 128 of them including such things as the NUL character and newline), though some of them had to be escaped, and escaping was generally discouraged. A later revision did reduce the set of allowed characters slightly. But it is still very liberal (ascii 32-126 is allowed). + is a valid character in the local part of the address. And it is generally up to the individual domain how the local part is interpreted. An implementation is allowed to impose restrictions on its own local part, but not the ones it communicate with. So a mail provider could decide that they would only allow usernames which are exactly 8 characters long and consist of letters from the range a-y, but they'd still have to allow you to communicate with addresses looking differently in order to conform with the RFC.
people just sending email to random addresses at my domain.
There are ways to deal with that. It seems you will often see the same few addresses tried over again and again. On my own domain I am filtering info@, sales@, and webmaster@ and allowing just about everything else. For a long time I haven't seen any of those random names. In case it should happen I'll switch to a whitelist of generated addresses rather than allowing everything by default. I have a script ready, which will generate a unique address for me. Actually I have two different versions one that expires after a certain number of days, and one which does not expire.
Slashdot Mirror
Of course for some hardware performance is not all that important. As long as the driver will be locked in memory, it won't matter if something like a keyboard driver was done in user mode. Hell, in recent years lots of hardware have been designed that will require the driver to spend loads of CPU time, because that could shave a few cents of the hardware cost. Such hardware would be slow on any operating system, kernel driver or not.
Decide on a fixed length of blocks to split your original bits into. When given a block of bits, compute the number of possible permutations of those exact bits, and use the binary representation to group the permutations into sets of sizes a power of two. Then by numbering the elements in this set you get the output bits to produce. It may be easier to follow from an example. I take groups of four input bits. If I happen to get something with two ones and two zeros, I compute that there are six possible permutations. That is 4+2 so I have one group of four equally likely permutations that will give me two output bits, and another of just two that will give me one output bit:
- 0011 => 00
- 0101 => 01
- 0110 => 10
- 1001 => 11
- 1010 => 0
- 1100 => 1
OTOH if I got only a single one and three bits in the input there are exactly four distributions, and I always get two bits of output:- 0001 => 00
- 0010 => 01
- 0100 => 10
- 1000 => 11
Likewise if I got a single zero and three ones. If I were so unlucky to get four identical bits there is only a single permutation, which means I get zero output bits. So in the end if the input happened to have zero and one equally likely you would get 1.625 output bits for every four output bits, which is 62.5% better than with half the block size. Of course again, with a skewed input the gain will decrease. As the block size grows, your gain will converge towards the real entropy of your input (even if you don't know how large that is). But larger blocks means you'd have to do more computation or have larger lookup tables. So there may be a limit to how large blocks you can use. The block size does not change the quality of your result, only the quantity.The purpose of patents were to improve inovation and make the results available to society. Before patents were introduced, people would try to protect their inventions by keeping the details as secret as possible. Patents are supposed to get them to reveal the details by getting a timelimited monopoly in return. Then others can keep inovating by building on top and eventually the inventions will become free for everybody to use. And anybody who sticked with the old habbit of keeping the details secret rather than patenting it would run the risk of somebody else being granted a patent on the intention.
That is how it was supposed to work in the theory.
In reality we see abuse such as companies patenting things they didn't really invent, companies patenting trivialities, and patents that don't include all the details which were the purpose of patents in the first place. If software patents weren't bad enough in itself, it is made even worse by them not containing the full source of a working implementation. If patent applications were really being treated within the original spirit of patents, any software patent application not comming with the full source would be rejected. And of course once the patent is granted, the source is published available for anybody to use as long as they have a licensee for the patent. Once the patent expires, the source can be used essentially the same way you can use BSD licensed source.
Somebody seems to have forgotten why patents were introduced. And some companies seems to want to not only keep, but also extent patents (and copyright as well) because they want to make money from it. If making money is the only reason for keeping those kinds of protections in place, they should be abandoned. But for gods sake, don't make the big mistake of abandoning them only for economical reasons. Rather think the system over again and adjust it to serve its original purpose, even if that means companies will make less money on average.
What you are saying is probably right, but I really wouldn't worry about that. So what if somebody can take a 14 year old version of a piece of open source software and use it in a closed product. In reallity a lot of improvements will have happened over that time, and the new code will still be covered by copyright. If no improvements have happened, it would mean one of two things. Either it has been abandoned because it is obsolete, or it has finally become perfect such that there is no way to improve it anymore. The later is of course highly unlikely to happen, but if a piece of code actually did become perfect,you wouldn't need the source anyway.
I like the idea except that I think the first five years should be free. First of all it will save a lot of bureaucracy, and the 1$ is just symbolic anyway (but the later payments are not). But much more important is the fact that it takes time to produce a work. What if you let somebody see an unfinished version? Could they freely copy it, because you had not payed the one dollar yet? But after five years you can decide if you have something, which can really be considered a work, and whether it is worth paying 10$ for protecting. And if you are not yet finished after five years, I sure hope you are sure the final result is going to be worth more than 10$, because otherwise, I'd say you had been wasting a lot of time.
Getting one proprietary product to play well with others can be a challenge. You want to proprietary products from two different vendors to play well together. I'm afraid you are not in for an easy task. Your problem is exactly the reason why people are talking so much about openness.
With those options, I'd take an array of IDE disks rather than SCSI any day. Let's for a momemnt consider what are the advantages of that SCSI disk over an IDE disk. Maybe the transfer rate is higher, but it is not twice as high, so an array of IDE disks would still be able to match the transfer rate of the SCSI disk. The SCSI disk may have lower seek times, but like I already said, that is less of a concern for me. A sequential read of the SCSI disk will probably be significantly faster than the IDE disk, but that is mainly because the SCSI disk is going to have a smaller capacity. I really don't see that as an advantage
Currently we have a much greater problem than seek times. Disk capacity is growing faster than transfer speed! That means the time to read (or write) a disk from end to end (that means without seeks) will grow with every new generation of disks. A decade ago you could read an entire disk sequentially in about 20 minutes, today it takes hours. During the last decade the transfer speeds have not grown by a factor of 100. A decade ago a new disk could transfer a few MB/s. Today they I have not yet come across a single disk that could do 100MB/s. If the next decade will give us a 100 times improvement in transfer speeds, it is much welcome, because we need it.
Sure it may mean we want to do file systems with larger block sizes. They already have grown from a typical 512 bytes to 4KB now being typical. (At some point 32KB was common, but was so because of shortcommings in the file system rather than performance reasons). Sure we'll have to solve problems such as how to boot an operating system or load an application with as few seeks as possible, but we are slowly getting there already. And once we get computers with 128GB of RAM, it will be nice being able to suspend to disk and resume from disk in less than 20 seconds.
That only works for those 90% of the users who doesn't understand how https works. Those 10% who understands how it works will notice, or even just use https from the very beginning leaving no opertunity to force it back to http.
That depends on where they live. There are countries that have a law that clearly states such reverse engineering is legal, and the right to reverse engineer cannot be given up by a contract.
In effect you are suggesting that the copyright violator sues the copyright owners over something the owners does with their own code, which would be legal in many parts of the world even if they didn't own the code in the first place.
If you really don't link against any third party libraries and only depnd on the kernel, no problem at all, you can just go ahead and do it. The license coming with Linux clearly states that this is OK. And my interpretation is, that they couldn't have forbidden you from doing this, even if they wanted to.
Since Linux is explictly licensed under GPL version 2 only, nothing is likely to change. After all changing Linux from GPL version 2 to GPL version 3 would require every author's permission. (Or the code would have to be identified and replaced).
Even if the kernel or libraries you depend on are switching to GPL version 3, you could still be using the old GPL version 2 versions to build your software. If it happens to still work with later versions (and if you depend only on the kernel it is very likely to work), that is none of your fault. It is the users who decide to run your software together with some GPL version 3 code. And it is highly unlikely that the user would be doing anything illegal by doing so, since forbidding that would go completely against the spirit of the GPL.
Strictly speaking there is nothing called Linux libraries. What you have in mind is probably glibc, which is licensed under LGPL. This license allows static linking provided that you allow the end user to relink it against a different version of the library. So you'd have to include not only the linked executable, but also the
If you are talking about glibc, keep in mind that it is not easy to link statically. If you try, you are very likely to end up with only parts of glibc linked statically and other parts still linked dynamically. This is going to break if the user is using a different version of glibc, because internal interfaces may have changed.
Relying on dynamic linking might be a much easier way to go. If you are unsure avoid linking against GPL libraries. People disagree on whether a closed source program is allowed to dynamically link against a GPL library (I believe it is legal, but IANAL). Statically linking a GPL library into a closed source program is clearly a copyright violation.
What would the point be in that if you only intend to publish the compiled code?
Probably not. If you are violating a third party's copyright, they can sue you. But only the author whose copyright you violated can sue you. In such a case you should obviously be stopped from distributing violating code, and may have to pay some compensation. But as long as you are able to pay a reasonable compensation, I don't see how you could be forced to give them code as well.
I'd say you are unlikely to run into problems in that case as well. It all comes down to which libraries you link against. If you use the same libraries on both platforms, you will have the same potential problems.
Exactly. SMTP already does this. Problem is, in the name of spam fighting, people started randomly and silently dropping emails. If you don't want to deliver an email at least produce an appropriate error response. It's not that hard to respond with an error code at the end of DATA, if you don't want to deliver it. That way the sender will at least know why it was not delivered. And before anybody starts complaining, that this will just produce lots of invalid bounces, I'd like to point out, that they are easy to prevent. A bounce is easy to identify from the empty sender, when you see one look inside the data for a Message-ID matching one that was sent from this account in the last 14 days. If none is found this is a bounce of a mail with a forged sender address, refuse to accept the mail. Oh, and if you see log entries on your own mail server indicating, that it couldn't deliver bounces, then at least you are one step closer to the source, that the person who rejected them. That means it is time to figure out why your mail server accepted the messages in the first place. Eventually the spam will be stopped at the source.
Well, that is the theory at least. The problems are: People don't respect the protocols. Very few actually try to stop the spam at the source, since you don't make a lot of money from that. And for ISPs being a good netcitizen have a far lower priority than making money.
Now if only it was easier to pick up girls when you have a job and easier to get a job when you have a girlfriend......