After seeing this story, I wondered about the status of Armadillo Aerospace's effort. At their website, I found this news item, posted last month:
The Scaled Composites team deserves huge congratulations for the 100km flight of Space Ship One on Monday. They probably have the X-Prize in the bag now, but just in case, I did go ahead and place orders for all the long lead time items we still need. If their flight had been flawless, I probably wouldn't have bothered. We can still have our final vehicle assembled this year, but it isn't clear that we have time to recover from the inevitable setbacks during testing.
Too bad. I hope they are able to keep going, even if they don't win the X-Prize.
They are very similar from the user's point of view, but in every other way (underlying architecture, overall goals, design philosophy), there are significant differences that make the idea of a merger of the projects rather silly. The freedesktop.org initiative is as close as you are going to get (and as close as you'd want to get, IMO).
This is all besides the point that you can't dictate to volunteer coders what they should work on. What are you going to do, email all of the [KDE|GNOME] devs and say, "It has been decided that having two desktops is unproductive. You are directed to start developing for [GNOME|KDE]. Thank you for your cooperation." ? Think that'll fly?
At the National Air and Space Museum, they have a backup Lunar Excursion Module. I'm always transfixed by it when I visit. It seems so primitive; you can see tape on the foil wrapping, and there are welds and rivets all over it.
I mean look at this image. I've seen RVs with better construction! It really puts the accomplishment in perspective.
Wait, I thought you got the binary as a result of your subscription? Are you sure it's only access to the source code (not the binary) that requires a subscription?
The correct distillation of this situation is as follows: "We will not do X if you distribute this software", where X is "offer you future upgrades of the software". They are not restricting your freedoms, they are imposing a consequence if you exercise your freedom.
They may not further restrict the rights to the source code of those who obtain the program, in any way. Doing so is an infringement of the original authors' copyrights.
Just to clarify, I now understand that Sveasoft is not restricting anyone's rights over the code for the version that they have obtained, they are saying that they will chose to deny you future upgrades of the program, if you choose to exercise your redistribution rights under the GPL. This is *not* a dual-license of the code; the code is licensed under the GPL only. They are just going to weed out redistributors when the next version comes out. This isn't a GPL violation, and I don't even think it's ethically wrong.
However, I don't think it's going to work, because even a tiny number of redistribution events spreads the code infinitely wide, and I don't see how the code distributed to each customer can be uniquely identified in a non-breakable way.
You're right. It was his saying the code is under a "dual license" that threw me, because it isn't. If it were, then Sveasoft wouldn't have a leg to stand on.
However, I now see that the restriction they are placing is on *future* updates, not on the current distribution. So, if you choose to exercise your redistribution rights under the GPL, they will choose to deny you access to future upgrades. This is pretty clever, and I don't think it's a GPL violation. There's nothing in the GPL that guarantees you access to future upgrades.
Still, I don't think it's a realistic business model. A very small fraction of the subscribers will likely republish the source code of every release, making these license gymnastics utterly moot. Also, they must have some system for uniquely identifying each customer's copy of the code, but I would think it will be quite easy to get around this. If it's some kind of hash, just add a random comment somewhere. If it's an embedded ID, just find it and delete it.
HUGE difference: Trolltech *wrote all of the code* they distribute, so they are free to choose a dual-license. Since Sveasoft did *NOT* write all of the code they are distributing, they have ONE choice to distribute derivative code legally: the GPL. They may not further restrict the rights to the source code of those who obtain the program, in any way. Doing so is an infringement of the original authors' copyrights.
You mean, too bad it's completely wrong. Unless Sveasoft is the author of the entire codebase being distributed (they aren't), they are not allowed to distribute the code under any license except the GPL.
Wrong, because you have become a binary distributor. It's very clear in the license: If you distribute a GPL binary, you are responsible for providing the source.
It doesn't matter if you are the author, or you got it from the author, or you got it from someone who got it from the author.
You still see it in the way the suits are being reported by "the mainstream press", who tend to take the side of the biggest corporation, by default.
Uh....SCO vs IBM, SCO vs Daimler/Chrysler, SCO vs Novell. If the mainstream press always sides with the bigger company, then their slant should be decidedly *against* SCO in each of these cases. Hell, even Auto Zone has almost 100 times SCO's market cap.
> Here's an example: Konqueror, KDE's file and web browser, has a menu entry called "smbUmount." I don't need a laboratory with video gear to figure out that this is nearly impossible for non-hacker users to understand.
Exactly. Submit it as a bug. This is the first thing. Many of the people who work on OSS projects realize that there is a usability problem. However, nobody wants to do anything about it.
Well, according to lxr.kde.org, the string "smbUmount" does not exist anywhere in KDE source code. Hmm, imagine that, an OSS dev fixed a usability bug!
Seriously, the OSS project I am most familiar with (KDE) completely contradicts your claims. There are many people in KDE who work very, very hard to solve usability problems, and I would say that almost all KDE devs take usability seriously.
Since the satellite is necessarily in a geostationary orbit, that means it is directly above the equator (longitude=111.1 degrees). So why are they not covering the Southern hemisphere as well? I suppose the reason is that the antennas are directional, and pointed up North.
I was an undergrad at the time; we were watching Jupiter with the Steward Observatory 21-inch telescope. The actual impact events were not visible from Earth, but as Jupiter spun around, we saw the scars left by the impacts. Very exciting stuff!
He's made it very clear that *his* decision will stand despite all the flack he's taken over *his* decision.
O'Keefe himself asked the NAS to form this committee to investigate the future of HST. Granted, perhaps that was just to appease the tidal wave of critics that crashed down on him after he announced his decision, but if we take him at face value, then he is willing to consider options to save HST.
It is more like: 'I want more funding. Screw the rest of you guys.'
Oh, please. Who are "the rest of you guys" supposed to be in this scenario?
FYI, the NAS committee was formed because O'Keefe bowed to intense pressure from scientists, politicians and the general public over his unilateral decision to let HST go. He asked NAS to form this committee and to give him its recommendation.
The risk to Hubble on a manned mission is fairly low. The risk to Hubble by entrusting it to an untested and today uninvented and yet-to-be-engineered robot is very high.
I agree with your general thread (that a manned repair mission is preferable because it has a higher probability of success), but to be fair, the robot is not yet-to-be-engineered. It exists, and it works. It was built by the Canadarm guys. It was meant to go up to ISS for remote work outside thespace station, but the HST guys kind of stole it from Greenbelt and moved it down to Cape Canaveral...
But what about the finacial concerns? I don't think NASA has the funding to allocate to a Hubble Repair mission...
First of all, the instruments which were slated to go up have already been built, so you're looking at a substantial loss of investment if a servicing mission doesn't go.
I heard an estimate of 1 billion USD today for the robotic mission. A manned shuttle mission would likely be comparable in price. However, even if they don't send a repair mission, a robotic mission to HST will still need to be sent, in order to attach rockets which can safely splash it down into the ocean. Otherwise, there's no way to control where it will come down. The cost of this robotic-splashdown mission is half the cost of the full robotic-servicing mission (500 million USD).
It would be a shame to scrap HST because we didn't want to spend an extra $500 million to save it. That's almost exactly the average price of a single space shuttle mission. NASA's annual budget is $15 billion. It's not a lot of money, considering what we're getting for it.
Slashdot Mirror
Too bad. I hope they are able to keep going, even if they don't win the X-Prize.
They are very similar from the user's point of view, but in every other way (underlying architecture, overall goals, design philosophy), there are significant differences that make the idea of a merger of the projects rather silly. The freedesktop.org initiative is as close as you are going to get (and as close as you'd want to get, IMO).
This is all besides the point that you can't dictate to volunteer coders what they should work on. What are you going to do, email all of the [KDE|GNOME] devs and say, "It has been decided that having two desktops is unproductive. You are directed to start developing for [GNOME|KDE]. Thank you for your cooperation." ? Think that'll fly?
Rhymes with "lid". It's from the three parts of the mind in psychology (ego, superego, and id)
(IANAP).
Seriously, has anyone considered the possibility that the only intelligent life-forms in the universe maybe humans in past, present and future form ?
If this was the case, the structure of the universe would have to be periodic on a scale of 20 light years. It isn't.
SCO's ticker symbol is "SCOX", not "SCO"...
At the National Air and Space Museum, they have a backup Lunar Excursion Module. I'm always transfixed by it when I visit. It seems so primitive; you can see tape on the foil wrapping, and there are welds and rivets all over it.
I mean look at this image. I've seen RVs with better construction! It really puts the accomplishment in perspective.
Wait, I thought you got the binary as a result of your subscription? Are you sure it's only access to the source code (not the binary) that requires a subscription?
The correct distillation of this situation is as follows: "We will not do X if you distribute this software", where X is "offer you future upgrades of the software". They are not restricting your freedoms, they are imposing a consequence if you exercise your freedom.
They may not further restrict the rights to the source code of those who obtain the program, in any way. Doing so is an infringement of the original authors' copyrights.
Just to clarify, I now understand that Sveasoft is not restricting anyone's rights over the code for the version that they have obtained, they are saying that they will chose to deny you future upgrades of the program, if you choose to exercise your redistribution rights under the GPL. This is *not* a dual-license of the code; the code is licensed under the GPL only. They are just going to weed out redistributors when the next version comes out. This isn't a GPL violation, and I don't even think it's ethically wrong.
However, I don't think it's going to work, because even a tiny number of redistribution events spreads the code infinitely wide, and I don't see how the code distributed to each customer can be uniquely identified in a non-breakable way.
You're right. It was his saying the code is under a "dual license" that threw me, because it isn't. If it were, then Sveasoft wouldn't have a leg to stand on.
However, I now see that the restriction they are placing is on *future* updates, not on the current distribution. So, if you choose to exercise your redistribution rights under the GPL, they will choose to deny you access to future upgrades. This is pretty clever, and I don't think it's a GPL violation. There's nothing in the GPL that guarantees you access to future upgrades.
Still, I don't think it's a realistic business model. A very small fraction of the subscribers will likely republish the source code of every release, making these license gymnastics utterly moot. Also, they must have some system for uniquely identifying each customer's copy of the code, but I would think it will be quite easy to get around this. If it's some kind of hash, just add a random comment somewhere. If it's an embedded ID, just find it and delete it.
Firstly, Like QT, it is under a dual-licence.
HUGE difference: Trolltech *wrote all of the code* they distribute, so they are free to choose a dual-license. Since Sveasoft did *NOT* write all of the code they are distributing, they have ONE choice to distribute derivative code legally: the GPL. They may not further restrict the rights to the source code of those who obtain the program, in any way. Doing so is an infringement of the original authors' copyrights.
You mean, too bad it's completely wrong. Unless Sveasoft is the author of the entire codebase being distributed (they aren't), they are not allowed to distribute the code under any license except the GPL.
I don't see what's so hard to understand.
Wrong, because you have become a binary distributor. It's very clear in the license: If you distribute a GPL binary, you are responsible for providing the source.
It doesn't matter if you are the author, or you got it from the author, or you got it from someone who got it from the author.
You still see it in the way the suits are being reported by "the mainstream press", who tend to take the side of the biggest corporation, by default.
Uh....SCO vs IBM, SCO vs Daimler/Chrysler, SCO vs Novell. If the mainstream press always sides with the bigger company, then their slant should be decidedly *against* SCO in each of these cases.
Hell, even Auto Zone has almost 100 times SCO's market cap.
It's a poke at Apple's "Redmond, we have a problem" marketing campaign". It's funny, laugh.
Oh well, maybe it should have been "Cupertino, we have a problem".
> Here's an example: Konqueror, KDE's file and web browser, has a menu entry called "smbUmount." I don't need a laboratory with video gear to figure out that this is nearly impossible for non-hacker users to understand.
Exactly. Submit it as a bug. This is the first thing. Many of the people who work on OSS projects realize that there is a usability problem. However, nobody wants to do anything about it.
Well, according to lxr.kde.org, the string "smbUmount" does not exist anywhere in KDE source code. Hmm, imagine that, an OSS dev fixed a usability bug!
Seriously, the OSS project I am most familiar with (KDE) completely contradicts your claims. There are many people in KDE who work very, very hard to solve usability problems, and I would say that almost all KDE devs take usability seriously.
Since the satellite is necessarily in a geostationary orbit, that means it is directly above the equator (longitude=111.1 degrees). So why are they not covering the Southern hemisphere as well? I suppose the reason is that the antennas are directional, and pointed up North.
I was an undergrad at the time; we were watching Jupiter with the Steward Observatory 21-inch telescope. The actual impact events were not visible from Earth, but as Jupiter spun around, we saw the scars left by the impacts. Very exciting stuff!
He's made it very clear that *his* decision will stand despite all the flack he's taken over *his* decision.
O'Keefe himself asked the NAS to form this committee to investigate the future of HST. Granted, perhaps that was just to appease the tidal wave of critics that crashed down on him after he announced his decision, but if we take him at face value, then he is willing to consider options to save HST.
It is more like: 'I want more funding. Screw the rest of you guys.'
Oh, please. Who are "the rest of you guys" supposed to be in this scenario?
FYI, the NAS committee was formed because O'Keefe bowed to intense pressure from scientists, politicians and the general public over his unilateral decision to let HST go. He asked NAS to form this committee and to give him its recommendation.
The risk to Hubble on a manned mission is fairly low. The risk to Hubble by entrusting it to an untested and today uninvented and yet-to-be-engineered robot is very high.
I agree with your general thread (that a manned repair mission is preferable because it has a higher probability of success), but to be fair, the robot is not yet-to-be-engineered. It exists, and it works. It was built by the Canadarm guys. It was meant to go up to ISS for remote work outside thespace station, but the HST guys kind of stole it from Greenbelt and moved it down to Cape Canaveral...
whoops, sorry about missing the typo joke...
ahem. Well, one hundred anyway. In one fell swoop.
But what about the finacial concerns? I don't think NASA has the funding to allocate to a Hubble Repair mission...
First of all, the instruments which were slated to go up have already been built, so you're looking at a substantial loss of investment if a servicing mission doesn't go.
I heard an estimate of 1 billion USD today for the robotic mission. A manned shuttle mission would likely be comparable in price. However, even if they don't send a repair mission, a robotic mission to HST will still need to be sent, in order to attach rockets which can safely splash it down into the ocean. Otherwise, there's no way to control where it will come down. The cost of this robotic-splashdown mission is half the cost of the full robotic-servicing mission (500 million USD).
It would be a shame to scrap HST because we didn't want to spend an extra $500 million to save it. That's almost exactly the average price of a single space shuttle mission. NASA's annual budget is $15 billion. It's not a lot of money, considering what we're getting for it.
...it's odd even.
No, it's not even odd.