Argument A would get tossed out immediately based on copyright law. The law is very clear: code is copyrighted by it's author by default, and never enters the public domain except by the copyright term expiring or by an explicit written statement from the author committing the work to the public domain.
Argument B would get tossed out as a matter of law. A party who has standing to sue can contract with someone to represent them in the suit. That's what's happened here, the BusyBox authors have assigned SFLC as their legal representative when dealing with copyright-infringement matters. If you think the court's going to tell the BB authors that they can't have an attorney handle their case for them, I'm afraid you'll be in for a suprise.
The problem is that the law is settled. That's why companies are so quick to comply and settle fast in GPL-violation cases once they realize that the copyright holder really is prepared to take them to court.
Other GPL software projects do in fact provide all the source code, or they're distributing very clearly under 3c. Diffs are not acceptable under the GPL. You aren't providing just diffs of the binaries either, after all. And of course a company always has the option of using 3a, eg. including the source code on a CD with the product, at which point their obligation ends completely when they give the binaries and accompanying source to the user and they don't have to host anything ever.
If someone else takes the stuff and puts it up, they are doing the distributing. Per the GPL, providing source code is their responsibility.
No nightmare at all, not unless you insist on creating one for yourself by adding things the GPL doesn't.
What's so hard to read about the GPL? It's a whole lot easier to read and comprehend than your average commercial software license. If a company's lawyers are expected to routinely understand complex contracts running close to a hundred pages of dense legalese, why should they have any trouble whatsoever with the GPL?
It's not that hard, as 3a, 3b and 3c are alternatives ("or" relationship). And the requirement to give anybody the code flows from the very obvious implications of 3c and the fact that the GPL prohibits you from barring further redistribution. Suppose vendor V sells a product containing GPL'd code to person A. Person A redistributes the GPL'd code to person C under section 3c, passing on the written offer from V as the GPL allows them to. Person C then takes advantage of the offer and asks V for the source code. If V could refuse just because C didn't get the code directly from them, there'd be an obvious loophole that'd allow companies to distribute GPL'd code without providing source. So 3b explicitly blocks that loophole, and 3a never had the loophole.
From the looks of it, that source code was put up the day after the lawsuit was filed.
Once again, evidence that the only language some companies understand is "lawsuit". That language does seem to be highly effective at getting their attention, though.
Nope, you can't just point to someone else's sources. When you distribute GPL'd software, you are responsible for being able to provide the sources upon request. And not just the sources, but the sources for the version you distributed. If you just point to someone else's copies, they could stop hosting them or host newer versions. You are now in violation of the GPL, since the sources required by it are no longer available from you.
The only way to deal with this would be for you to enter into a contract with the party hosting the sources to make sure the correct versions are available as long as your obligation continues.
No, you're not being pedantic, you're being wrong. To quote from the GPL v2, section 3b (which covers distribution of source for binaries which were distributed without accompanying source), the vendor must:
Accompany it with a written offer, valid for at least three years, to give any third party, for a charge no more than your cost of physically performing source distribution, a complete machine-readable copy of the corresponding source code, to be distributed under the terms of Sections 1 and 2 above on a medium customarily used for software interchange;
Notice that the offer does not say the vendor must give only people who bought their product the source code. It says they must give any third party the code. Now, under section 3a the vendor only has to give the code to people who receive the product, but 3a pertains to the vendor distributing the source code with the product itself. If they don't include the source code with the binaries, 3a doesn't apply. And since it's not a non-commercial distribution, 3c doesn't apply either.
Most good software I've seen follows the KISS principle internally: Keep It Simple, Stupid. Pieces of it know what they're supposed to do and they do just that. They don't mix in functionality for several things. They don't have embedded knowledge of how they relate to the rest of the system. They've got clean, modular interfaces that let you test just that one part to make sure it's doing what it should and not doing what it shouldn't, without having to haul in large parts of the rest of the system. They either don't make assumptions about what the rest of the system will hand them or they've got those assumptions clearly documented in the interface and they test that their input conforms to those assumptions and produce a clear error if it doesn't. Eventually some pieces will have to embody the design and logic, understand how all the individual pieces fit together to make the system work, but that's their job: to orchestrate the work being done, not to actually do it.
Another indicator is that good software is designed with the certainty that it will change, that it will be extended and altered over time. Good software has that assumption built in. Bad software, by comparison, is often flagged by statements like "Don't worry, we're never going to change that." or "We don't need to worry about doing that.". Software designed not to change or be extended is either bad software or rapidly becomes bad software once it hits production.
And no, nothing particularly new there. It's been this way for about 50 years.
Your company probably gets Internet connectivity from an ISP, and possibly has that ISP or a dedicated mail service provider handling e-mail. Check the Terms of Service. They probably contain language about unsolicited bulk e-mail. Bring up this point and ask for guidance from the corporate counsel as to what steps, if any, you need to take to run the requested campaign without violating contracts the company's signed and putting their Internet and mail at risk. Let counsel handle the rest.
Then I suspect the consultants here are making a big deal out of very little. Where I work we use a lot of open-source in our programs, and there's nothing in any of the official documentation about what we're using. All there is is a notation that these programs use outside libraries, and of course the makefiles and such list every such library used. And over in a completely separate team's workspace is the complete set of external libraries we use, along with their dependencies and build instructions. I'm sure these consultants would be horrified at the lack of documentation in our programs of what we're using, but it's simply not a problem. Our programs are for internal use, and all the libraries we use are fine for that (we make sure of that before we decide to use them). It only becomes an issue if we ever want to distribute our software outside the company, which a) isn't going to happen and b) if it ever does happen we know we need to vet all our external libraries and their licenses with Legal before doing so whether they're open-source or proprietary.
They talk about how much of the open-source code is undocumented. I notice that they don't bother to mention how much of the in-house code is also undocumented. My experience as a software engineer is that their in-house code's probably at least as poorly documented as the open-source stuff. And if the business finds this state of affairs acceptable for their in-house code, why's it any more of a problem for the open-source parts?
I've also found that when the business does get a consultant in who demands documentation, they usually demand something that's completely useless for the actual developers. Eg., they demand UML models for all the software. Well, that's nice and all, but most of what's in the UML you can see by glancing at the class definitions. The things a developer needs, like what the methods are supposed to do and what gotcha caused a particular way of doing it to be picked and what assumptions the code's making about it's inputs and outputs, have no place in a UML model.
But why would one give these kids an assignment to write a program? The assignment's more likely to be "Draw a map of the area around the village.". The OLPC is the tool the kids use to draw the map. And to get all their friends together to help point out landmarks one of them may have forgotten to include, and to argue about where those landmarks are relative to one another. No programming needed by the kids to do that. And yes, you can do that kind of assignment in a classroom with paper and pencils. Unless you don't have a classroom, you can't afford to buy pencils and paper as fast as the kids will use them up, and the kids are spread out and it's impractical to get all of them together at one time (but it is practical for groups of them to get together, especially if they just have to flip open a lid to join the group instead of hiking the mile or so to the school). And pencil and paper and a classroom won't let you bring the class from the 5 villages around you in to have the kids look at how the other villages see the local world. And it sure won't let you get two kids from tribes that've been mortal enemies since before their grandparents were born talking and working with each other before they realize they're mortal enemies (old adage: "On the 'net everybody's the same color, green on a black background.").
And again, you're missing the point: you don't teach them to use the OLPC. That's why it's UI is such that it mostly doesn't require teaching kids how to use it. And at that age, kids don't need to learn food storage techniques. What they need to learn is how to find out about and learn about food storage techniques. Which is a special case of learning how to find out and learn about anything.
You're demonstrating a dichotomy I've seen a lot in college. Most students would memorize what was taught. In a physics class, they'd memorize the hundreds of formulas for all the different things covered in class. They'd come in to exams with the (allowed) cheat-sheets completely covered in tiny writing. And if a question on the exam involved something they didn't have a formula written down for, they were completely lost. By contrast, me and a handful of others would come in with a 3x5 index card with perhaps half-a-dozen basic equations written on one side. Instead of learning all the formulas for everything, we'd learned how to derive any formula we needed from those basic equations. If a question was on something that hadn't been covered in class, it might take us a few minutes longer to work through to get what we needed but it wasn't a big deal. We'd taken the next step, from learning the formulas to learning why the formulas were what they were.
NB: I think it significant that there was a big psychological difference between the two groups. The majority, the ones who memorized formulas, were literally physically afraid of there being anything on the exam they didn't have notes for. Me, I might be annoyed if I couldn't work out the answer in the time given but the unexpected wasn't anything to be scared of.
As others have noted, there already exists a way. It's called a "contract". Centuries-long basis in law for it. And no, contrary to your protestations down-thread, it's not all that inconvenient. It's called a blanket contract. I deal with it all the time as a software developer. Instead of negotiating one contract for each promo you want to send out, before you even start you negotiate one contract with the recipient covering all the promos you'll send them until they notify you in writing that they no longer want to receive the promos. One contract, one negotiation, then mail away without needing to mess with it again until you get that letter from them.
In general, the legal system doesn't let some arbitrary person impose obligations on someone else without that other party's consent and agreement. This is a good thing.
That's adult thinking. What the child's learning is problem-solving, co-operation and collaboration, and how to go about finding answers to questions when you have a question you need an answer for. The OLPC is a tool for doing those things. Hence why most of it's applications network automatically. It's got puzzle games which teach problem-solving. If you're working on a puzzle, all your friends on the network can automatically see (just like they were looking over your shoulder) and you can talk with them to discuss how to solve it, get ideas, everyone can try ideas and everyone can see how they work. And pretty quick they get to "Joban three villages over's really good at these kinds of problems. Let's get him to look at this and show us what we're doing wrong.". Which winds up working a lot better than having an authority figure stand there and lecture at you.
Except that the "and magic happens" is actually a fairly routine part of early education. Most kids like to learn, want to learn. It takes the education system several years of intense effort to beat this penchant for learning out of most kids. You may have to teach the kid how the card catalog in a library works, but once you do he'll cheerfully get together with a bunch of his friends and organize finding all they need to know for the essay assignments you give them. And probably more, I usually ended up with three or four essays for every assignment I'd been given. You may not even need to teach them how to use the card catalog, I figured out on my own not just the card catalog but how the Dewey numbers on the spines of the books worked (got a lot of teachers mad at me because I was supposed to go to the card catalog, and instead I'd head straight for the section of shelves I knew had the books on the subject I needed and I Wasn't Supposed To Do That and I should Stop That This Instant, Come Back Here And Start Again And Do It Right This Time).
Yes, the OLPC is useless as a computer for a geek. Fair enough, it wasn't designed to be a computer for a geek. It was designed to be a learning (not teaching, learning) tool for a child. That's a completely different thing. And oddly, I notice that all the reports of actual children being handed an OLPC without any instruction or guidance seem to end with the child being entirely comfortable with it, having no problem figuring it out, and generally out-running the adults when it comes to using the thing. They even pick up the networking parts of it naturally. Yes, children are in fact smarter than most adults like to believe.
You're missing one nuance of this case, and several related ones: "win" doesn't mean the defendant just prevailed. In this case, it means the defendant gets awarded costs. That's a big deal. Really big. One reason defendants don't fight is that typically even if they win they'll have to bear the costs of their own defense. No lawyer's going to take a case on contingency if there's no possibility of recovery at the end, and few defendants can afford to pay a good defense attorney cash on the barrelhead. Awarding costs changes that. Now there is money in it for the attorney if they prevail, which means more attorneys will be willing to take cases on a contingency basis. That means more defendants fighting back and not settling immediately, which means more work and more costs for the RIAA. The RIAA doesn't want to win cases, they want to get settlements without having to fight at all. That, as much as the possibility of setting a bad precedent, is why the RIAA has tried to drop cases when the defendant puts up a determined defense. And cases like this are rapidly making that impossible.
Because this defendant has fought and won. The RIAA needs to send a clear message to everyone else: even winning against us comes at too high a cost. That's all this is about now, and hopefully the courts will send a message to the RIAA: the legal system isn't here to use as your personal club to beat people you don't like with.
I don't think this is a smart move. Given that the first case is still active, and that the new case involves the same acts and the same defendants, can't the defense move to have the new case reassigned to the first judge and consolidated with the first case? I'd think that would be a lawyer's worst nightmare, to have tried this kind of end-run and wind up back in front of the judge you tried to evade anyway. He's sure to be none too thrilled about it, and now has a reason to crack down harder.
And when the receiving MTA isn't under your control and isn't going to accept configuration from you? Think GMail or Yahoo Mail. How does your sync idea work when you can't sync?
When you brush it off as "easy to solve" without a solution in hand, I'm afraid my response is "OK, talk to me when you've got an implementation we can test.". Cynical and brusque, yes, but you sound exactly like the last two dozen youngsters on the teams at work whose failures I've had to clean up after.
Unfortunately "relay cannot reach the destination immediately" is the standard configuration. On almost every ISP MUAs (or user MTAs) are required to hand mail to an internal MTA. That MTA will then send the mail through processing and hand it to another MTA. That second MTA will handle the actual delivery to the recipient's MTA. And I don't see ISPs changing that setup until after spam and the problems an ISP gets from having customers on it's network used to spam are elimianted, so your protocol will have to contend with this setup if it wants to get adopted. And your system has another problem: what happens if the sender also implements it? I go to send an e-mail to you, the first e-mail I've sent to you. You've never sent one to me either. Your system sends me a challenge. My system sees you sending me an e-mail for the first time, and sends you a challenge. Your system sees a second e-mail from me without me having responded to your challenge (because I haven't been presented with your challenge, and won't be until you respond to my challenge). How do you propose to resolve this deadlock? And no, allowing challenges through won't work, because if you allow that then the spammers will simply wrap their spam up as a challenge. And no, having the sender keep track of which challenges it's sent won't help, because people use more than one computer (work machine, home machine, laptop, and let's not even get into those of us with multiple home machines plus multiple remote servers that we use when the local network policies are too restrictive for our normal e-mail to work). Server-side won't work either, my mail for example goes out via my ISP (because of my ISP's policies) but the mail server that you'll send the challenge to belongs to a completely different ISP (the one who hosts my domain and handles my mail) in a different state.
Your "solution" has one problem: it assumes a real-time interactive channel. How, for instance, is it going to ask the sender to respond to a captcha when the mail's being handled by an intermediate relay (ISP smart-host) and the sender isn't connected anymore? And if it asks you to authorize the mail, how is it going to do that without having to make you look at each and every incoming mail, spam or not, so you can decide?
And this apparently ignores one of the more common abuses: an "affiliate" who exists solely to spam. They don't bother cloaking their identity because they only exist for the length of the spam run. Recipients submit opt-out requests, that affiliate puts them on the list. And then promptly evaporates, replaced by a new, different affiliate who can send the same spam for the same product and not have to worry about the opt-outs.
Make it opt-in. Period. This is the era of Google and the like. If I'm at all interested in something I already know all about who offers it, I don't need an unsolicited advertisement for it. And if I'm interested in hearing from your company, I'm quite capable of asking for continued information.
Bacteria isn't a species. Escherichia coli is a species, genus escherichia, family enterobacteriaceae, order enterobacteriales, class gamma proteobacteria, phylum proteobacteria, domain bacteria. To become something other than a bacteria, E. coli would have to evolve not just into a new species but into something in an entirely different domain. Note that we've again seen this happen, eg. some of the most primitive multi-celled creatures developed from colonies of single-celled organisms as individuals within the colony specialized for different tasks.
Slashdot Mirror
Argument A would get tossed out immediately based on copyright law. The law is very clear: code is copyrighted by it's author by default, and never enters the public domain except by the copyright term expiring or by an explicit written statement from the author committing the work to the public domain.
Argument B would get tossed out as a matter of law. A party who has standing to sue can contract with someone to represent them in the suit. That's what's happened here, the BusyBox authors have assigned SFLC as their legal representative when dealing with copyright-infringement matters. If you think the court's going to tell the BB authors that they can't have an attorney handle their case for them, I'm afraid you'll be in for a suprise.
The problem is that the law is settled. That's why companies are so quick to comply and settle fast in GPL-violation cases once they realize that the copyright holder really is prepared to take them to court.
Other GPL software projects do in fact provide all the source code, or they're distributing very clearly under 3c. Diffs are not acceptable under the GPL. You aren't providing just diffs of the binaries either, after all. And of course a company always has the option of using 3a, eg. including the source code on a CD with the product, at which point their obligation ends completely when they give the binaries and accompanying source to the user and they don't have to host anything ever.
If someone else takes the stuff and puts it up, they are doing the distributing. Per the GPL, providing source code is their responsibility.
No nightmare at all, not unless you insist on creating one for yourself by adding things the GPL doesn't.
What's so hard to read about the GPL? It's a whole lot easier to read and comprehend than your average commercial software license. If a company's lawyers are expected to routinely understand complex contracts running close to a hundred pages of dense legalese, why should they have any trouble whatsoever with the GPL?
It's not that hard, as 3a, 3b and 3c are alternatives ("or" relationship). And the requirement to give anybody the code flows from the very obvious implications of 3c and the fact that the GPL prohibits you from barring further redistribution. Suppose vendor V sells a product containing GPL'd code to person A. Person A redistributes the GPL'd code to person C under section 3c, passing on the written offer from V as the GPL allows them to. Person C then takes advantage of the offer and asks V for the source code. If V could refuse just because C didn't get the code directly from them, there'd be an obvious loophole that'd allow companies to distribute GPL'd code without providing source. So 3b explicitly blocks that loophole, and 3a never had the loophole.
From the looks of it, that source code was put up the day after the lawsuit was filed.
Once again, evidence that the only language some companies understand is "lawsuit". That language does seem to be highly effective at getting their attention, though.
Nope, you can't just point to someone else's sources. When you distribute GPL'd software, you are responsible for being able to provide the sources upon request. And not just the sources, but the sources for the version you distributed. If you just point to someone else's copies, they could stop hosting them or host newer versions. You are now in violation of the GPL, since the sources required by it are no longer available from you.
The only way to deal with this would be for you to enter into a contract with the party hosting the sources to make sure the correct versions are available as long as your obligation continues.
No, you're not being pedantic, you're being wrong. To quote from the GPL v2, section 3b (which covers distribution of source for binaries which were distributed without accompanying source), the vendor must:
Accompany it with a written offer, valid for at least three years, to give any third party, for a charge no more than your cost of physically performing source distribution, a complete machine-readable copy of the corresponding source code, to be distributed under the terms of Sections 1 and 2 above on a medium customarily used for software interchange;
Notice that the offer does not say the vendor must give only people who bought their product the source code. It says they must give any third party the code. Now, under section 3a the vendor only has to give the code to people who receive the product, but 3a pertains to the vendor distributing the source code with the product itself. If they don't include the source code with the binaries, 3a doesn't apply. And since it's not a non-commercial distribution, 3c doesn't apply either.
Most good software I've seen follows the KISS principle internally: Keep It Simple, Stupid. Pieces of it know what they're supposed to do and they do just that. They don't mix in functionality for several things. They don't have embedded knowledge of how they relate to the rest of the system. They've got clean, modular interfaces that let you test just that one part to make sure it's doing what it should and not doing what it shouldn't, without having to haul in large parts of the rest of the system. They either don't make assumptions about what the rest of the system will hand them or they've got those assumptions clearly documented in the interface and they test that their input conforms to those assumptions and produce a clear error if it doesn't. Eventually some pieces will have to embody the design and logic, understand how all the individual pieces fit together to make the system work, but that's their job: to orchestrate the work being done, not to actually do it.
Another indicator is that good software is designed with the certainty that it will change, that it will be extended and altered over time. Good software has that assumption built in. Bad software, by comparison, is often flagged by statements like "Don't worry, we're never going to change that." or "We don't need to worry about doing that.". Software designed not to change or be extended is either bad software or rapidly becomes bad software once it hits production.
And no, nothing particularly new there. It's been this way for about 50 years.
Your company probably gets Internet connectivity from an ISP, and possibly has that ISP or a dedicated mail service provider handling e-mail. Check the Terms of Service. They probably contain language about unsolicited bulk e-mail. Bring up this point and ask for guidance from the corporate counsel as to what steps, if any, you need to take to run the requested campaign without violating contracts the company's signed and putting their Internet and mail at risk. Let counsel handle the rest.
Then I suspect the consultants here are making a big deal out of very little. Where I work we use a lot of open-source in our programs, and there's nothing in any of the official documentation about what we're using. All there is is a notation that these programs use outside libraries, and of course the makefiles and such list every such library used. And over in a completely separate team's workspace is the complete set of external libraries we use, along with their dependencies and build instructions. I'm sure these consultants would be horrified at the lack of documentation in our programs of what we're using, but it's simply not a problem. Our programs are for internal use, and all the libraries we use are fine for that (we make sure of that before we decide to use them). It only becomes an issue if we ever want to distribute our software outside the company, which a) isn't going to happen and b) if it ever does happen we know we need to vet all our external libraries and their licenses with Legal before doing so whether they're open-source or proprietary.
They talk about how much of the open-source code is undocumented. I notice that they don't bother to mention how much of the in-house code is also undocumented. My experience as a software engineer is that their in-house code's probably at least as poorly documented as the open-source stuff. And if the business finds this state of affairs acceptable for their in-house code, why's it any more of a problem for the open-source parts?
I've also found that when the business does get a consultant in who demands documentation, they usually demand something that's completely useless for the actual developers. Eg., they demand UML models for all the software. Well, that's nice and all, but most of what's in the UML you can see by glancing at the class definitions. The things a developer needs, like what the methods are supposed to do and what gotcha caused a particular way of doing it to be picked and what assumptions the code's making about it's inputs and outputs, have no place in a UML model.
But why would one give these kids an assignment to write a program? The assignment's more likely to be "Draw a map of the area around the village.". The OLPC is the tool the kids use to draw the map. And to get all their friends together to help point out landmarks one of them may have forgotten to include, and to argue about where those landmarks are relative to one another. No programming needed by the kids to do that. And yes, you can do that kind of assignment in a classroom with paper and pencils. Unless you don't have a classroom, you can't afford to buy pencils and paper as fast as the kids will use them up, and the kids are spread out and it's impractical to get all of them together at one time (but it is practical for groups of them to get together, especially if they just have to flip open a lid to join the group instead of hiking the mile or so to the school). And pencil and paper and a classroom won't let you bring the class from the 5 villages around you in to have the kids look at how the other villages see the local world. And it sure won't let you get two kids from tribes that've been mortal enemies since before their grandparents were born talking and working with each other before they realize they're mortal enemies (old adage: "On the 'net everybody's the same color, green on a black background.").
And again, you're missing the point: you don't teach them to use the OLPC. That's why it's UI is such that it mostly doesn't require teaching kids how to use it. And at that age, kids don't need to learn food storage techniques. What they need to learn is how to find out about and learn about food storage techniques. Which is a special case of learning how to find out and learn about anything.
You're demonstrating a dichotomy I've seen a lot in college. Most students would memorize what was taught. In a physics class, they'd memorize the hundreds of formulas for all the different things covered in class. They'd come in to exams with the (allowed) cheat-sheets completely covered in tiny writing. And if a question on the exam involved something they didn't have a formula written down for, they were completely lost. By contrast, me and a handful of others would come in with a 3x5 index card with perhaps half-a-dozen basic equations written on one side. Instead of learning all the formulas for everything, we'd learned how to derive any formula we needed from those basic equations. If a question was on something that hadn't been covered in class, it might take us a few minutes longer to work through to get what we needed but it wasn't a big deal. We'd taken the next step, from learning the formulas to learning why the formulas were what they were.
NB: I think it significant that there was a big psychological difference between the two groups. The majority, the ones who memorized formulas, were literally physically afraid of there being anything on the exam they didn't have notes for. Me, I might be annoyed if I couldn't work out the answer in the time given but the unexpected wasn't anything to be scared of.
As others have noted, there already exists a way. It's called a "contract". Centuries-long basis in law for it. And no, contrary to your protestations down-thread, it's not all that inconvenient. It's called a blanket contract. I deal with it all the time as a software developer. Instead of negotiating one contract for each promo you want to send out, before you even start you negotiate one contract with the recipient covering all the promos you'll send them until they notify you in writing that they no longer want to receive the promos. One contract, one negotiation, then mail away without needing to mess with it again until you get that letter from them.
In general, the legal system doesn't let some arbitrary person impose obligations on someone else without that other party's consent and agreement. This is a good thing.
That's adult thinking. What the child's learning is problem-solving, co-operation and collaboration, and how to go about finding answers to questions when you have a question you need an answer for. The OLPC is a tool for doing those things. Hence why most of it's applications network automatically. It's got puzzle games which teach problem-solving. If you're working on a puzzle, all your friends on the network can automatically see (just like they were looking over your shoulder) and you can talk with them to discuss how to solve it, get ideas, everyone can try ideas and everyone can see how they work. And pretty quick they get to "Joban three villages over's really good at these kinds of problems. Let's get him to look at this and show us what we're doing wrong.". Which winds up working a lot better than having an authority figure stand there and lecture at you.
Except that the "and magic happens" is actually a fairly routine part of early education. Most kids like to learn, want to learn. It takes the education system several years of intense effort to beat this penchant for learning out of most kids. You may have to teach the kid how the card catalog in a library works, but once you do he'll cheerfully get together with a bunch of his friends and organize finding all they need to know for the essay assignments you give them. And probably more, I usually ended up with three or four essays for every assignment I'd been given. You may not even need to teach them how to use the card catalog, I figured out on my own not just the card catalog but how the Dewey numbers on the spines of the books worked (got a lot of teachers mad at me because I was supposed to go to the card catalog, and instead I'd head straight for the section of shelves I knew had the books on the subject I needed and I Wasn't Supposed To Do That and I should Stop That This Instant, Come Back Here And Start Again And Do It Right This Time).
Yes, the OLPC is useless as a computer for a geek. Fair enough, it wasn't designed to be a computer for a geek. It was designed to be a learning (not teaching, learning) tool for a child. That's a completely different thing. And oddly, I notice that all the reports of actual children being handed an OLPC without any instruction or guidance seem to end with the child being entirely comfortable with it, having no problem figuring it out, and generally out-running the adults when it comes to using the thing. They even pick up the networking parts of it naturally. Yes, children are in fact smarter than most adults like to believe.
You're missing one nuance of this case, and several related ones: "win" doesn't mean the defendant just prevailed. In this case, it means the defendant gets awarded costs. That's a big deal. Really big. One reason defendants don't fight is that typically even if they win they'll have to bear the costs of their own defense. No lawyer's going to take a case on contingency if there's no possibility of recovery at the end, and few defendants can afford to pay a good defense attorney cash on the barrelhead. Awarding costs changes that. Now there is money in it for the attorney if they prevail, which means more attorneys will be willing to take cases on a contingency basis. That means more defendants fighting back and not settling immediately, which means more work and more costs for the RIAA. The RIAA doesn't want to win cases, they want to get settlements without having to fight at all. That, as much as the possibility of setting a bad precedent, is why the RIAA has tried to drop cases when the defendant puts up a determined defense. And cases like this are rapidly making that impossible.
Because this defendant has fought and won. The RIAA needs to send a clear message to everyone else: even winning against us comes at too high a cost. That's all this is about now, and hopefully the courts will send a message to the RIAA: the legal system isn't here to use as your personal club to beat people you don't like with.
I don't think this is a smart move. Given that the first case is still active, and that the new case involves the same acts and the same defendants, can't the defense move to have the new case reassigned to the first judge and consolidated with the first case? I'd think that would be a lawyer's worst nightmare, to have tried this kind of end-run and wind up back in front of the judge you tried to evade anyway. He's sure to be none too thrilled about it, and now has a reason to crack down harder.
And when the receiving MTA isn't under your control and isn't going to accept configuration from you? Think GMail or Yahoo Mail. How does your sync idea work when you can't sync?
When you brush it off as "easy to solve" without a solution in hand, I'm afraid my response is "OK, talk to me when you've got an implementation we can test.". Cynical and brusque, yes, but you sound exactly like the last two dozen youngsters on the teams at work whose failures I've had to clean up after.
Unfortunately "relay cannot reach the destination immediately" is the standard configuration. On almost every ISP MUAs (or user MTAs) are required to hand mail to an internal MTA. That MTA will then send the mail through processing and hand it to another MTA. That second MTA will handle the actual delivery to the recipient's MTA. And I don't see ISPs changing that setup until after spam and the problems an ISP gets from having customers on it's network used to spam are elimianted, so your protocol will have to contend with this setup if it wants to get adopted. And your system has another problem: what happens if the sender also implements it? I go to send an e-mail to you, the first e-mail I've sent to you. You've never sent one to me either. Your system sends me a challenge. My system sees you sending me an e-mail for the first time, and sends you a challenge. Your system sees a second e-mail from me without me having responded to your challenge (because I haven't been presented with your challenge, and won't be until you respond to my challenge). How do you propose to resolve this deadlock? And no, allowing challenges through won't work, because if you allow that then the spammers will simply wrap their spam up as a challenge. And no, having the sender keep track of which challenges it's sent won't help, because people use more than one computer (work machine, home machine, laptop, and let's not even get into those of us with multiple home machines plus multiple remote servers that we use when the local network policies are too restrictive for our normal e-mail to work). Server-side won't work either, my mail for example goes out via my ISP (because of my ISP's policies) but the mail server that you'll send the challenge to belongs to a completely different ISP (the one who hosts my domain and handles my mail) in a different state.
Your "solution" has one problem: it assumes a real-time interactive channel. How, for instance, is it going to ask the sender to respond to a captcha when the mail's being handled by an intermediate relay (ISP smart-host) and the sender isn't connected anymore? And if it asks you to authorize the mail, how is it going to do that without having to make you look at each and every incoming mail, spam or not, so you can decide?
And this apparently ignores one of the more common abuses: an "affiliate" who exists solely to spam. They don't bother cloaking their identity because they only exist for the length of the spam run. Recipients submit opt-out requests, that affiliate puts them on the list. And then promptly evaporates, replaced by a new, different affiliate who can send the same spam for the same product and not have to worry about the opt-outs.
Make it opt-in. Period. This is the era of Google and the like. If I'm at all interested in something I already know all about who offers it, I don't need an unsolicited advertisement for it. And if I'm interested in hearing from your company, I'm quite capable of asking for continued information.
Bacteria isn't a species. Escherichia coli is a species, genus escherichia, family enterobacteriaceae, order enterobacteriales, class gamma proteobacteria, phylum proteobacteria, domain bacteria. To become something other than a bacteria, E. coli would have to evolve not just into a new species but into something in an entirely different domain. Note that we've again seen this happen, eg. some of the most primitive multi-celled creatures developed from colonies of single-celled organisms as individuals within the colony specialized for different tasks.