Eiffel is nice, but it's contravariant. Ew. Sather gets this right.
And, as a bonus, Sather has a NICE inheritance system -- any class can be used as though it were an interface, and you can import functionality from any class without exposing its interface to others. This makes writing delegates enormously easier (and also just plain makes sense).
In the long run, too much regulation favors large companies, not smaller ones.
Well, that's quite a disputable statement.
No it isn't! I dispute that it's disputable!;-), just kidding.
I for one, have always held that regulation is neccessary to keep big companies from getting too big and turning the market into a monopoly/oligopoly, hampering small businesses.
I think one problem with the original post is that is has an ambiguous phrase: "too much regulation." He either thinks that there's some level of appropriate regulation which has been passed whenever large companies are favored (in which case you might agree or disagree, but you can both negotiate) OR he thinks that out of currently enacted legislation, more of it favors large companies than it should.
My opinion is that most regulation benefits large companies by increasing the barriers to entry in their markets.
Government involvement didn't seem to benifit Standard Oil very much.
No argument there:-).
And the deregulation of energy markets didn't seem to stop Enron. (RIP!)
I'm not sure what you mean by that -- deregulation allowed them to startup. This means that the REGULATION that had preceded prevented a startup.
They became a huge company very quickly, but that doesn't mean that they weren't a startup.
Depends who's asking. To end-users, it might provide a way to evaluate a vendor's software. To vendors it's useless.
To crackers, black-hat or otherwise, it's a gold mine -- and therefore every vendor who makes any security claims will HAVE to buy this in order to head off the crackers.
Your camera would either take too long to take photos (consider that digital cameras are already too slow), or would cost an arm and a leg to incorporate hardware encryption (and thus lose you big money when ordinary people drop it in a pond).
No, it's easier to just use an odd plug, and know that most people won't bother, since they're getting a good deal on the processing anyhow. Those who do bother will probably help you in the long run, by spreading your name.
I normally write Forth using files, and try to constrain my definitions to one line. (I bet you didn't expect THAT response; I sure didn't expect to see a Forth example used here!) But that's not relevant:-), I know what you mean.
OO is easy to write if your design calls for it. It's not "natural" to slip out of OO within a design; but the mistakes that are natural within OO aren't prevented by Smalltalk any more than they are within Python. Violating the Law of Demeter is just one example.
The difference is that in Python, you can start out doing something completely non-OO if you want. And you know, sometimes that's appropriate.
Register based machines are much faster than stack based machines.
Why do you say that? I've worked with stack machines that were faster than register machines I'd worked with. Stack machines are easier to generate code for, and easier to compile to efficient machine code; I don't see why register machines should be faster unless the number of virtual registers happens to exactly match the number of machine registers.
Smalltalk is a beautiful environment and a simple and elegant language (although the reverse is not true). But it's not the last word. Python does an excellent job at object orientation, and the fact that it doesn't enforce it doesn't cause any more bad code than the fact that Smalltalk doesn't enforce the Law of Demeter causes bad code.
I can't say that you'll _never_ see what you're asking for from Python (there are some variants that have it, such as IIRC "Psyco"), but it is unlikely. The problem is that Python's data is typed, not its variables. A lot of people like that, and there's sound reason for it, both theoretical and practical.
If you double the number of known languages, you more than quarter the number of errors
Your post is reasonable and interesting (using three-way parallelism would give better translations), but you're missing something important here.
First, none of these languages are "known" to this interpreter program. The program reads parallel texts, and when you feed it a text without a parallel, it generates the parallel for you. In other words, it can translate either way. So you don't have two known languages and one unknown; all you have is three text corpuses. (Well, in this case you have two, but you know what I mean.)
Second, yes; three would be FAR better than two; but two is also useful, and in more situations. You don't always have a Rosetta stone.
They're doing well here. Yes, there's an obvious next step to take; but no, the existance of a "next step" doesn't destroy the usefulness of this step.
That specific example won't normally happen -- you have to repeatedly be the source of spam and do nothing about it to get on most RBLs. When you do get on it, it's more likely to be your entire ISP than just a single reassigned IP (because the ISP was a spamhaus).
HOWEVER, I dislike RBLs for the same reason you do, and I like Bayesian filtering because it prevents that problem. The problem is that the better filtering is at getting spam without killing valid use, the slower it gets. Bayesian filtering is relatively slow.
So... I've been working on defining a multi-layer client/server antispam solution. There are multiple layers of defence:
1. The blocklist: people who have been abusing the greylist system recently. Deny all communications from these IPs, but take them off the blocklist if their entries get stale (i.e. they haven't been abusing for a while). 2. The greylist: people who might be risky. This includes people with IPs on RBLs, people who sent something that a user tagged as spam, etc. Anything sent from these IPs goes into the greylist system Slashdot looked at earlier. 3. Filtering -- probably DSPAM (a very nice server-side Bayesian filter).
This is just a summary; I'm leaving out a lot of detail, like how you tell when to put someone on or take someone off of the blocklist. But I hope it gives the idea. Again, the purpose is to throw out heavy time-wasters as quickly as possible, while not wasting the time of legit users or putting their communications at risk.
Makes sense to me... But I do happen to have a great solution for this specific problem. Get the Flash Click To Play extension, and you'll never again have to see a flash that you didn't explicitly want to see.
I like the idea of flash, but until this plugin the costs were usually more than the benefits -- I had to keep a spare browser around with flash installed, and only use it when I wanted to see a specific flash. Now I can just see what I want.
On the other hand, if you want your project to take a life of its own and not fall into a morass, you choose a system wherin all may partake equally who agree to return contributions they distribute.
I don't agree that a morass is the result of any license freer than the GPL (how could you so blindly ignore the many counterexamples -- XFree, BSD, libpng, and so many others); but I will agree that there's something to be gained from choosing a license that requires my code to remain free and open, no matter what changes someone else makes to it.
That's why I use the LGPL.
So you are your own military, police force, and justice system, or do you depend on others for certains aspects of that vaunted freedom?
Well said.:-)
Yes, I depend on others, but I also watch THEM. Quis custodiet ipsos custodes and so on. The GPL is a runaway policeman, and I won't use it to guard my copyright.
Yes, but contrary to your statement it IS a choice. It's just not as free as the original. Neither would a GPL'ed fork, although for different reasons.
Most people get stuck with proprietized version of BSD code because they dont know any better. the GPL looks out for them, so when they or their descendants need the source, itll be there for them.
Daddy can't look out for my rights. Only I can.
Remember "the price of freedom"? It's "Eternal vigilance!" Not "using a specific licence."
If you want your source code, you need to keep it available. You can't force other people to keep it available for you. If you want someone else's source code -- well, ask them. Otherwise, too bad.
A BSD licensed piece of code is only more freely usable from one persons point of view: the next developer.
Let's suppose that's so. So what? This makes it more freely usable.
Its your prerogative to license things as you like, but dont say its "freer as BSD" because its just not true, unless you dont care one whit for the end users of a commercialized version.
But it IS true. The end users have more choices than they had if the original code had been under GPL: they could choose the original, any open forks off of it, AND the proprietary fork.
But I have to say that I like the LGPL for these purposes -- BSD may be more free, but I'd like improvements to my code to be as public as possible.
As I said, that's the LGPL. The LGPL can't be "contracted" by code outside of the original project; the GPL can. That's its distinguishing difference.
I think the LGPL is a great license; it solidly protects your code, while allowing great freedom in how to use it. I'm using it for a game engine in order to allow later closed-source expansion packs (which are fun for a game).
Of course, I had to make a new preamble for it, since otherwise it's far to C-library specific. But that's fine with me.
The only one you should be pissed on is yourself. If you chose to release your project as open source and someone forks it and you don't like it, then it's entirely your fault.
Taking sentance fragments out of context is bad debating style. I said that I'd be pissed if he forked it for no reason, not that I'd be pissed if he forked it for any reason at all.
I'm maintaining one project that's ready for a fork anytime, and although I hope I can get back to work on it I know that if someone forks it it's for good reason. (Actually, it probably wouldn't be a fork -- it would be a new maintainer.)
Forks are good. Forks that don't add functionality are stupid. Forks that deliberately close off the original project from using their code are bad.
Calling it viral is implying that you can "catch" it, and it's an offensive implication if I've ever heard one.
No, it's implying that it attaches itself to code and uses the "replication" of the code to spread itself beyond the code itself. "Catching" it can be considered in the analogy, but only on a broader scale than software -- in this case, the entire copyright system has come down with a case of copyleft:-).
Offense is your choice, not mine.
Following your ridiculous reasoning, ALL proprietary code is viral as well, because you can't insert it into your own work and do whatever you like with it, but that's utter bullshit as well.
Um... Nonsense. I'm not talking about code, I'm talking about licenses. Proprietary code is license-neuter; it can't propagate on its own and its licenses therefore can't spread without some other vector (even though SCO believes otherwise).
GPLed code acts as a lure. If the code is enticing enough to convince you to open your own code, then you bite. It's your own damn choice.
Yes, GPLed code is a lure -- or more precisely, code is what the GPL "infects". Good code carrying the GPL will spread it more efficiently than bad code.
Yes, once again, you CAN avoid getting infected with the GPL, if it matters to you. But to do that you have to take precautions, just as with any other virus.
What if they said it wasn't viral because it uses a little bit of benign copyright application to protect a body of code against truly malignant, embrace-extend-extinguish style copyright application? That sounds much more like a *vaccine* than a virus to me.
That's the LGPL, not the GPL. Vaccines don't spread.
Please, why do we need to hear these words in relation to the (L)GPL? Apart from the fact that they have a very negative tone, they don't even properly describe the nature of the GPL.
They precisely describe the GPL; the analogy is amazingly close. The host is a copyrighted work licensed with the GPL; the target is all copyrighted works. Spread occurs via reuse. The ultimate goal of this viral art is the death of the entire system of copyright law (read the FSF's website!). (Viruses in general don't have goals, of course, but they can be engineered, and the engineer would certainly have a goal.)
You can keep from getting infected the same way you can keep from getting biological viruses -- shelter, avoid, or protect; but that only makes the analogy closer.
Now, I'm not saying that this similarity to viruses is bad. Perhaps it's a good thing to want to destroy the copyright system. I don't agree, but I'm not arguing that here. What I'm saying is that you should be honest: admit that the GPL is viral, and admit that it's about copyright, not about freedom. The old name, "copyleft", was much more accurate than "free software".
The LGPL isn't copyleft; it minimises the exposure of the odd quirks of copyright. BSD isn't copyleft at all, it's a pure license. I'd say that the LGPL is the most free of the licenses (in the "free software" sense of the term), although the BSD license allows the most leeway (but at the cost of allowing your own work to be hijacked by a later contributor).
I like all the licenses for their own benefits. I don't use the GPL often, though, because I don't think its main benefit is something I'm willing to sacrifice temporary freedom for.
If you are really serious about free software. Then you will never use the LGPL.
I believe that if you're serious about free software you won't use the GPL. For the same reason you give -- if I were to use the GPL, then you couldn't use my libraries without giving me the source to your program.
The GPL isn't about free software. It's about destroying the copyright system from within (by its own internal contradictions). If you want to be part of that fight, by all means use the GPL. But calling the result free software is only partially honest -- it'll be free only when the GPL succeeds in destroying copyright.
If I decide to write a program and contribute it to free software, the GPL assures me that it will stay free software forever.
Nope; if every copy disappears or becomes useless it's not free software (perhaps it's free, but it's arguably not software). That happens all the time with many different programs -- although by definition few of us have heard of them. (There's a LOT of them on Sourceforge right now.)
Neither BSD nor GPL protects against that -- although the BSD license does have the possibility of attracting more users and developers due to the fact that it can be used as part of proprietary work. The only problem is that these developers can be invisible, never releasing their improvements; but that's a problem with not understanding the benefits and uses of open source.
The BSD license lets people apply almost any license to my software, including most non-free licenses.
Nope! It lets people apply almost any license to _derivative works_ of your work (including the trivial derivative work of simple redistribution). Your original work is yours until your copyright expires; they can't take it from you.
Some of these pro-GPL arguments are as bad as the RIAA. "Help! They're STEALING OUR CODE!!!" At least you're not as bad as SCO: "We own all licensing rights for all derived works, but WE get to decide what's derived."
I've thought about organizing a GPL-ed thread derived from the body of existing BSD-licensed work, just to illustrate a lesson about the BSD license. That would really piss people off, but it would be legal.
The price of freedom is having to put up with knaves.
Frankly, I'd be pissed if you forked my project, but it would be the needless fork that pissed me off, not the license (that doesn't apply to me because I'm BSD).
Anyone who was pissed off would probably be so because you substituted a less freely usable license for a more free one.
Slashdot Mirror
Eiffel is nice, but it's contravariant. Ew. Sather gets this right.
And, as a bonus, Sather has a NICE inheritance system -- any class can be used as though it were an interface, and you can import functionality from any class without exposing its interface to others. This makes writing delegates enormously easier (and also just plain makes sense).
-Billy
For a cleaned-up C, try Oberon.
:-)
It's very nice.
-Billy (coding in C++ at work
In the long run, too much regulation favors large companies, not smaller ones.
;-), just kidding.
:-).
Well, that's quite a disputable statement.
No it isn't! I dispute that it's disputable!
I for one, have always held that regulation is neccessary to keep big companies from getting too big and turning the market into a monopoly/oligopoly, hampering small businesses.
I think one problem with the original post is that is has an ambiguous phrase: "too much regulation." He either thinks that there's some level of appropriate regulation which has been passed whenever large companies are favored (in which case you might agree or disagree, but you can both negotiate) OR he thinks that out of currently enacted legislation, more of it favors large companies than it should.
My opinion is that most regulation benefits large companies by increasing the barriers to entry in their markets.
Government involvement didn't seem to benifit Standard Oil very much.
No argument there
And the deregulation of energy markets didn't seem to stop Enron. (RIP!)
I'm not sure what you mean by that -- deregulation allowed them to startup. This means that the REGULATION that had preceded prevented a startup.
They became a huge company very quickly, but that doesn't mean that they weren't a startup.
-Billy
The legislation belonging to the client.
Yes. The client wrote it or was pushing it.
-Billy
what use is this?
Depends who's asking. To end-users, it might provide a way to evaluate a vendor's software. To vendors it's useless.
To crackers, black-hat or otherwise, it's a gold mine -- and therefore every vendor who makes any security claims will HAVE to buy this in order to head off the crackers.
-Billy
The point is that closed-source security holes are harder to find by analysis. With this program, a certain class of them becomes equally easy.
Thus, for this class of problem, closed source is at best no more secure than open source -- and open source is far easier to fix.
(The submitter was envisioning black-hat crackers using this tool.)
-Billy
Your camera would either take too long to take photos (consider that digital cameras are already too slow), or would cost an arm and a leg to incorporate hardware encryption (and thus lose you big money when ordinary people drop it in a pond).
No, it's easier to just use an odd plug, and know that most people won't bother, since they're getting a good deal on the processing anyhow. Those who do bother will probably help you in the long run, by spreading your name.
-Billy
I normally write Forth using files, and try to constrain my definitions to one line. (I bet you didn't expect THAT response; I sure didn't expect to see a Forth example used here!) But that's not relevant :-), I know what you mean.
OO is easy to write if your design calls for it. It's not "natural" to slip out of OO within a design; but the mistakes that are natural within OO aren't prevented by Smalltalk any more than they are within Python. Violating the Law of Demeter is just one example.
The difference is that in Python, you can start out doing something completely non-OO if you want. And you know, sometimes that's appropriate.
-Billy
Register based machines are much faster than stack based machines.
Why do you say that? I've worked with stack machines that were faster than register machines I'd worked with. Stack machines are easier to generate code for, and easier to compile to efficient machine code; I don't see why register machines should be faster unless the number of virtual registers happens to exactly match the number of machine registers.
-Billy
Smalltalk is a beautiful environment and a simple and elegant language (although the reverse is not true). But it's not the last word. Python does an excellent job at object orientation, and the fact that it doesn't enforce it doesn't cause any more bad code than the fact that Smalltalk doesn't enforce the Law of Demeter causes bad code.
-Billy
I can't say that you'll _never_ see what you're asking for from Python (there are some variants that have it, such as IIRC "Psyco"), but it is unlikely. The problem is that Python's data is typed, not its variables. A lot of people like that, and there's sound reason for it, both theoretical and practical.
-Billy
If you double the number of known languages, you more than quarter the number of errors
Your post is reasonable and interesting (using three-way parallelism would give better translations), but you're missing something important here.
First, none of these languages are "known" to this interpreter program. The program reads parallel texts, and when you feed it a text without a parallel, it generates the parallel for you. In other words, it can translate either way. So you don't have two known languages and one unknown; all you have is three text corpuses. (Well, in this case you have two, but you know what I mean.)
Second, yes; three would be FAR better than two; but two is also useful, and in more situations. You don't always have a Rosetta stone.
They're doing well here. Yes, there's an obvious next step to take; but no, the existance of a "next step" doesn't destroy the usefulness of this step.
-Billy
That specific example won't normally happen -- you have to repeatedly be the source of spam and do nothing about it to get on most RBLs. When you do get on it, it's more likely to be your entire ISP than just a single reassigned IP (because the ISP was a spamhaus).
HOWEVER, I dislike RBLs for the same reason you do, and I like Bayesian filtering because it prevents that problem. The problem is that the better filtering is at getting spam without killing valid use, the slower it gets. Bayesian filtering is relatively slow.
So... I've been working on defining a multi-layer client/server antispam solution. There are multiple layers of defence:
1. The blocklist: people who have been abusing the greylist system recently. Deny all communications from these IPs, but take them off the blocklist if their entries get stale (i.e. they haven't been abusing for a while).
2. The greylist: people who might be risky. This includes people with IPs on RBLs, people who sent something that a user tagged as spam, etc. Anything sent from these IPs goes into the greylist system Slashdot looked at earlier.
3. Filtering -- probably DSPAM (a very nice server-side Bayesian filter).
This is just a summary; I'm leaving out a lot of detail, like how you tell when to put someone on or take someone off of the blocklist. But I hope it gives the idea. Again, the purpose is to throw out heavy time-wasters as quickly as possible, while not wasting the time of legit users or putting their communications at risk.
-Billy
Makes sense to me... But I do happen to have a great solution for this specific problem. Get the Flash Click To Play extension, and you'll never again have to see a flash that you didn't explicitly want to see.
I like the idea of flash, but until this plugin the costs were usually more than the benefits -- I had to keep a spare browser around with flash installed, and only use it when I wanted to see a specific flash. Now I can just see what I want.
-Billy
You seem to be willfully ignoring the LGPL, along with all the other source licenses out there.
The only difference between the LGPL and the GPL is that the GPL is viral. Period. Why try so hard to deny it?
-Billy
On the other hand, if you want your project to take a life of its own and not fall into a morass, you choose a system wherin all may partake equally who agree to return contributions they distribute.
:-)
I don't agree that a morass is the result of any license freer than the GPL (how could you so blindly ignore the many counterexamples -- XFree, BSD, libpng, and so many others); but I will agree that there's something to be gained from choosing a license that requires my code to remain free and open, no matter what changes someone else makes to it.
That's why I use the LGPL.
So you are your own military, police force, and justice system, or do you depend on others for certains aspects of that vaunted freedom?
Well said.
Yes, I depend on others, but I also watch THEM. Quis custodiet ipsos custodes and so on. The GPL is a runaway policeman, and I won't use it to guard my copyright.
-Billy
the proprietized version is NOT a "Free" choice.
Yes, but contrary to your statement it IS a choice. It's just not as free as the original. Neither would a GPL'ed fork, although for different reasons.
Most people get stuck with proprietized version of BSD code because they dont know any better. the GPL looks out for them, so when they or their descendants need the source, itll be there for them.
Daddy can't look out for my rights. Only I can.
Remember "the price of freedom"? It's "Eternal vigilance!" Not "using a specific licence."
If you want your source code, you need to keep it available. You can't force other people to keep it available for you. If you want someone else's source code -- well, ask them. Otherwise, too bad.
-Billy
A BSD licensed piece of code is only more freely usable from one persons point of view: the next developer.
Let's suppose that's so. So what? This makes it more freely usable.
Its your prerogative to license things as you like, but dont say its "freer as BSD" because its just not true, unless you dont care one whit for the end users of a commercialized version.
But it IS true. The end users have more choices than they had if the original code had been under GPL: they could choose the original, any open forks off of it, AND the proprietary fork.
But I have to say that I like the LGPL for these purposes -- BSD may be more free, but I'd like improvements to my code to be as public as possible.
-Billy
As I said, that's the LGPL. The LGPL can't be "contracted" by code outside of the original project; the GPL can. That's its distinguishing difference.
I think the LGPL is a great license; it solidly protects your code, while allowing great freedom in how to use it. I'm using it for a game engine in order to allow later closed-source expansion packs (which are fun for a game).
Of course, I had to make a new preamble for it, since otherwise it's far to C-library specific. But that's fine with me.
-Billy
The only one you should be pissed on is yourself. If you chose to release your project as open source and someone forks it and you don't like it, then it's entirely your fault.
Taking sentance fragments out of context is bad debating style. I said that I'd be pissed if he forked it for no reason, not that I'd be pissed if he forked it for any reason at all.
I'm maintaining one project that's ready for a fork anytime, and although I hope I can get back to work on it I know that if someone forks it it's for good reason. (Actually, it probably wouldn't be a fork -- it would be a new maintainer.)
Forks are good. Forks that don't add functionality are stupid. Forks that deliberately close off the original project from using their code are bad.
-Billy
Calling it viral is implying that you can "catch" it, and it's an offensive implication if I've ever heard one.
:-).
No, it's implying that it attaches itself to code and uses the "replication" of the code to spread itself beyond the code itself. "Catching" it can be considered in the analogy, but only on a broader scale than software -- in this case, the entire copyright system has come down with a case of copyleft
Offense is your choice, not mine.
Following your ridiculous reasoning, ALL proprietary code is viral as well, because you can't insert it into your own work and do whatever you like with it, but that's utter bullshit as well.
Um... Nonsense. I'm not talking about code, I'm talking about licenses. Proprietary code is license-neuter; it can't propagate on its own and its licenses therefore can't spread without some other vector (even though SCO believes otherwise).
GPLed code acts as a lure. If the code is enticing enough to convince you to open your own code, then you bite. It's your own damn choice.
Yes, GPLed code is a lure -- or more precisely, code is what the GPL "infects". Good code carrying the GPL will spread it more efficiently than bad code.
Yes, once again, you CAN avoid getting infected with the GPL, if it matters to you. But to do that you have to take precautions, just as with any other virus.
-Billy
What if they said it wasn't viral because it uses a little bit of benign copyright application to protect a body of code against truly malignant, embrace-extend-extinguish style copyright application? That sounds much more like a *vaccine* than a virus to me.
That's the LGPL, not the GPL. Vaccines don't spread.
-Billy
Please, why do we need to hear these words in relation to the (L)GPL? Apart from the fact that they have a very negative tone, they don't even properly describe the nature of the GPL.
They precisely describe the GPL; the analogy is amazingly close. The host is a copyrighted work licensed with the GPL; the target is all copyrighted works. Spread occurs via reuse. The ultimate goal of this viral art is the death of the entire system of copyright law (read the FSF's website!). (Viruses in general don't have goals, of course, but they can be engineered, and the engineer would certainly have a goal.)
You can keep from getting infected the same way you can keep from getting biological viruses -- shelter, avoid, or protect; but that only makes the analogy closer.
Now, I'm not saying that this similarity to viruses is bad. Perhaps it's a good thing to want to destroy the copyright system. I don't agree, but I'm not arguing that here. What I'm saying is that you should be honest: admit that the GPL is viral, and admit that it's about copyright, not about freedom. The old name, "copyleft", was much more accurate than "free software".
The LGPL isn't copyleft; it minimises the exposure of the odd quirks of copyright. BSD isn't copyleft at all, it's a pure license. I'd say that the LGPL is the most free of the licenses (in the "free software" sense of the term), although the BSD license allows the most leeway (but at the cost of allowing your own work to be hijacked by a later contributor).
I like all the licenses for their own benefits. I don't use the GPL often, though, because I don't think its main benefit is something I'm willing to sacrifice temporary freedom for.
-Billy
If you are really serious about free software. Then you will never use the LGPL.
I believe that if you're serious about free software you won't use the GPL. For the same reason you give -- if I were to use the GPL, then you couldn't use my libraries without giving me the source to your program.
The GPL isn't about free software. It's about destroying the copyright system from within (by its own internal contradictions). If you want to be part of that fight, by all means use the GPL. But calling the result free software is only partially honest -- it'll be free only when the GPL succeeds in destroying copyright.
-Billy
If I decide to write a program and contribute it to free software, the GPL assures me that it will stay free software forever.
Nope; if every copy disappears or becomes useless it's not free software (perhaps it's free, but it's arguably not software). That happens all the time with many different programs -- although by definition few of us have heard of them. (There's a LOT of them on Sourceforge right now.)
Neither BSD nor GPL protects against that -- although the BSD license does have the possibility of attracting more users and developers due to the fact that it can be used as part of proprietary work. The only problem is that these developers can be invisible, never releasing their improvements; but that's a problem with not understanding the benefits and uses of open source.
The BSD license lets people apply almost any license to my software, including most non-free licenses.
Nope! It lets people apply almost any license to _derivative works_ of your work (including the trivial derivative work of simple redistribution). Your original work is yours until your copyright expires; they can't take it from you.
Some of these pro-GPL arguments are as bad as the RIAA. "Help! They're STEALING OUR CODE!!!" At least you're not as bad as SCO: "We own all licensing rights for all derived works, but WE get to decide what's derived."
I've thought about organizing a GPL-ed thread derived from the body of existing BSD-licensed work, just to illustrate a lesson about the BSD license. That would really piss people off, but it would be legal.
The price of freedom is having to put up with knaves.
Frankly, I'd be pissed if you forked my project, but it would be the needless fork that pissed me off, not the license (that doesn't apply to me because I'm BSD).
Anyone who was pissed off would probably be so because you substituted a less freely usable license for a more free one.
-Billy