I think when you ask that question, you ought to put "robots" in quotes also. You talk about them as though they are a species, all mentally wired the same way, which of course couldn't be further from the truth.
Anyway, I guess the answer would have to be, "we don't know," because we've tried many different ways to make robots, some with different needs, some without any, and none have aspired to the hollywood definition of a robot, a mechanical being that acts just like a human but doesn't use as many articles when speaking.
Also, I think "needs" and "motivations" may be too high-level of terms. For example, why does a computer program run as it does? It's just a process: the physical design of the machine, combined with it's current state and inputs, cause it to enter a predictable set of states in the future. But why do you continue to live? The current state of your body and brain, including your senses, physically interact and bring your body to somewhat predictable states in the future. In both cases, it's just a process, and at the lowest level, the why is unimportant. Needs and motives are higher-level abstractions that we humans use to understand how other humans will act over timescales that would be too long to predict with lower-level abstractions. It's the same idea as files, processes, and windows - abstractions we use to predict how computers will act without having to think about every instruction that is run (which is itself an abstraction of the electrons and transistors.)
So if one were to make a robot that actually could "emulate" a human, than it would have the same motivations as a human does. Motivation and humanity are both in the eyes of the beholder, and if you didn't think of the robot as having motivations, you wouldn't think of it as human-like.
Science fiction often envisions robots with quite inhuman or vastly simplified motivations (Asimov's laws, or Bender's "Kill all humans", or needing to plug in instead of to eat), but the very fact that there are motivations, that thinking in terms of motivations allows you to explain the robot's actions, is what makes you believe that the robots think similarly to humans.
I've never really understood why DRM always seems to be implemented at the file format level. Why not just have something like a.tar file that's DRM'd, and of course (try to) make sure that the only software able to read it won't divulge it's contents?
Of course for the purposes of the law, you may as well just ROT128 the file and call it DRM. It may be technically simpler, but in theory it's exactly as easy to crack as "real" DRM.
You do realize it's that way in America too, right?
There is a difference in the discs - if you were stupid enough to get tape-deck-like CD-recorders that were marketed as audio equipment instead of just getting a computer, you need to buy the audio CD-Rs.
The argument against TCPA is a little better-informed than you admit, but it's goals are more long-term and big-picture. (Perhaps too much so, but nevertheless...)
The idea is that while TCPA can be used to help security or accelerate encryption, it of course can also be used for DRM, which includes not only things like delivering entertainment in such a way as to screw the user as hard as physically possible, but also the scary stuff about keeping you from blowing the whistle on evil schemes, etc. The idea is that the current fact that files can be copied by the recipient, and that client computers can act in a way not sanctioned by the servers, is an important safeguard, both in maintaining the balance of fair use and in more serious matters.
I don't think most TCPA opponents are so misinformed as to think that enabling a TCPA chip somehow immediately limits you, or that it's not optional. Instead, they just don't want to see TCPA become popular, because of the bad things which will inevitably follow.
Microsoft: "We'll sell you our software and hardware manufacturers will bundle drivers that work with it."
Linux: "We'll give you not only our software but also a bunch of drivers, however, many hardware vendors will hang you out to dry."
The point is, the Linux community does more for you than Microsoft, and for free. This is what open source gets you. However, manufacturers won't write a driver if it won't move much more hardware. That part has nothing to do with open source; it has to do with the relative sizes of the markets involved. Open source even fixes this shortcoming where possible, by doing the manufacturer's jobs for them, provided they can get the necessary hardware specs. IOW, if Linux had 90% of the desktop market, by your logic, closed source would hinder driver development. In fact, driver development has everything to do with market share.
Also, borg-like or not, the One True Kernel Tree can scale much better, and produce a higher-quality result, than the Windows approach does. The problem is that while hardware is a moving target, software is an even faster moving target. For a given piece of hardware, the design is eventually fixed, and though there will be newer models and designs, the installed base provides constancy. For a given piece of software, however, requirements are constantly changing and designs are constantly improving. Windows and linux have different approaches to solving this problem, and the Linux one is better.
In Windows, there are tons of third party drivers, and being drivers, they depend on the APIs and design of "the" Windows kernel. So what must Microsoft do when they want to change something? For a small change, first they add the new system, then they add a compatibility layer for the old APIs, then they release it. Although no driver needed to be changed, every driver has become slower and less reliable, and the kernel has become more bloated. Larger changes that require breaking compatibility completely pretty much require a new release of Windows. Which means that drivers have to be changed anyway, and worse, two versions have to be maintained. And if the hardware company has gone under, users may be unable to use the hardware with the new version of Windows.
Under the open source model and with most drivers in the tree, making changes of any size is much easier. Just make the change and modify the drivers that rely on it to use the new or updated API. There's no crufty compatibility layer adding bloat to the kernel. This works for any size change. The hardware companies don't have to lift a finger, because an API change wouldn't be accepted without a corresponding update of any affected maintained in-kernel drivers. And if the company dies, if enough users still have the hardware, it remains supported.
For a concrete example of this, look at the transition to 64-bit. Linux was there first (if you count non-x86 architectures, by several years), and for in-kernel drivers, there was no problem. All the source was there to be modified by the same people who actually ported the kernel, the hardware vendors didn't have to lift a finger. For Windows, updating the kernel to run in 64-bit mode has required (or is requiring) a massive coordinated effort between Microsoft and all the major hardware vendors. And of course, the vendors that have died have left their users with no way to run their hardware in 64-bit Windows. And the surviving vendors now have to release two versions of all their drivers, as opposed to just having one version, which gets compiled by distributors in 32- or 64-bit mode as needed, in the tree.
There are seperate device nodes for each mouse, but by default they are multiplexed into/dev/input/mice. You can certainly tell X to read just one of them. And you can run multiple instances of X on different (or even the same) video card. USB keyboards (maybe PS2 now, but good luck having multiple PS2 keyboards anyway) also have seperate device nodes. From the standpoint of X, it's possible and has been done (google for it). The one thing that would need major patching is virtual consoles (i.e. Ctrl-Alt-F1), but that's not really essential anyway.
This is one of those instances where the collective opinion of a group ("RIAA bad, GPL good") is stupid, biased, and inconsisent, but if you look closer, you see several subgroups with somewhat more consistent logical opinions, and closer still, individuals with different, but each downright intelligent, opinions. In this case, the people who think the RIAA are in the wrong in enforcing their copyrights because copyrights are flawed and evil are probably not the same people who think enforcing the GPL is good. I'd guess people in favor of forcing compliance with the GPL acknowledge that the RIAA are at least within their rights. (I'm in this group, but I personally would qualify that last part by saying that they're protecting their copyrights in very stupid and even evil ways, including interfering with the government, working against fair use, and lying constantly. GPL enforcers are generally better-intentioned.)
I guess my point is, 'exposing' the hypocrisy of Slashdot as you have is just a very stupid way of trying to make everyone look stupid, and it's sad that arguments similar to yours get modded up so frequently.
(Insert arbitrary number of spaces here)-space indentation is evil - real men (including K&R, whose standard you otherwise advocate) use tabs. With tabs, we can all set our editors to use the amount of visual space that is most pleasing to us.
Actually, I would argue that a clone (or rather, a tool that could extract all the data (which data should be owned collectively by the kernel developers) into an open format, was needed for interoperability, precisely because of the restrictiveness of the "free" BK license.
The license didn't just prohibit reverse engineering for any reasonable definition of the term, it prohibited licencees from working on any other source code management system for some time into the future. What this means is, not only are the people who won't touch nVidia drivers morally unable to use BK, but most people who value their freedom and want to keep their options open can't morally use it. Not only that, it makes using BT a big liability, because how do you define SCM system? And there were tons of people whose employers won't let them enter into such a contract, and with good reason. The "free" BK license drastically increased the demand for a BK "clone," which was absolutely needed for interoperability with the unnecesarily large number of people who couldn't agree to the license.
The idea with the free version was that you could use it if you made your servers open to the public, but if you wanted them private, you'd have to pay. This is a great business model, and perfectly capable of being supported using nothing but copyright, and not even particularly restrictive licenses. It would even have been possible to make the source code visible (though not "open source," as you couldn't necessarily use the results of your modificiations). But instead McVoy got scared, and made the license far too restrictive, thus increasing the demand for a clone. When work inevitably began on this, he took his ball and went home.
Also, saying Tridell is "license cracking" implies that he was a party to the license, which we have no evidence of. And 'If you do this, it'll sink our business; We gotta eat' is not a valid argument.
When you connect to a private proprietry-protocol server using something other than the server owner's publically available client *then* you're in the wrong.
So what about all our non-AOL AIM clients, huh? There's a good chance you use one, Mr. AC. More important that pointing out your probable hypocrisy, why do you propose we add this "protocol right" to the already-too-large body of IP law? What possible benefit could it serve? Is it really worth legislating what tools people can use to communicate with public servers, a significant blow to interoperability and personal freedom?
The way I see it, interoperability is very important to the health of the software industry, and things that stand in the way are bad. (Copyright is the one branch of IP that doesn't (especially if the scope of derived works were reigned in a bit), and so I applaud it.)
Watch me... A unified, open, universally supported DRM format would rapidly speed the adoption of DRM while simultaneously providing a seamless multimedia experience. Sounds great, right? Absolutely not. Removing the marketing bullshit from that sentence, it would make control of the music industry even more centralized, while keeping the users more ignorant of their situation, which would be worsening at an accelerated rate.
I really believe it's best overall if the DRM scene remains as fragmented and complicated as it is now - that increases the window of time during which someone might realize that they if just SELL THE DAMN MUSIC without ANY restrictions beyond copyright and the honor system, they'd be bigger than iTunes.
Right now, the only way to legally obtain music and (somewhat) legally use it on all devices is to buy it on CD. If Congress really gives a damn about customers, they should mandate that online purchases be as flexible as that - which would involve banning DRM outright. But at the moment they won't even strike the legal protection they were bribed to give it under the DMCA. If they intervene to accelerate DRM's adoption, rest assured that their goal is to hasten the death of fair use, and thus screw the consumers.
While what you say is true, it ignores wear and tear on the bulb and ballast, which is actually more significant. So if you figure the total cost of running the light, including replacing it when it fails, I've seen figures as high as 5 - 15 minutes (sorry, have long since lost the link). But still certainly not 16 hours.
Understand that in most cases*, when submitting changes to a GPL work, you retain your copyright. So you have every right to use even the exact same code you contributed to the GPL project in your own proprietary works. This has no effect on the licensing of the remainder of your proprietary works. If you don't contribute to GPL projects for ideological reasons, that's your choice, but if you don't contribute because you're afraid it will somehow affect the licensing or ownership of your proprietary code (even if it's the same code), that's just misinformed.
* Notable exceptions are projects the FSF hosts, which make you sign a copyright transfer for non-trivial patches. But the transfer is obvious and active - when you transfer your copyrights, you'll know it. And I think the even the FSF will, in return, give you a right to sublicense the code however you please.
I don't think anybody suggested that would be done for all elements, or permanently for any. It's just so there's a way to talk about the newly-discovered ones until people stop fighting over whom it should be named after.
Software patents would be brought into that system via essentially the same loophole by which they were brought into the current system. Everyone would send cheap PCs with the "innovative" software loaded on them. Exactly as they do now, patents would cover "the enclosed device, which consists of a central processing unit, one or more input and output devices, and a fucking plurality (God I hate that word!) of memory storage cells onto which are loaded data which can cause the device to..."
Actually, it would probably be worse than present, because given the intelligence the patent office has shown so far, they'd probably take a few photos of the motherboard, and not even bother to save a hard disk image, much less think to ask for a description of how the software does what it does.
We absolutely need to ban software patents, but we need to do so explicitly and clearly.
It's because most people pronounce it "gram er," (er as in her, or german Uhr) not "gram are" or "gram air." (I'm not saying this is correct, just that in Illinois, it's the way I've always heard it said.) So you have to know that it's not spelled like it sounds.
I'd be much happier if Nero has at least the option to not use the proprietary in-kernel drivers I get the impression it ships with. I hope we can avoid combining the annoyance of nvidia drivers with the fragility of cd-recording under Windows.
It also means that to make CD burning work on an unusual setup, support only has to be added in one place, bugs only have to be fixed in one place, and not as much effort is wasted, which is important when trying to get people to volunteer to write non-"fun" software.
Also, there are several other backends besides cdrecord, such a cdrdao, and some with better support for DVD writing, such as groisofs, and others that have been mentioned in this story. Many frontends can be configured to use these backends also. This is a big win, because when the frontends and backends are modular, if your drive doesn't work with one backend, that doesn't limit which frontends you can use.
I can definitely see the problem with having all the eggs in one basket, especially when that basket is held by Joerg Schilling, who seems to be backpedaling on the GPL, and who violently and untactfully disagrees with a lot of Linux's design choices, making cooperation extremly difficult. But still, having the backend decoupled is a first step to the goal of multiple frontends each capable of using each of several backends, and a much easier first step that having multiple tightly integrated programs that act as both frontend and backend.
And all of this is better than the situation in Windows, where at least until recently, you had to choose between several expensive proprietary programs with conflicting in-kernel components that embed themselves into your system in mysterious ways, defy deletion, and conspire to destroy your ability to burn anything, or at least to bug you with "CD Recording software will cause Windows to become unstable." bubbles until the end of time.
What follows is an incredibly shameless plug for my project...
VLevel is exactly what you want. It works by continuously but gradually changing the gain throughout the file. It has a lookahead buffer of a few seconds, so unlike a compressor, it never has to change the gain too quickly. This preserves "contrast," so for example if a quiet part was being made loud, the gain will decrease a little while before the big bombastic crescendo, so you'll still get the effect.
For Windows, the best way to use it is with the plugin for Foobar2000, an awesome windows audio player. On Linux, you can use it as a LADSPA filter, which can be plugged into XMMS.
Well, that is certainly the way it is. But it's horribly broken - why on earth shouldn't there be an amount you're "supposed" to pay? Why should the tax laws be indeterminate? The "attribute to malice" answer is so that the more you can spend on accountants, the less taxes you pay, and the "attribute to stupidity" answer is that when congresspeople fight, they never repeal laws, only make new ones, so the tax laws just continue to increase in complexity. The "stupidity" answer is probably right, but either way, it ought to be fixed.
I suppose I could look at this from the cracker's perspective, "what loopholes in the system can I exploit?", but I'd kinda prefer it if the system didn't have loopholes.
When you only use GPL software, you're right, nothing is being exchanged, so there would be no contract. The GPL even explicitly states this. (This should also apply to EULAs also, though it doesn't seem to.) However, when you distribute any software, you're violating copyright by default, and the only way to save yourself is to have entered into some license agreement that allows you to do so. And for GPL software, one, and probably the only, such license is the GPL. There is compensation - you give up your right to keep your modifications secret, and in exchange, you get the right to distribute binaries.
Actually, though some cards (like my SoundBlaster Live Value!) do have a recording input that is the wav output, that's probably not what grandparent was alluding to. You shoud be more afraid if realplay and friends start trying to ignore LD_PRELOAD or not run under debuggers, because that's how it works. (Though it should be easy enough to intercept it in either anything that uses ALSA, or even for OSS, in the kernel.)
Slashdot Mirror
Anyway, I guess the answer would have to be, "we don't know," because we've tried many different ways to make robots, some with different needs, some without any, and none have aspired to the hollywood definition of a robot, a mechanical being that acts just like a human but doesn't use as many articles when speaking.
Also, I think "needs" and "motivations" may be too high-level of terms. For example, why does a computer program run as it does? It's just a process: the physical design of the machine, combined with it's current state and inputs, cause it to enter a predictable set of states in the future. But why do you continue to live? The current state of your body and brain, including your senses, physically interact and bring your body to somewhat predictable states in the future. In both cases, it's just a process, and at the lowest level, the why is unimportant. Needs and motives are higher-level abstractions that we humans use to understand how other humans will act over timescales that would be too long to predict with lower-level abstractions. It's the same idea as files, processes, and windows - abstractions we use to predict how computers will act without having to think about every instruction that is run (which is itself an abstraction of the electrons and transistors.)
So if one were to make a robot that actually could "emulate" a human, than it would have the same motivations as a human does. Motivation and humanity are both in the eyes of the beholder, and if you didn't think of the robot as having motivations, you wouldn't think of it as human-like.
Science fiction often envisions robots with quite inhuman or vastly simplified motivations (Asimov's laws, or Bender's "Kill all humans", or needing to plug in instead of to eat), but the very fact that there are motivations, that thinking in terms of motivations allows you to explain the robot's actions, is what makes you believe that the robots think similarly to humans.
Of course for the purposes of the law, you may as well just ROT128 the file and call it DRM. It may be technically simpler, but in theory it's exactly as easy to crack as "real" DRM.
There is a difference in the discs - if you were stupid enough to get tape-deck-like CD-recorders that were marketed as audio equipment instead of just getting a computer, you need to buy the audio CD-Rs.
The idea is that while TCPA can be used to help security or accelerate encryption, it of course can also be used for DRM, which includes not only things like delivering entertainment in such a way as to screw the user as hard as physically possible, but also the scary stuff about keeping you from blowing the whistle on evil schemes, etc. The idea is that the current fact that files can be copied by the recipient, and that client computers can act in a way not sanctioned by the servers, is an important safeguard, both in maintaining the balance of fair use and in more serious matters.
I don't think most TCPA opponents are so misinformed as to think that enabling a TCPA chip somehow immediately limits you, or that it's not optional. Instead, they just don't want to see TCPA become popular, because of the bad things which will inevitably follow.
Microsoft: "We'll sell you our software and hardware manufacturers will bundle drivers that work with it."
Linux: "We'll give you not only our software but also a bunch of drivers, however, many hardware vendors will hang you out to dry."
The point is, the Linux community does more for you than Microsoft, and for free. This is what open source gets you. However, manufacturers won't write a driver if it won't move much more hardware. That part has nothing to do with open source; it has to do with the relative sizes of the markets involved. Open source even fixes this shortcoming where possible, by doing the manufacturer's jobs for them, provided they can get the necessary hardware specs. IOW, if Linux had 90% of the desktop market, by your logic, closed source would hinder driver development. In fact, driver development has everything to do with market share.
Also, borg-like or not, the One True Kernel Tree can scale much better, and produce a higher-quality result, than the Windows approach does. The problem is that while hardware is a moving target, software is an even faster moving target. For a given piece of hardware, the design is eventually fixed, and though there will be newer models and designs, the installed base provides constancy. For a given piece of software, however, requirements are constantly changing and designs are constantly improving. Windows and linux have different approaches to solving this problem, and the Linux one is better.
In Windows, there are tons of third party drivers, and being drivers, they depend on the APIs and design of "the" Windows kernel. So what must Microsoft do when they want to change something? For a small change, first they add the new system, then they add a compatibility layer for the old APIs, then they release it. Although no driver needed to be changed, every driver has become slower and less reliable, and the kernel has become more bloated. Larger changes that require breaking compatibility completely pretty much require a new release of Windows. Which means that drivers have to be changed anyway, and worse, two versions have to be maintained. And if the hardware company has gone under, users may be unable to use the hardware with the new version of Windows.
Under the open source model and with most drivers in the tree, making changes of any size is much easier. Just make the change and modify the drivers that rely on it to use the new or updated API. There's no crufty compatibility layer adding bloat to the kernel. This works for any size change. The hardware companies don't have to lift a finger, because an API change wouldn't be accepted without a corresponding update of any affected maintained in-kernel drivers. And if the company dies, if enough users still have the hardware, it remains supported.
For a concrete example of this, look at the transition to 64-bit. Linux was there first (if you count non-x86 architectures, by several years), and for in-kernel drivers, there was no problem. All the source was there to be modified by the same people who actually ported the kernel, the hardware vendors didn't have to lift a finger. For Windows, updating the kernel to run in 64-bit mode has required (or is requiring) a massive coordinated effort between Microsoft and all the major hardware vendors. And of course, the vendors that have died have left their users with no way to run their hardware in 64-bit Windows. And the surviving vendors now have to release two versions of all their drivers, as opposed to just having one version, which gets compiled by distributors in 32- or 64-bit mode as needed, in the tree.
There are seperate device nodes for each mouse, but by default they are multiplexed into /dev/input/mice. You can certainly tell X to read just one of them. And you can run multiple instances of X on different (or even the same) video card. USB keyboards (maybe PS2 now, but good luck having multiple PS2 keyboards anyway) also have seperate device nodes. From the standpoint of X, it's possible and has been done (google for it). The one thing that would need major patching is virtual consoles (i.e. Ctrl-Alt-F1), but that's not really essential anyway.
I guess my point is, 'exposing' the hypocrisy of Slashdot as you have is just a very stupid way of trying to make everyone look stupid, and it's sad that arguments similar to yours get modded up so frequently.
Yay for binary formats, they're so easy to perfectly parse. Oh wait...
(Insert arbitrary number of spaces here)-space indentation is evil - real men (including K&R, whose standard you otherwise advocate) use tabs. With tabs, we can all set our editors to use the amount of visual space that is most pleasing to us.
The license didn't just prohibit reverse engineering for any reasonable definition of the term, it prohibited licencees from working on any other source code management system for some time into the future. What this means is, not only are the people who won't touch nVidia drivers morally unable to use BK, but most people who value their freedom and want to keep their options open can't morally use it. Not only that, it makes using BT a big liability, because how do you define SCM system? And there were tons of people whose employers won't let them enter into such a contract, and with good reason. The "free" BK license drastically increased the demand for a BK "clone," which was absolutely needed for interoperability with the unnecesarily large number of people who couldn't agree to the license.
The idea with the free version was that you could use it if you made your servers open to the public, but if you wanted them private, you'd have to pay. This is a great business model, and perfectly capable of being supported using nothing but copyright, and not even particularly restrictive licenses. It would even have been possible to make the source code visible (though not "open source," as you couldn't necessarily use the results of your modificiations). But instead McVoy got scared, and made the license far too restrictive, thus increasing the demand for a clone. When work inevitably began on this, he took his ball and went home.
Also, saying Tridell is "license cracking" implies that he was a party to the license, which we have no evidence of. And 'If you do this, it'll sink our business; We gotta eat' is not a valid argument.
So what about all our non-AOL AIM clients, huh? There's a good chance you use one, Mr. AC. More important that pointing out your probable hypocrisy, why do you propose we add this "protocol right" to the already-too-large body of IP law? What possible benefit could it serve? Is it really worth legislating what tools people can use to communicate with public servers, a significant blow to interoperability and personal freedom?
The way I see it, interoperability is very important to the health of the software industry, and things that stand in the way are bad. (Copyright is the one branch of IP that doesn't (especially if the scope of derived works were reigned in a bit), and so I applaud it.)
I really believe it's best overall if the DRM scene remains as fragmented and complicated as it is now - that increases the window of time during which someone might realize that they if just SELL THE DAMN MUSIC without ANY restrictions beyond copyright and the honor system, they'd be bigger than iTunes.
Right now, the only way to legally obtain music and (somewhat) legally use it on all devices is to buy it on CD. If Congress really gives a damn about customers, they should mandate that online purchases be as flexible as that - which would involve banning DRM outright. But at the moment they won't even strike the legal protection they were bribed to give it under the DMCA. If they intervene to accelerate DRM's adoption, rest assured that their goal is to hasten the death of fair use, and thus screw the consumers.
While what you say is true, it ignores wear and tear on the bulb and ballast, which is actually more significant. So if you figure the total cost of running the light, including replacing it when it fails, I've seen figures as high as 5 - 15 minutes (sorry, have long since lost the link). But still certainly not 16 hours.
* Notable exceptions are projects the FSF hosts, which make you sign a copyright transfer for non-trivial patches. But the transfer is obvious and active - when you transfer your copyrights, you'll know it. And I think the even the FSF will, in return, give you a right to sublicense the code however you please.
I don't think anybody suggested that would be done for all elements, or permanently for any. It's just so there's a way to talk about the newly-discovered ones until people stop fighting over whom it should be named after.
On Slashdot at least, when you subscribe, the ads go away.
Actually, it would probably be worse than present, because given the intelligence the patent office has shown so far, they'd probably take a few photos of the motherboard, and not even bother to save a hard disk image, much less think to ask for a description of how the software does what it does.
We absolutely need to ban software patents, but we need to do so explicitly and clearly.
It's because most people pronounce it "gram er," (er as in her, or german Uhr) not "gram are" or "gram air." (I'm not saying this is correct, just that in Illinois, it's the way I've always heard it said.) So you have to know that it's not spelled like it sounds.
I'd be much happier if Nero has at least the option to not use the proprietary in-kernel drivers I get the impression it ships with. I hope we can avoid combining the annoyance of nvidia drivers with the fragility of cd-recording under Windows.
Also, there are several other backends besides cdrecord, such a cdrdao, and some with better support for DVD writing, such as groisofs, and others that have been mentioned in this story. Many frontends can be configured to use these backends also. This is a big win, because when the frontends and backends are modular, if your drive doesn't work with one backend, that doesn't limit which frontends you can use.
I can definitely see the problem with having all the eggs in one basket, especially when that basket is held by Joerg Schilling, who seems to be backpedaling on the GPL, and who violently and untactfully disagrees with a lot of Linux's design choices, making cooperation extremly difficult. But still, having the backend decoupled is a first step to the goal of multiple frontends each capable of using each of several backends, and a much easier first step that having multiple tightly integrated programs that act as both frontend and backend.
And all of this is better than the situation in Windows, where at least until recently, you had to choose between several expensive proprietary programs with conflicting in-kernel components that embed themselves into your system in mysterious ways, defy deletion, and conspire to destroy your ability to burn anything, or at least to bug you with "CD Recording software will cause Windows to become unstable." bubbles until the end of time.
Uh, that's a good thing.
VLevel is exactly what you want. It works by continuously but gradually changing the gain throughout the file. It has a lookahead buffer of a few seconds, so unlike a compressor, it never has to change the gain too quickly. This preserves "contrast," so for example if a quiet part was being made loud, the gain will decrease a little while before the big bombastic crescendo, so you'll still get the effect.
For Windows, the best way to use it is with the plugin for Foobar2000, an awesome windows audio player. On Linux, you can use it as a LADSPA filter, which can be plugged into XMMS.
I suppose I could look at this from the cracker's perspective, "what loopholes in the system can I exploit?", but I'd kinda prefer it if the system didn't have loopholes.
When you only use GPL software, you're right, nothing is being exchanged, so there would be no contract. The GPL even explicitly states this. (This should also apply to EULAs also, though it doesn't seem to.) However, when you distribute any software, you're violating copyright by default, and the only way to save yourself is to have entered into some license agreement that allows you to do so. And for GPL software, one, and probably the only, such license is the GPL. There is compensation - you give up your right to keep your modifications secret, and in exchange, you get the right to distribute binaries.
Actually, though some cards (like my SoundBlaster Live Value!) do have a recording input that is the wav output, that's probably not what grandparent was alluding to. You shoud be more afraid if realplay and friends start trying to ignore LD_PRELOAD or not run under debuggers, because that's how it works. (Though it should be easy enough to intercept it in either anything that uses ALSA, or even for OSS, in the kernel.)