Apple has made some changes in their EULA recently (or, possibly, I've recently noticed some features) that make them no longer an acceptable choice. They've added that obnoxious(paraphrase) "we have the right to add, remove, copy, or delete any files from your system". That makes them an unacceptable choice.
This might be an interesting language for many purposes... just because those who created it had one purpose in mind, doesn't mean it can't be used elsewhere. But that depends on the license, which the article doesn't seem to mention.
The license clearly isn't BSD, but it could, conceivably, be GPL...depending on what the article writer translated into "Hancock's source code and binaries (now up to version 2.0) are available free to noncommercial users from an AT&T Research website. " (In the article there's a link to the source code site...but without knowing the license I'm not looking any further.)
Try it this way: Nearly everyone's an idealog about things that matter to them. As the site increased the number of people posting, the divergence in views became larger between the different sections. Nothing makes a programmer be either left-wing, right-wing, or centrist. Any of those can be good programmers, so they all showed up. There's lots of libertarians...but this is political ideology, it doesn't easily translate into practical matters...except that it's highly consistent with FOSS, so there's a very strong libertarian streak that is also favorable to FOSS. (Note that this kind of libertarian isn't closely connected with what the Libertarian Party is talking about. There's some overlap, but not much.)
OTOH, programmers who are system designers tend to notice that designing a good system is hard work, and requires lots of cycles of error correction. So in areas where they think carefully, they tend to be opposed to design decisions that are top-down and difficult to fix design errors in. But this is only in areas where they think carefully, and nobody does that in most of the places that they're operating. Too inefficient.
There's probably more factors involved, but those are the ones that I notice off the top of my head, and they would predict the effects that you have noticed.
I notice that you're reporting a consensus of the manufacturers.
Their opinion is in direct contrast with other opinions that I've heard recently (although not specifically about "InPhase". The opinions that I've seen put the shelf life at a couple of years...and specifically said that after about a decade the plastic would be so degraded that it couldn't safely be handled without cracking, and that it would have lost much of it's transparency. And that's only if you had stored it under ideal conditions (at standard temperature and pressure...but no light exposure at all, and sealed).
Now it's true that the comments were about standard DVDs. And they did admit that the original CDs (the ones on metalic films between glass plates, with pits burned into the metal to write [not a mere phase change of an alloy]) could be expected to last indefinitely...and even to be playable for centuries if stored under reasonable conditions (which included flat with no uneven pressure on them). But this wasn't true of the modern reformulations which were designed to allow low powered lasers in customer equipment to write them.
I notice that the CILR report specifically claims stability for the plastic used to seal the disks. This was specifically denied by the other report that I read, so that gives you one particular thing to investigate before you decide that the report is trustworthy. The other claim, that the phase-change alloy wasn't stable over time, would be much more difficult to check, and different DVDs might well use different alloys, so what is true for one might well not be true of another.
P.S.: I'm skeptical of BOTH reports. Current DVDs haven't existed in their current form for any natural aging tests to have been done. As a result, any projections of the stability of the current disks are, at best, educated guesses. Accelerated aging tests have a very poor history, being quite succeptible to biased or otherwise improper guesses as to what kinds of stress would mimic natural aging in a shorter timespan.
Unh...about those "soft spots": such as the relatively limited number of write cycles
You *are* aware that this particular soft spot only exists because it doesn't matter for the designated application, aren't you? It's cheaper to build flash ram that wears out more quickly, and "more quickly" is sufficiently far in the future that most people will lose their thumb drive before they ever encounter this problem. If they cared, they'd use wear-leveling NAND flash, but it's cheaper not to, and the current version is "good enough for the purpose".
If they wanted faster speed, they could "RAID" the chips. They don't want the extra cost and complexity.
So your "soft spots" don't exist.
Presumably the people who licensed the patents got a better idea of what they were buying, but from here it looks like the target is either a video distribution system, a hard disk replacement for portables, or both. Whether either or both of these are practical depends on lots of details that won't show up in the popular press. Also, these guys are research scientists, not production engineers. The virtues and downfalls of their lab model don't say that much about what the production-for-sale model will be like.
If she's not a computer professional, why is she worried about the disk size? Her question should be "Is it big enough?", not "How many bytes is it?"
That said, if she's not a computer professional, the answer to "Is it big enough?" is almost certain to be "Yes", unless she's using Vista, or some other recently-released giganticaly-humongous OS. (I'm counting animators, architects, etc. as computer professionals. They have legitimate reasons to wonder whether the disk is big enough, But such people probably have someone else do the sizing for them...so it's still a computer systems professional [i.e., not someone who professionally uses computers, but someone whose profession centers around computes] who really estimates "What is 'big enough' in Megabytes?".)
Sorry, but for certain algorithms it's important that you are working in powers of 2, and that was always called Mega (Bits, Bytes, Words, whatever) or, more commonly Kilo-whatever was 2^10 whatevers.
IO has always been a mixture and compromise. Punched cards could hold 12 * 72 bits (7094 row binary) or 12 * 80 bits (column binary, but don't try to read it with the main card reader). Try to fit THAT into your "powers of 10" scenario!
For the current set of IO devices, capacity measurement was defined by marketing. I saw arguments about it in the trade journals when it was being fought out over hard disks. AFAIK, companies decided independently the choice that was, to them, most advantageous. It was powers of 10. This was not appreciated by any single customer that I was aware of. Some despised it, some didn't care, nobody was in favor. (Yeah, it was a small sample, but it's one that I was aware of. Most didn't care, and many of those weren't interested in understanding.)
But block allocations of RAM are done in powers of two, and these are frequently mapped directly to IO devices. So having a mis-match creates problems. Disk files were (possibly) created as an answer to this problem. (7094 drum storage didn't have files. Things were addressed by drum address. If a piece went bad, you had to patch your program to avoid it. UGH! Tape was for persistent data, drum storage was transient...just slightly more persistent than RAM.) Drum addresses were tricky. I never did it myself, but some people improved performance by timing the instructions so that they would have the drum head right before the data they wanted to read or write to limit lagging. (Naturally this was all done in assembler, so you could count out exactly how many miliseconds of execution time you were committing, and if you know the drum rotation speed, and the latency... So things tended to be stored in powers of two positions on the drum, unless a piece went bad.
Disks, when they first appeared, were slower than drums, but more capacious. (They were still too expensive and unreliable to use for persistent storage.) But the habit of mapping things out in powers of two transferred from drums storage to disk storage. When files were introduced (not sure about when that was) the habit transferred. This wasn't all blind habit, lots of the I/O techniques that had been developed were dependent upon powers of two. So programmers though of capacity in powers of two. This didn't make any sense to accountants, managers, etc. When computer equipment started being sold by the Megabyte it made sense to the manufacturers to claim powers of 10 Megabytes for stroage, as they could claim larger sizes. (This wasn't as significant for Kilobytes, as 1024 is pretty close to 1000.) It not only made sense to the manufacturers, it also made sense to the accountants who were approving the orders. And when the managers started specifying the equipment...well, everything switched over into being measured by powers of 10.
No conspiracy. Just system dynamics. And programmers still think of storage in powers of 2, because that's what they work in. (This is less true when you work in higher level langauges, but if you don't take advantage of the powers of two that the algorithms are friendly with, it will cost you in performance, even if you don't realize it.)
To repeat another comment (paraphrased): The project should rename itself to "The Linux (Kernel) Devices Project", because their current name seems to cause massive confusion.
Yes, Linux *is* the kernel. But that's not how many people think of it. So this usage needs to be emphasized to avoid confusion.
You can think of "userspace" as the programs which can be run without special priviledges.
I think that few devices can be programmed in userspace...but device drivers can be accessed and instructed (I want to say programmed, but in this context that's ambiguous) from usersapce.
CUPS is one particular very complex driver. It's got it's own special project just to handle printers, because handling printers is complicated. (And the manufacturers don't make it easier.) It's also because handling printers is one of the first things that systems had to start doing. I think they were right after teletypes and before hard disks. (Not sure where tape drives fit in...or what interface they had.)
The result is that printer driver development is done through the CUPS project. The Linux Driver project was set up to deal with a bunch of later devices (light-pens, whatever). These are generally rather small devices...or at least they generally have rather small drivers. They also generally have a rather small number of users, who tend to be rather specialized.
P.S.: This *ISN'T* an authroitative reply. I've read a few articles is all, and was here watching as some history happened. But lots of projects "just grow". The Linux Drivers project wasn't one of the very early ones, so some driver projects got started before it ever showed up, and others started separately and never merged. (That might include SANE [Scanner Access Now Easy], but I'm not sure.)
Symbiotic is clearly proven by the publicly available evidence.
There is suggestive evidence that indicates that complicit and accessory before the fact are also reasonable things to believe, but it's only suggestive, not convincing.
OTOH, if I were to compare the probability of a politician chosen at random vs. a citizen (or and arab, for that matter) chosen at random, I'd bet that the politician was the more guilty, and the more directly involved. The evidence doesn't come close to "beyond a reasonable doubt", but it's definitely suggestive. It also doesn't follow party lines, exactly, though more of the evidence indicates Republican involvement, that may just be because of who was in control of the executive branch at the time (which might, or might not, be chance).
But if you coerce the confession from somebody who wasn't a member (or maybe even from somebody who was), then what you've got are a few more FALSE leads to expend time and effort on, and they real perpetrators get off free.
Congrats, US leaders: you managed to completely hose one of our main advantages in the "war" on terror. Sadly, the next crop (Hillary or Guliani, most likely) will be just as bad. Why? Because the majority of the voters buy into the 24 approach to terror. Which means we get the leaders we deserve.
No, they'll be just as bad because of the systematic structure of the US electorial system. It's a system where if you don't vote for the most popular candidate, you vote is worthless, so you need to guess which of the two bastard promulgated as the top two is least offensive...or you might just as well not vote.
I'm getting closer and closer to not bothering, since I can't really tell which is worse. I probably will, though, when push comes to shove, take some dramamine & some anti-acid and vote for one or the other of them. But the thought of being told how I've "given them a mandate" may make me vote for a third party. At least that way I'll be able to claim "it's not my fault, I voted for Kodos".
It turns out that this doesn't cover any patents. There's a patent license involved, but it doesn't offer terms compatible with ANY version of the GPL. Anyone who redistributes the code owes MS a percentage of the price. Even if you don't charge anything, this is incompatible with ALL versions of the GPL.
Considering that we are talking about the company that patented adding 2 and 2 using a computer, we can be fairly certain that covered patents will be involved, and I'd guess (just a guess) that there's language in there saying that if you challenge one of MS patents, you must pay not only your own legal fees, but theirs also.
So basically, this is a Does Not Apply deal insofar as FOSS software development is concerned, even for successful projects with financial backing. The 10,000 EU price is just the START of the reasons why. (Some, I admit, are speculative...but those come after the point where the deal is rendered totally unacceptable.)
I don't believe that they were offering to share the source code with developers under terms that would not prevent their being able to work on competitive products. I don't think they've ever offered that.
The impression that I got is that they were offering VERY limited access to their source code. They've done it before. The terms result in strongly restricting who can look at the code, so if you aren't well financed, with a corporation behind you, you could pretty much forget it.
I wonder what strings, besides the 10,000 EU fee, they're planning on this "offering". The news may be reporting it as a concession, but I won't believe it until I've examined the fine print. This is MS we're talking about here. (Even then, I'll be skeptical. They've pulled too many smooth backstabbings for me to trust them behind my back EVER. [IANAL, so legal verbage won't convince me it's safe to deal with them.])
You do realize that this will only be done for projects that have already been successful, don't you?
I'm sure that MS does. This means that the bar for getting started is just as high as it ever was. That's the purpose of the !0,000 EU price for the specs. I suspect that in order to purchase the specs they'll also require you to sign a NDA. Otherwise someone might publish a paraphrase.
Well, according to rumor they've been seen eating the insulation on the inside of the reactors...so the claim is that they can survive, at least for short periods of time, extensive radiation. (I don't think I've ever heard it claimed that somebody followed one of them and figured out whether it later died of radiation sickness, or was rendered sterile.)
And Larry Niven predicted that the one's doing this would be criminals, not governments.
Organleggers is still a good word, with the right definition. After all, the government doesn't acknowledge it, and has signed treaties forbidding it, so those doing it must be criminals.
This, then, is the source of our disagreement. I know, understand, trust, and like the GPL v2. As a result, I'm willing to accept that the GPL v3 is an attempt to be better.
You don't like it, so you aren't. Perfectly reasonable.
There are definitely circumstances where the GPL isn't the best license. Partially it depends on your objectives. E.g., Python comes under a much more liberal license than the GPL, and so does Ruby. They chose the best license that they could manage given their purposes. (Part of the reason for the Python license has to do with partial corporate ownership back in the mists of time.)
Still, for *my* purposes the GPL v3, as I understand it, (which isn't up to my understanding of GPL v2) is the optimal available license. YMMV.
Slashdot Mirror
Apple has made some changes in their EULA recently (or, possibly, I've recently noticed some features) that make them no longer an acceptable choice. They've added that obnoxious(paraphrase) "we have the right to add, remove, copy, or delete any files from your system". That makes them an unacceptable choice.
I agree that the observed effect is present. I'm proposing an alternative theory for how the effect is created.
This might be an interesting language for many purposes... just because those who created it had one purpose in mind, doesn't mean it can't be used elsewhere. But that depends on the license, which the article doesn't seem to mention.
The license clearly isn't BSD, but it could, conceivably, be GPL...depending on what the article writer translated into "Hancock's source code and binaries (now up to version 2.0) are available free to noncommercial users from an AT&T Research website. " (In the article there's a link to the source code site...but without knowing the license I'm not looking any further.)
Try it this way:
Nearly everyone's an idealog about things that matter to them. As the site increased the number of people posting, the divergence in views became larger between the different sections. Nothing makes a programmer be either left-wing, right-wing, or centrist. Any of those can be good programmers, so they all showed up. There's lots of libertarians...but this is political ideology, it doesn't easily translate into practical matters...except that it's highly consistent with FOSS, so there's a very strong libertarian streak that is also favorable to FOSS. (Note that this kind of libertarian isn't closely connected with what the Libertarian Party is talking about. There's some overlap, but not much.)
OTOH, programmers who are system designers tend to notice that designing a good system is hard work, and requires lots of cycles of error correction. So in areas where they think carefully, they tend to be opposed to design decisions that are top-down and difficult to fix design errors in. But this is only in areas where they think carefully, and nobody does that in most of the places that they're operating. Too inefficient.
There's probably more factors involved, but those are the ones that I notice off the top of my head, and they would predict the effects that you have noticed.
He's probably running the version of Eclipse that's compiled with gcj...i.e., native code.
I notice that you're reporting a consensus of the manufacturers.
Their opinion is in direct contrast with other opinions that I've heard recently (although not specifically about "InPhase". The opinions that I've seen put the shelf life at a couple of years...and specifically said that after about a decade the plastic would be so degraded that it couldn't safely be handled without cracking, and that it would have lost much of it's transparency. And that's only if you had stored it under ideal conditions (at standard temperature and pressure...but no light exposure at all, and sealed).
Now it's true that the comments were about standard DVDs. And they did admit that the original CDs (the ones on metalic films between glass plates, with pits burned into the metal to write [not a mere phase change of an alloy]) could be expected to last indefinitely...and even to be playable for centuries if stored under reasonable conditions (which included flat with no uneven pressure on them). But this wasn't true of the modern reformulations which were designed to allow low powered lasers in customer equipment to write them.
I notice that the CILR report specifically claims stability for the plastic used to seal the disks. This was specifically denied by the other report that I read, so that gives you one particular thing to investigate before you decide that the report is trustworthy. The other claim, that the phase-change alloy wasn't stable over time, would be much more difficult to check, and different DVDs might well use different alloys, so what is true for one might well not be true of another.
P.S.: I'm skeptical of BOTH reports. Current DVDs haven't existed in their current form for any natural aging tests to have been done. As a result, any projections of the stability of the current disks are, at best, educated guesses. Accelerated aging tests have a very poor history, being quite succeptible to biased or otherwise improper guesses as to what kinds of stress would mimic natural aging in a shorter timespan.
Unh...about those "soft spots":
such as the relatively limited number of write cycles
You *are* aware that this particular soft spot only exists because it doesn't matter for the designated application, aren't you? It's cheaper to build flash ram that wears out more quickly, and "more quickly" is sufficiently far in the future that most people will lose their thumb drive before they ever encounter this problem. If they cared, they'd use wear-leveling NAND flash, but it's cheaper not to, and the current version is "good enough for the purpose".
If they wanted faster speed, they could "RAID" the chips. They don't want the extra cost and complexity.
So your "soft spots" don't exist.
Presumably the people who licensed the patents got a better idea of what they were buying, but from here it looks like the target is either a video distribution system, a hard disk replacement for portables, or both. Whether either or both of these are practical depends on lots of details that won't show up in the popular press. Also, these guys are research scientists, not production engineers. The virtues and downfalls of their lab model don't say that much about what the production-for-sale model will be like.
If she's not a computer professional, why is she worried about the disk size? Her question should be "Is it big enough?", not "How many bytes is it?"
That said, if she's not a computer professional, the answer to "Is it big enough?" is almost certain to be "Yes", unless she's using Vista, or some other recently-released giganticaly-humongous OS. (I'm counting animators, architects, etc. as computer professionals. They have legitimate reasons to wonder whether the disk is big enough, But such people probably have someone else do the sizing for them...so it's still a computer systems professional [i.e., not someone who professionally uses computers, but someone whose profession centers around computes] who really estimates "What is 'big enough' in Megabytes?".)
Sorry, but for certain algorithms it's important that you are working in powers of 2, and that was always called Mega (Bits, Bytes, Words, whatever) or, more commonly Kilo-whatever was 2^10 whatevers.
IO has always been a mixture and compromise. Punched cards could hold 12 * 72 bits (7094 row binary) or 12 * 80 bits (column binary, but don't try to read it with the main card reader). Try to fit THAT into your "powers of 10" scenario!
For the current set of IO devices, capacity measurement was defined by marketing. I saw arguments about it in the trade journals when it was being fought out over hard disks. AFAIK, companies decided independently the choice that was, to them, most advantageous. It was powers of 10. This was not appreciated by any single customer that I was aware of. Some despised it, some didn't care, nobody was in favor. (Yeah, it was a small sample, but it's one that I was aware of. Most didn't care, and many of those weren't interested in understanding.)
But block allocations of RAM are done in powers of two, and these are frequently mapped directly to IO devices. So having a mis-match creates problems. Disk files were (possibly) created as an answer to this problem. (7094 drum storage didn't have files. Things were addressed by drum address. If a piece went bad, you had to patch your program to avoid it. UGH! Tape was for persistent data, drum storage was transient...just slightly more persistent than RAM.) Drum addresses were tricky. I never did it myself, but some people improved performance by timing the instructions so that they would have the drum head right before the data they wanted to read or write to limit lagging. (Naturally this was all done in assembler, so you could count out exactly how many miliseconds of execution time you were committing, and if you know the drum rotation speed, and the latency...
So things tended to be stored in powers of two positions on the drum, unless a piece went bad.
Disks, when they first appeared, were slower than drums, but more capacious. (They were still too expensive and unreliable to use for persistent storage.) But the habit of mapping things out in powers of two transferred from drums storage to disk storage. When files were introduced (not sure about when that was) the habit transferred. This wasn't all blind habit, lots of the I/O techniques that had been developed were dependent upon powers of two. So programmers though of capacity in powers of two. This didn't make any sense to accountants, managers, etc. When computer equipment started being sold by the Megabyte it made sense to the manufacturers to claim powers of 10 Megabytes for stroage, as they could claim larger sizes. (This wasn't as significant for Kilobytes, as 1024 is pretty close to 1000.) It not only made sense to the manufacturers, it also made sense to the accountants who were approving the orders. And when the managers started specifying the equipment...well, everything switched over into being measured by powers of 10.
No conspiracy. Just system dynamics. And programmers still think of storage in powers of 2, because that's what they work in. (This is less true when you work in higher level langauges, but if you don't take advantage of the powers of two that the algorithms are friendly with, it will cost you in performance, even if you don't realize it.)
All they need to do is get the cost and MTBF in the right place and the Terrabyte memory will appear.
To repeat another comment (paraphrased):
The project should rename itself to "The Linux (Kernel) Devices Project", because their current name seems to cause massive confusion.
Yes, Linux *is* the kernel. But that's not how many people think of it. So this usage needs to be emphasized to avoid confusion.
You can think of "userspace" as the programs which can be run without special priviledges.
I think that few devices can be programmed in userspace...but device drivers can be accessed and instructed (I want to say programmed, but in this context that's ambiguous) from usersapce.
CUPS is one particular very complex driver. It's got it's own special project just to handle printers, because handling printers is complicated. (And the manufacturers don't make it easier.) It's also because handling printers is one of the first things that systems had to start doing. I think they were right after teletypes and before hard disks. (Not sure where tape drives fit in...or what interface they had.)
The result is that printer driver development is done through the CUPS project. The Linux Driver project was set up to deal with a bunch of later devices (light-pens, whatever). These are generally rather small devices...or at least they generally have rather small drivers. They also generally have a rather small number of users, who tend to be rather specialized.
P.S.: This *ISN'T* an authroitative reply. I've read a few articles is all, and was here watching as some history happened. But lots of projects "just grow". The Linux Drivers project wasn't one of the very early ones, so some driver projects got started before it ever showed up, and others started separately and never merged. (That might include SANE [Scanner Access Now Easy], but I'm not sure.)
The devil is in the details.
As appologies go, I'm less than impressed.
To me it seems more like his last payment check bounced. (Which also sums up what I think of him as a "journalist".)
Symbiotic is clearly proven by the publicly available evidence.
There is suggestive evidence that indicates that complicit and accessory before the fact are also reasonable things to believe, but it's only suggestive, not convincing.
OTOH, if I were to compare the probability of a politician chosen at random vs. a citizen (or and arab, for that matter) chosen at random, I'd bet that the politician was the more guilty, and the more directly involved. The evidence doesn't come close to "beyond a reasonable doubt", but it's definitely suggestive. It also doesn't follow party lines, exactly, though more of the evidence indicates Republican involvement, that may just be because of who was in control of the executive branch at the time (which might, or might not, be chance).
That's ok, you just need to install some new drivers to fix it...
Whoops!
If you're doing math, rather than politics, then the money is in science rather than religion.
If conversely, conversely.
But if you coerce the confession from somebody who wasn't a member (or maybe even from somebody who was), then what you've got are a few more FALSE leads to expend time and effort on, and they real perpetrators get off free.
Congrats, US leaders: you managed to completely hose one of our main advantages in the "war" on terror. Sadly, the next crop (Hillary or Guliani, most likely) will be just as bad. Why? Because the majority of the voters buy into the 24 approach to terror. Which means we get the leaders we deserve.
No, they'll be just as bad because of the systematic structure of the US electorial system. It's a system where if you don't vote for the most popular candidate, you vote is worthless, so you need to guess which of the two bastard promulgated as the top two is least offensive...or you might just as well not vote.
I'm getting closer and closer to not bothering, since I can't really tell which is worse. I probably will, though, when push comes to shove, take some dramamine & some anti-acid and vote for one or the other of them. But the thought of being told how I've "given them a mandate" may make me vote for a third party. At least that way I'll be able to claim "it's not my fault, I voted for Kodos".
I did a bit more reading.
It turns out that this doesn't cover any patents. There's a patent license involved, but it doesn't offer terms compatible with ANY version of the GPL. Anyone who redistributes the code owes MS a percentage of the price. Even if you don't charge anything, this is incompatible with ALL versions of the GPL.
Considering that we are talking about the company that patented adding 2 and 2 using a computer, we can be fairly certain that covered patents will be involved, and I'd guess (just a guess) that there's language in there saying that if you challenge one of MS patents, you must pay not only your own legal fees, but theirs also.
So basically, this is a Does Not Apply deal insofar as FOSS software development is concerned, even for successful projects with financial backing. The 10,000 EU price is just the START of the reasons why. (Some, I admit, are speculative...but those come after the point where the deal is rendered totally unacceptable.)
I don't believe that they were offering to share the source code with developers under terms that would not prevent their being able to work on competitive products. I don't think they've ever offered that.
The impression that I got is that they were offering VERY limited access to their source code. They've done it before. The terms result in strongly restricting who can look at the code, so if you aren't well financed, with a corporation behind you, you could pretty much forget it.
I wonder what strings, besides the 10,000 EU fee, they're planning on this "offering". The news may be reporting it as a concession, but I won't believe it until I've examined the fine print. This is MS we're talking about here. (Even then, I'll be skeptical. They've pulled too many smooth backstabbings for me to trust them behind my back EVER. [IANAL, so legal verbage won't convince me it's safe to deal with them.])
You do realize that this will only be done for projects that have already been successful, don't you?
I'm sure that MS does. This means that the bar for getting started is just as high as it ever was. That's the purpose of the !0,000 EU price for the specs. I suspect that in order to purchase the specs they'll also require you to sign a NDA. Otherwise someone might publish a paraphrase.
Well, according to rumor they've been seen eating the insulation on the inside of the reactors...so the claim is that they can survive, at least for short periods of time, extensive radiation. (I don't think I've ever heard it claimed that somebody followed one of them and figured out whether it later died of radiation sickness, or was rendered sterile.)
And Larry Niven predicted that the one's doing this would be criminals, not governments.
Organleggers is still a good word, with the right definition. After all, the government doesn't acknowledge it, and has signed treaties forbidding it, so those doing it must be criminals.
This, then, is the source of our disagreement. I know, understand, trust, and like the GPL v2. As a result, I'm willing to accept that the GPL v3 is an attempt to be better.
You don't like it, so you aren't. Perfectly reasonable.
There are definitely circumstances where the GPL isn't the best license. Partially it depends on your objectives. E.g., Python comes under a much more liberal license than the GPL, and so does Ruby. They chose the best license that they could manage given their purposes. (Part of the reason for the Python license has to do with partial corporate ownership back in the mists of time.)
Still, for *my* purposes the GPL v3, as I understand it, (which isn't up to my understanding of GPL v2) is the optimal available license. YMMV.