We often see the scientific community putting manned spaceflight down, saying that it is not useful for scientific research. Had we sent people, with even a minimal laboratory, we'd have known within about 15 minutes whether what they were digging up was ice or not. Since the lander doesn't have an "ice" experiment/module on board, we're reduced to guess work.
The reality is that manned spaceflight is not *economical* for scientific research at this point. We should be working on getting our launch costs down so that we could actually send people to do things, build factories in space, and start getting some real benefit out of space.
Patents were originally about implementations. You had to send a little working model along with your patent application. Now, you can just dream up something and then file for a patent. Requiring actual reduction to practice would get rid of the patent trolls - if you've gone to the work of actually creating your invention, even in software, then you now have something you can sell and you don't need to go looking for people to smack with your patents.
Actual reduction to practice by requiring inventors to submit an actual working model (could even be a computer simulation) or working source code, a smack down on trivial patents and fines for not disclosing prior art and lawsuits where the patent does not actual cover the device you're suing over.
Oh, and if you get a software patent you have to disclose your source code and it is *not* copyrightable, that is, after the patent expires your source code is now public domain.
x86 succeeded for exactly one reason - volume. If IBM had chosen the 68K over the x86 we'd be using that today.
Back in the 80's it was a lot cheaper to develop a processor. They were considerably simpler and slower. The reason there were so many processor architectures around back them was that it was feasible for a small team to develop a processor from scratch. It was even possible for a small team to build, out of discrete components, a processor that was (significantly) faster than a fully integrated microprocessor, e.g. the Cray-1.
As the semiconductor processes improved and more, faster, transistors could get squeezed onto a chip, the complexity and the speed of microprocessors increased. Where you're at today is that it takes a billion dollar fab and a huge design team to create a competitive microprocessor. x86 has succeeded because there is such a torrent of money flowing into Intel from x86 sales that it is able to build those fabs and fund those design teams.
PowerPC, for example, was a much smaller effort than Intel back in the mid-90's. PowerPC was able, for a short time, to significantly outperform Intel and remained fairly competitive for quite a while even though the design team was much smaller and the semiconductor process was not as sophisticated as Intel's. The reason for that was that the architecture was much better designed than Intel, making it easier to get more performance for fewer $$. Eventually, however, the huge amount of $$ going into x86 allowed Intel to pull ahead.
Any datacenter is subject to some form of catastrophe that will take it completely offline. They had an explosion in the power room - that's pretty wild and pretty nasty. Similarly, a good fire could take the whole place down, or a plane could crash into the building. If you're making enough money to miss the revenue, perhaps you should have a second server at another DC (preferably with a different provider).
I've had a server in that building for years now, and this is the first major outage we've had. If I were losing enough money to bitch about, I'd be kicking myself for not making sure that things didn't fail over to a completely different DC.
I'm not sure about your comments about the target audience not fitting into the "moderately competent" range. I've been doing systems admin for over 20 years, starting with DEC RSTS/E and going through just about every flavor of Unix. Mostly I do software development, though, and if the boxes in my business are working I don't spend my days messing with them.
Linux is a moving target for competence. Different distributions do things differently and they are all constantly changing. A lot of times I know how to do something - I just don't always know the *right* way to do something. I can build and install packages from the source, fix bugs in the scripts, etc. But then, the next update of the distribution comes along and screws me. So, I wind up spending more time than I would like to trying to figure out what the *right* way to do things is. Or, I know *what* I want to do, but how to do it under Linux is not immediately obvious.
I will probably order a copy of the book because it will be helpful when I have to do a task that I only do once a year or so. I hope they will continue to update it, though, as it will be out of date quite soon.
The solution is simple, really. Everyone in the world needs to have a subscription to National Geographic. Since no one ever throws out a National Geographic, all of the world's excess CO2 can be stored in people's attics and storage spaces.
"Amateurs study tactics, armchair generals study strategy, but professionals study logistics"
The military isn't looking at these for front line combat, at least not initially. They're looking at these for logistical support. Modern militaries depend on lots of supplies that needs to be moved around, loaded on trucks, etc. Often supplies need to be shifted around in places where something like a forklift won't be very effective (think loading a tank full of shells off a truck in a gully someplace). That's what this is targeted for.
If you're going to count the Vegas monorail then you should count the Disney monorails as well.
But seriously, there's no reason for high speed rail to take a long time to board. I take the shinkansen here in Japan all the time. Dwell times at the platforms are less than a minute typically (unless you're waiting in a station for a limited express to pass by - yes, there are "regular" shinkansen and "express" as well.) No security nonsense. There's no 9/11 scenarios for trains and you can always stop them and get the cops over for regular hostage taking.
One thing that makes the passenger loading quick on the shinkansen is that most people in Japan don't carry their baggage. If you have more than a carry-on it gets shipped by the equivalent of UPS - door to door service no less!
I rode the Eurostar once from London to Paris and I was really dismayed at how hard they had worked to turn the very pleasant train experience into a stress-filled airport like experience. Waiting lounges, baggage check-ins, etc. I like going to the platform and just waiting for the train.
Oh, and the other great thing about the shinkansen that isn't possible except on the really heavily used routes - they leave every 5-10 minutes. If you miss yours, just take the next one! That just removes so much stress from the whole process.
No, the key is a small sample size. Disks in data centers, running in a nice, fully A/C'd room off nicely filtered power will fail. All disks will fail eventually - they have little spinny things in them and bearings and such that will eventually give out. But, your mileage will vary, disks *are* reliable, and it's easy to have a small sample set that works well.
I looked at doing battery backed RAM cache back in the early nineties. At the time, NFS servers were either slow or expensive (Auspex) and it was pretty obvious that one of the things that really slowed them down was the NFS requirement to commit changes to disk before acknowledging the write. So, battery backed RAM write cache!
NetApp had the same idea and brought it to market. If you look at the design of WAFL (NetApp's Write Anywhere File System), it is basically dependent on having a large, stable RAM cache. Doesn't work if the RAM cache isn't stable.
The question that Daniel (the author of the patch) posed was "You just need to believe in your battery, Linux and the hardware it runs on. Which of these do you mistrust?" The answer is - all three. NetApp delivers a quality product that is engineered to work the way it needs to. Trying to get it to work with a bunch of off-the-shelf stuff not designed to do it is a recipe for disaster.
The nuclear cat is out of the bag, and as long as the US has a single nuke, they have no place to lecture others about non-proliferation.
Depends on how you want to come at it. I don't think the US (and I'm an American) can come at it from the "moral high ground." There's no doubt, though, that non-proliferation is in the United States' best interests and, let's be real, it's in the best interests of just about everyone else in the world. I believe today's world would be better off if no country, including the United States, had nuclear weapons. However, honestly, do you think that Pakistan or Iran or North Korea with nuclear weapons makes the world a better place for anyone?
Efficiency improvements and increased use of renewables don't have to be developed. They're here. They just need to be deployed. Rather than putting that money into building fission reactors, put it toward equipping homes with high-efficiency heat pumps (ground-source ones in cold climates), good insulation, a PV module or small windmill, and efficient appliances. We also need investment in mass transit - and in community planning so people don't have to drive all over creation to get shit done. This is all stuff we could do right now, today, without needing to wait in line for a steel factory in Japan to make special reactor vessels.
You think that all that getting all that done, by people, all over the place who really don't care (because electricity isn't expensive enough to force the issue) is easier than waiting for these reactor vessels to be forged?
I think orbital solar is a great idea. Launch costs are way too damn high though. You think that fixing the launcher problem and building solar arrays in space is easier than waiting for a steel factory in Japan?
On the home front, I went through a few months ago and replaced all of the incandescent bulbs in our house with CFL's (with a nice spectrum). Worked great, lighting was fine, electricity bill even went down a bit. Then we moved and the new house has all of these fixtures that take a miniature 60 watt bulb. No CFL's that will fit that I can find. So, I can either eat the electricity bill for a few years until either small LEDs are cost effective or someone makes a mini CFL that will fit or I can replace all the fixtures (there's over a dozen). Guess which option I'm taking?
Dropping in nuclear power plants, as difficult and messy as it may be, is the probably the easiest way to drop CO2, mercury emissions, and other pollutants from electrical generation. The other option (I don't think renewables are up to taking over the base load that coal and hydro have right now) is to get people to drop their energy usage and the only way to do that is to raise the price of energy so high that we'll go through a depression before all of the efficiency improvements are put in place.
Of course ndiswrapper can be distributed in binary form under the GPL. All of the sources are available for it and it can be built and run. Ndiswrapper does not depend on proprietary code - it enables proprietary code. Saying that ndiswrapper can't be distributed in binary form because it enables proprietary code is like saying that Linux can't be distributed in binary form because it enables proprietary code. ndiswrapper is complete without any modules loaded. It's ready to load modules.
Another poster made a very good point. The GPLONLY flag for the kernel basically is there so that kernel developers can know whether or not all of the sources are available for the running kernel and hence how much trouble it's going to be tracking down a bug that is reported. The flag should really be named something like SOURCESAVAILABLE. If you look at it from the point of view, flagging ndiswrapper might be appropriate - though, the correct thing would be for ndiswrapper to set the flag based on which modules it has loaded. It is possible to have open source Windows drivers though I'm not sure how there are.
However, you're arguing from a legal point of view that this or that may or may not be GPL'd and, I'm sorry, but you're wrong.
Yes, that is part of the GPL. However, it doesn't imply what you think it implies.
That section, "Source Code" does not define what you can distribute under the GPL. It is part of a legal document and is there to define "Source Code" as it is used in the rest of the document. Think of it as a #define.
Now, what does "Corresponding Source" apply to? It applies to someone, not the owner, distributing the code *in object code form* under the license. This clause is there so that if someone *modifies* a piece of GPL'd code, that they do not own, to depend upon a proprietary library they cannot distribute the it without putting that proprietary library under the GPL as well. Or, if it needs a particular script to be built, etc. It only applies when distributing the code in object form ("The "Corresponding Source" for a work in object code form").
The second paragraph following that is:
The Corresponding Source for a work in source code form is that same work.
So, if you're distributing code in source form, you're distributing the source code. (Of course, you would have to *only* be distributing it in source form, otherwise the provisions for distributing it in object form would kick in as well).
The GPL's clauses do not apply to the owner. They apply to people *distributing* (not copying, not using) the code under the terms of the license (Section 2, Basic Permissions - You may make, run and propagate covered works that you do not convey, without conditions so long as your license otherwise remains in force.). If you own the code you *ARE NOT SUBJECT TO THE TERMS OF THE LICENSE* - you *own* it, you're not licensed for it. Of course, in order for something to be useful when GPL'd people need to be able to distribute it in compliance with the license. However, things like a fragment of code are covered. If a fragment of code is licensed under the GPL you can distribute that, as just the source, and be in full compliance with the GPL ("The Corresponding Source for a work in source code form is that same work."). If not, then people would not be able to distribute patches to GPL'd code. Your patch is a derivative work under the GPL, however since you are distributing it in source form all you need to distribute is the source, not the whole kit and kaboodle.
The GPL uses "you" throughout it. "You" is not referring to someone who owns code putting it under the license. It refers to someone who is receiving code under the license. There are no restrictions on what you can slap the GPL on. You could attach it as the license to something that you are only distributing in object form. It just wouldn't be a useful license to the receiver since they would not be able to distribute what you gave them (since they're required to distribute source) and would kind of miss the whole point of the GPL.
If there's no outrage against it, it *will* get passed. These are the kind of laws that lazy law enforcement types love. They bring them again and again until they slip through somehow.
The US has been passing stupid laws left and right in the wake of "9-11". Australia doesn't have to be so stupid. Be upset or it will happen.
Your first four examples all boil down to "You don't own the copyright" (or, you've given the copyright away irrevocably for number 4). That's true for any license since you can't license what you don't own.
Where in the GPL does it say anything about not being able to GPL part of a proprietary program? Of course you can. It may not be useful but you can do it. There is no GPL authority to determine what you can and cannot license under the GPL. It is a license that you get to put on your own copyrighted materials.
You're trying to cite hacker lore as legal precedent. Sorry, it don't fly. There's nothing in the license or in copyright law that requires you to license usable software or even a complete work. If there were, Microsoft would have been run out of business long ago.
There's a big difference between being the owner and licensing the code and being a user of the code and being bound by the license. The owner has very few restrictions, other than, as you pointed out, actually being the owner.
Soyuz is still flying! How do you think those tourist guys get to the space station? Hint - NASA doesn't sell things.
A quick look at Wikipedia shows there have been 98 manned Soyuz missions to date and 121 Shuttle missions. Additionally, you could include the Progress missions which have been used to supply both Mir and the ISS - Progress is an unmanned spacecraft based on the Soyuz design. There have been 114 Progress flights.
Bzzt - wrong. GPL is a one way street, not a two way street. There are no negative requirements in the GPL. *Anything* can be placed under the GPL.
Where GPL requirements come into play is that the GPL sometimes requires code to be placed under the GPL. Code that is derived from GPL licensed code *must* be placed under the GPL. Derived code has been held to be both code that is a modification of a piece of code *and* code that is linked to and depended on, like a library. It's a one way street, though. If you make something like ndiswrapper it can be released under the GPL. The fact the ndiswrapper provides functions to proprietary code doesn't have any bearing on its GPL status. And, the fact that proprietary code is now linked to ndiswrapper doesn't force the proprietary code to become GPL'd - it doesn't depend on ndiswrapper and it wasn't linked with ndiswrapper by its creator and distributor.
This is a good explanation. I think the problem is the the GPLONLY variable is misnamed. It should be called something like "SOURCEAVAILABLE".
As a result of the misnaming the argument moved into whether or not ndiswrapper is GPL'd and, it is. The GPL is a license that applies to copyright issues. Those issues are copying (distribution) and creation of derivative works. ndiswrapper complies with the GPL and is licensed under the GPL and is freely distributed. Just because ndiswrapper is primarily used with non-GPL code does not make it non-GPL. There's nothing in the GPL that says that GPL code cannot work with non-GPL code. It says that if you make derivative works of GPL code then your code must also be GPL'd. The proprietary drivers are not derivative works of ndiswrapper or the Linux kernel (they're Windows drivers and their authors may never even have seen Linux internals) and really have no bearing on the GPL/non-GPL status of ndiswrapper. ndiswrapper is licensed under the GPL and all of its source code is freely available. It may seem like a legalistic argument, but the GPL *is* a legal instrument.
The argument should have been that ndiswrapper will load modules that make debugging hard or impossible - which is factually true.
Well, long ago, we used to consider the kernel as the OS. It wasn't until MS started their nonsense with how the browser was really part of the OS that people started extending the definition of an OS.
Slashdot Mirror
We often see the scientific community putting manned spaceflight down, saying that it is not useful for scientific research. Had we sent people, with even a minimal laboratory, we'd have known within about 15 minutes whether what they were digging up was ice or not. Since the lander doesn't have an "ice" experiment/module on board, we're reduced to guess work.
The reality is that manned spaceflight is not *economical* for scientific research at this point. We should be working on getting our launch costs down so that we could actually send people to do things, build factories in space, and start getting some real benefit out of space.
Heh - only one problem. The moon is not in geosynchronous orbit so you would need to have multiple collectors on Earth.
Patents were originally about implementations. You had to send a little working model along with your patent application. Now, you can just dream up something and then file for a patent. Requiring actual reduction to practice would get rid of the patent trolls - if you've gone to the work of actually creating your invention, even in software, then you now have something you can sell and you don't need to go looking for people to smack with your patents.
Actual reduction to practice by requiring inventors to submit an actual working model (could even be a computer simulation) or working source code, a smack down on trivial patents and fines for not disclosing prior art and lawsuits where the patent does not actual cover the device you're suing over.
Oh, and if you get a software patent you have to disclose your source code and it is *not* copyrightable, that is, after the patent expires your source code is now public domain.
x86 succeeded for exactly one reason - volume. If IBM had chosen the 68K over the x86 we'd be using that today.
Back in the 80's it was a lot cheaper to develop a processor. They were considerably simpler and slower. The reason there were so many processor architectures around back them was that it was feasible for a small team to develop a processor from scratch. It was even possible for a small team to build, out of discrete components, a processor that was (significantly) faster than a fully integrated microprocessor, e.g. the Cray-1.
As the semiconductor processes improved and more, faster, transistors could get squeezed onto a chip, the complexity and the speed of microprocessors increased. Where you're at today is that it takes a billion dollar fab and a huge design team to create a competitive microprocessor. x86 has succeeded because there is such a torrent of money flowing into Intel from x86 sales that it is able to build those fabs and fund those design teams.
PowerPC, for example, was a much smaller effort than Intel back in the mid-90's. PowerPC was able, for a short time, to significantly outperform Intel and remained fairly competitive for quite a while even though the design team was much smaller and the semiconductor process was not as sophisticated as Intel's. The reason for that was that the architecture was much better designed than Intel, making it easier to get more performance for fewer $$. Eventually, however, the huge amount of $$ going into x86 allowed Intel to pull ahead.
Any datacenter is subject to some form of catastrophe that will take it completely offline. They had an explosion in the power room - that's pretty wild and pretty nasty. Similarly, a good fire could take the whole place down, or a plane could crash into the building. If you're making enough money to miss the revenue, perhaps you should have a second server at another DC (preferably with a different provider).
I've had a server in that building for years now, and this is the first major outage we've had. If I were losing enough money to bitch about, I'd be kicking myself for not making sure that things didn't fail over to a completely different DC.
I'm not sure about your comments about the target audience not fitting into the "moderately competent" range. I've been doing systems admin for over 20 years, starting with DEC RSTS/E and going through just about every flavor of Unix. Mostly I do software development, though, and if the boxes in my business are working I don't spend my days messing with them.
Linux is a moving target for competence. Different distributions do things differently and they are all constantly changing. A lot of times I know how to do something - I just don't always know the *right* way to do something. I can build and install packages from the source, fix bugs in the scripts, etc. But then, the next update of the distribution comes along and screws me. So, I wind up spending more time than I would like to trying to figure out what the *right* way to do things is. Or, I know *what* I want to do, but how to do it under Linux is not immediately obvious.
I will probably order a copy of the book because it will be helpful when I have to do a task that I only do once a year or so. I hope they will continue to update it, though, as it will be out of date quite soon.
The solution is simple, really. Everyone in the world needs to have a subscription to National Geographic. Since no one ever throws out a National Geographic, all of the world's excess CO2 can be stored in people's attics and storage spaces.
OK, next problem please.
"Amateurs study tactics, armchair generals study strategy, but professionals study logistics"
The military isn't looking at these for front line combat, at least not initially. They're looking at these for logistical support. Modern militaries depend on lots of supplies that needs to be moved around, loaded on trucks, etc. Often supplies need to be shifted around in places where something like a forklift won't be very effective (think loading a tank full of shells off a truck in a gully someplace). That's what this is targeted for.
Well, lots of embedded systems work is done in C and there is a *lot* of embedded code running around in the world.
If you're going to count the Vegas monorail then you should count the Disney monorails as well.
But seriously, there's no reason for high speed rail to take a long time to board. I take the shinkansen here in Japan all the time. Dwell times at the platforms are less than a minute typically (unless you're waiting in a station for a limited express to pass by - yes, there are "regular" shinkansen and "express" as well.) No security nonsense. There's no 9/11 scenarios for trains and you can always stop them and get the cops over for regular hostage taking.
One thing that makes the passenger loading quick on the shinkansen is that most people in Japan don't carry their baggage. If you have more than a carry-on it gets shipped by the equivalent of UPS - door to door service no less!
I rode the Eurostar once from London to Paris and I was really dismayed at how hard they had worked to turn the very pleasant train experience into a stress-filled airport like experience. Waiting lounges, baggage check-ins, etc. I like going to the platform and just waiting for the train.
Oh, and the other great thing about the shinkansen that isn't possible except on the really heavily used routes - they leave every 5-10 minutes. If you miss yours, just take the next one! That just removes so much stress from the whole process.
Yah, that's damn expensive trash bag.
No, the key is a small sample size. Disks in data centers, running in a nice, fully A/C'd room off nicely filtered power will fail. All disks will fail eventually - they have little spinny things in them and bearings and such that will eventually give out. But, your mileage will vary, disks *are* reliable, and it's easy to have a small sample set that works well.
I looked at doing battery backed RAM cache back in the early nineties. At the time, NFS servers were either slow or expensive (Auspex) and it was pretty obvious that one of the things that really slowed them down was the NFS requirement to commit changes to disk before acknowledging the write. So, battery backed RAM write cache!
NetApp had the same idea and brought it to market. If you look at the design of WAFL (NetApp's Write Anywhere File System), it is basically dependent on having a large, stable RAM cache. Doesn't work if the RAM cache isn't stable.
The question that Daniel (the author of the patch) posed was "You just need to believe in your battery, Linux and the hardware it runs on. Which of these do you mistrust?" The answer is - all three. NetApp delivers a quality product that is engineered to work the way it needs to. Trying to get it to work with a bunch of off-the-shelf stuff not designed to do it is a recipe for disaster.
The nuclear cat is out of the bag, and as long as the US has a single nuke, they have no place to lecture others about non-proliferation.
Depends on how you want to come at it. I don't think the US (and I'm an American) can come at it from the "moral high ground." There's no doubt, though, that non-proliferation is in the United States' best interests and, let's be real, it's in the best interests of just about everyone else in the world. I believe today's world would be better off if no country, including the United States, had nuclear weapons. However, honestly, do you think that Pakistan or Iran or North Korea with nuclear weapons makes the world a better place for anyone?
Go for it! Make it work at your house and I'll buy one from you.
Efficiency improvements and increased use of renewables don't have to be developed. They're here. They just need to be deployed. Rather than putting that money into building fission reactors, put it toward equipping homes with high-efficiency heat pumps (ground-source ones in cold climates), good insulation, a PV module or small windmill, and efficient appliances. We also need investment in mass transit - and in community planning so people don't have to drive all over creation to get shit done. This is all stuff we could do right now, today, without needing to wait in line for a steel factory in Japan to make special reactor vessels.
You think that all that getting all that done, by people, all over the place who really don't care (because electricity isn't expensive enough to force the issue) is easier than waiting for these reactor vessels to be forged?
I think orbital solar is a great idea. Launch costs are way too damn high though. You think that fixing the launcher problem and building solar arrays in space is easier than waiting for a steel factory in Japan?
On the home front, I went through a few months ago and replaced all of the incandescent bulbs in our house with CFL's (with a nice spectrum). Worked great, lighting was fine, electricity bill even went down a bit. Then we moved and the new house has all of these fixtures that take a miniature 60 watt bulb. No CFL's that will fit that I can find. So, I can either eat the electricity bill for a few years until either small LEDs are cost effective or someone makes a mini CFL that will fit or I can replace all the fixtures (there's over a dozen). Guess which option I'm taking?
Dropping in nuclear power plants, as difficult and messy as it may be, is the probably the easiest way to drop CO2, mercury emissions, and other pollutants from electrical generation. The other option (I don't think renewables are up to taking over the base load that coal and hydro have right now) is to get people to drop their energy usage and the only way to do that is to raise the price of energy so high that we'll go through a depression before all of the efficiency improvements are put in place.
Of course ndiswrapper can be distributed in binary form under the GPL. All of the sources are available for it and it can be built and run. Ndiswrapper does not depend on proprietary code - it enables proprietary code. Saying that ndiswrapper can't be distributed in binary form because it enables proprietary code is like saying that Linux can't be distributed in binary form because it enables proprietary code. ndiswrapper is complete without any modules loaded. It's ready to load modules.
Another poster made a very good point. The GPLONLY flag for the kernel basically is there so that kernel developers can know whether or not all of the sources are available for the running kernel and hence how much trouble it's going to be tracking down a bug that is reported. The flag should really be named something like SOURCESAVAILABLE. If you look at it from the point of view, flagging ndiswrapper might be appropriate - though, the correct thing would be for ndiswrapper to set the flag based on which modules it has loaded. It is possible to have open source Windows drivers though I'm not sure how there are.
However, you're arguing from a legal point of view that this or that may or may not be GPL'd and, I'm sorry, but you're wrong.
Yes, that is part of the GPL. However, it doesn't imply what you think it implies.
That section, "Source Code" does not define what you can distribute under the GPL. It is part of a legal document and is there to define "Source Code" as it is used in the rest of the document. Think of it as a #define.
Now, what does "Corresponding Source" apply to? It applies to someone, not the owner, distributing the code *in object code form* under the license. This clause is there so that if someone *modifies* a piece of GPL'd code, that they do not own, to depend upon a proprietary library they cannot distribute the it without putting that proprietary library under the GPL as well. Or, if it needs a particular script to be built, etc. It only applies when distributing the code in object form ("The "Corresponding Source" for a work in object code form").
The second paragraph following that is:
The Corresponding Source for a work in source code form is that same work.
So, if you're distributing code in source form, you're distributing the source code. (Of course, you would have to *only* be distributing it in source form, otherwise the provisions for distributing it in object form would kick in as well).
The GPL's clauses do not apply to the owner. They apply to people *distributing* (not copying, not using) the code under the terms of the license (Section 2, Basic Permissions - You may make, run and propagate covered works that you do not convey, without conditions so long as your license otherwise remains in force.). If you own the code you *ARE NOT SUBJECT TO THE TERMS OF THE LICENSE* - you *own* it, you're not licensed for it. Of course, in order for something to be useful when GPL'd people need to be able to distribute it in compliance with the license. However, things like a fragment of code are covered. If a fragment of code is licensed under the GPL you can distribute that, as just the source, and be in full compliance with the GPL ("The Corresponding Source for a work in source code form is that same work."). If not, then people would not be able to distribute patches to GPL'd code. Your patch is a derivative work under the GPL, however since you are distributing it in source form all you need to distribute is the source, not the whole kit and kaboodle.
The GPL uses "you" throughout it. "You" is not referring to someone who owns code putting it under the license. It refers to someone who is receiving code under the license. There are no restrictions on what you can slap the GPL on. You could attach it as the license to something that you are only distributing in object form. It just wouldn't be a useful license to the receiver since they would not be able to distribute what you gave them (since they're required to distribute source) and would kind of miss the whole point of the GPL.
If there's no outrage against it, it *will* get passed. These are the kind of laws that lazy law enforcement types love. They bring them again and again until they slip through somehow.
The US has been passing stupid laws left and right in the wake of "9-11". Australia doesn't have to be so stupid. Be upset or it will happen.
Your first four examples all boil down to "You don't own the copyright" (or, you've given the copyright away irrevocably for number 4). That's true for any license since you can't license what you don't own.
Where in the GPL does it say anything about not being able to GPL part of a proprietary program? Of course you can. It may not be useful but you can do it. There is no GPL authority to determine what you can and cannot license under the GPL. It is a license that you get to put on your own copyrighted materials.
You're trying to cite hacker lore as legal precedent. Sorry, it don't fly. There's nothing in the license or in copyright law that requires you to license usable software or even a complete work. If there were, Microsoft would have been run out of business long ago.
There's a big difference between being the owner and licensing the code and being a user of the code and being bound by the license. The owner has very few restrictions, other than, as you pointed out, actually being the owner.
Soyuz is still flying! How do you think those tourist guys get to the space station? Hint - NASA doesn't sell things.
A quick look at Wikipedia shows there have been 98 manned Soyuz missions to date and 121 Shuttle missions. Additionally, you could include the Progress missions which have been used to supply both Mir and the ISS - Progress is an unmanned spacecraft based on the Soyuz design. There have been 114 Progress flights.
Bzzt - wrong. GPL is a one way street, not a two way street. There are no negative requirements in the GPL. *Anything* can be placed under the GPL.
Where GPL requirements come into play is that the GPL sometimes requires code to be placed under the GPL. Code that is derived from GPL licensed code *must* be placed under the GPL. Derived code has been held to be both code that is a modification of a piece of code *and* code that is linked to and depended on, like a library. It's a one way street, though. If you make something like ndiswrapper it can be released under the GPL. The fact the ndiswrapper provides functions to proprietary code doesn't have any bearing on its GPL status. And, the fact that proprietary code is now linked to ndiswrapper doesn't force the proprietary code to become GPL'd - it doesn't depend on ndiswrapper and it wasn't linked with ndiswrapper by its creator and distributor.
This is a good explanation. I think the problem is the the GPLONLY variable is misnamed. It should be called something like "SOURCEAVAILABLE".
As a result of the misnaming the argument moved into whether or not ndiswrapper is GPL'd and, it is. The GPL is a license that applies to copyright issues. Those issues are copying (distribution) and creation of derivative works. ndiswrapper complies with the GPL and is licensed under the GPL and is freely distributed. Just because ndiswrapper is primarily used with non-GPL code does not make it non-GPL. There's nothing in the GPL that says that GPL code cannot work with non-GPL code. It says that if you make derivative works of GPL code then your code must also be GPL'd. The proprietary drivers are not derivative works of ndiswrapper or the Linux kernel (they're Windows drivers and their authors may never even have seen Linux internals) and really have no bearing on the GPL/non-GPL status of ndiswrapper. ndiswrapper is licensed under the GPL and all of its source code is freely available. It may seem like a legalistic argument, but the GPL *is* a legal instrument.
The argument should have been that ndiswrapper will load modules that make debugging hard or impossible - which is factually true.
Well, long ago, we used to consider the kernel as the OS. It wasn't until MS started their nonsense with how the browser was really part of the OS that people started extending the definition of an OS.
Just consider how much CO2 is locked up in old National Geographics!