As other people have pointed out, RMS seems to have taken the position that GNU is all that matters. While I understand his perspective and somewhat agree, I can't help but think that he is making a mistake by not taking a more pro-Linux stance.
I believe that the SCO case could threaten GNU just as much as it threatens Linux. In the long run, they aren't just after IBM or Red Hat; they want to own the rights to the entire *nix paradigm. In addition, the outcome of this case could affect the entire system of "open" development. Even the FSF would feel the chilling effect on development of having to do IP-violation searches or the such.
In the end, I think RMS is shooting himself in the foot by not closing ranks with the Linux community in this time of need.
Unfortunately, I believe there is one more element to the puzzle that you didn't mention: the licensing contract between SCO and IBM.
SCO has said this case doesn't deal with copyrights (yet), but rather with contracts. That's why they are suing IBM and not Red Hat -- they had a contract with IBM. Unfortunately, we do not yet know the particular details of the contract, which will be the crux of the eventual ruling, but SCO is hinting that the contract explicitly states that all derivative work reverts to SCO in some fashion. If the contract really does grant SCO exclusive control over derivative work, then IBM might be found guilty.
Personally, there are many points of the contract that I would like to see cleared up. This is one, and IBM's insistance that they have an irrevokable and perpetual license is another. Maybe IBM would be so kind as to leak a copy of the contract so that we can see what is really going on...
I found it especially interesting that she says that she saw the early '80s code, yet notes in the next question that SCO claims that the copied code pertains to NUMA, RCU, and SMP. Did SCO even have those features in the early '80s? I don't know for sure, but I somehow doubt it.
I would guess that the 80-line piece of code that she saw was not related to any of the "enterprise" functionality that she mentions. The pieces just aren't fitting together well, and it is confirming to me that SCO is making a mountain out of a molehill (that may not even exist.)
Just to clear up some points that people have raised:
First, ClearChannel isn't terribly affected by the changes, at least as they stand. The radio cap was left at 8, so they aren't going to be buying up a lot of new radio stations because of this ruling. The item that may give them more potential is the ability to buy newspapers that are in the same market as their radio stations, but radio diversity will not be affected by that.
Second, very few people have mentioned the unfortunate fact that something had to be done; the courts were prepared to throw the current cross-media ownership rules away completely on First Amendment grounds. Those who are informed on both sides of the issue acknowledge this fact. You may disagree with the changes that were made today, but please don't argue that the rules should have been left the same or even tightened, as they would have been dumped anyway.
Lastly, I don't believe that the changes are effective until 60 days after they have been published by the FCC, so there is still time to write your Representative/Senator to encourage them to overturn the ruling.
I would say that you should go with HTTP for sure. Of course, you can provide both, but there are some key reasons for using HTTP.
Easier Configuration Perhaps I'm just not that swift, but I've found that web servers (including Apache) are easier to configure. This is especially true if you have any previous web server experience. Of course, the FTP server is more complex due to its additional features that HTTP doesn't have, but assuming that (c) is true, then you won't need to mess with group access control rights and file uploads.
Speed This whole "FTP is faster" stuff is not true. HTTP does not have a lot more overhead than FTP; it may even have less overhead than FTP in certain cases. Even when it does have more overhead, it is in the order of 100-200 bytes, which is too small to care about. HTTP always uses binary transfers and just spits out the whole file on the same connection as the request. FTP needs to build a data connection for every single data transfer, which can slow things down and even occasionally introduce problems.
Easier for Users Given assumption (d), your users will be much more familiar with HTTP URLs than FTP addresses. You could just use FTP URLs and let their web browsers download the files, but then you lose the benefit of resuming partial downloads.
Simple Access Controls Though some people need to have complex user access rules, you may very well just need simple access controls. HTTP provides this (look at Apache's.htaccess file), and you can even integrate Apache's authentication routines into PAM, if you are really hard core.
There are a few main areas where FTP currently holds sway:
Partial Downloads Web browsers typically don't support partial downloads, but the fact of the matter is that the HTTP protocol does support it (see the Range header.) The next generation of web browsers may very well include this feature.
User Controls Addressed above.
File Uploads Again, HTTP does support this feature but most browsers don't support it well. Look to WebDAV in the future to provide better support.
In summary, just use HTTP unless you need complex access rules, resumption of partial download, or file uploading. It will be easier both on you and your users.
The truth is that part of the reason that software seems different is because I am involved in it. If I made medicine in my spare time then I'd probably think those type of patents were bad too.
You would think that, and you would probably have a case for it (logical, not legal.) The barriers to entry into the software market are very low -- all I need is a computer and I can start cranking out new software that includes revolutionary new ideas. On the other hand, the barriers to entry into medicine are very high -- you would probabily need millions, if not billions, of dollars to discover, test, and patent a new medicine. This means that there are naturally fewer new ideas in medicine than in software, hence the need for additional protections on the few that do occur, hence patents. So, if the costs were low enough to where you were able to do medicial research in your spare time, there would probably be less of a need for patent protections as there would most likely be a constant stream of innovation anyway.
I suppose that it doesn't matter, though, since patents have long since lost their original purpose and have become strategic tools for corporations.
Uninformed people complain about software patents because they are "bad." No one ever quantifies "bad" or defines "bad." They simply label patents as "bad." What these people reason from is the flawed premise that because something is easy to copy (i.e. - I can write code to do that) that it is unworthy of protection. They could not be further from the truth.
No, you don't understand the argument. Patents are bad when they betray the very thing that they seek to create -- new ideas. The fact that something is easy to copy has nothing to do with the patent argument.
Have you ever thought about what patents do to a field where there is already rampant innovation? People are coming up with new ideas all the time in the world of software. When things are moving as quickly as they are, patents tend to discourage innovation by threatening developers with the chance of a lawsuit. If I independently come up with a great idea, and then find out that Microsoft has a patent on a distant, yet vaguely similar concept, there is no way in hell that I will further develop on that idea. I would rather try to find something that involves less risk, even if Microsoft's patent doesn't seem to cover my new idea.
This is somewhat tolerable in most other fields, as the idea overlap tends not to happen quite so frequently, but the world of software is a very young field where new ideas happen every minute (of course, it depends on what you call a "new idea," but I'm using the term loosely here, just like the Patent Office does.)
Without IP laws there will be no innovation.
That is very easily disproved. Have you ever noticed that one of the most innovative things to come along in recent years -- the Web -- is not patented? Keep your eyes open; you'll notice a lot of things in society that are innovative, yet not patented.
But I'll keep writing those software patents and suing the theives (yes -- THEIVES) who infringe them anyway.
I feel sorry for the poor guy who comes up with "your" idea on his own. In all reality, he wouldn't have "stolen" the idea from you, but you can sue him into oblivion anyway. Between you and him, I can honestly say that you are the thief, as you are the one who are stealing his money for the crime of thinking up something new. Kind of ironic, isn't it?
Of course, patents do have a place in the world. I just don't believe that software is a placed where they are needed at the moment. You should really look into how software patents are being used by companies now; it reminds me more of the Cold War philosophy of Mutually Assured Destruction (MAD) than of promoting the arts and sciences.
There is no way on Earth that this thing will be used any time soon to encrypt and distribute things over the Internet, assuming that it fundamentally works anyway. The last page of the article talks about how she will need to change every router on the Internet to make it work:
[Glick] fretted that encrypted data could be intercepted on its way to the user. What if pirates tapped into a router?...
[Denning] came up with a way to make routers themselves "locationally intelligent"-in other words, the GPS-based encryption itself would change dynamically as it moved through the path from owner to user.
Obviously she hasn't been keeping tabs on how long it takes new standards (read: IPv6) to be implemented on the Internet.
It would seem that the site is not viewable using Konqueror (2.2.2). It doesn't seem to be Konqeror's fault, it is just that the site does not send a valid HTTP response header (or any header, for that matter), so it freaks out the browser.
Mozilla 0.9.8 is able to compensate for it, so you may want to try it instead.
What the students should have said was "the KDE/GNOME choice confuses everybody".
Well, there is a very easy solution that does not necessitate the death of either KDE or GNOME. If a person wants to have only one option, hell, let's give it to them! RedHat can remove the choice between the two in the default installation and the inexperienced will be none the wiser.
Of course, there are those who would complain ("It's not fair to the other one!"), but they would both be available under the advanced installation.
Slashdot Mirror
I believe that the SCO case could threaten GNU just as much as it threatens Linux. In the long run, they aren't just after IBM or Red Hat; they want to own the rights to the entire *nix paradigm. In addition, the outcome of this case could affect the entire system of "open" development. Even the FSF would feel the chilling effect on development of having to do IP-violation searches or the such.
In the end, I think RMS is shooting himself in the foot by not closing ranks with the Linux community in this time of need.
SCO has said this case doesn't deal with copyrights (yet), but rather with contracts. That's why they are suing IBM and not Red Hat -- they had a contract with IBM. Unfortunately, we do not yet know the particular details of the contract, which will be the crux of the eventual ruling, but SCO is hinting that the contract explicitly states that all derivative work reverts to SCO in some fashion. If the contract really does grant SCO exclusive control over derivative work, then IBM might be found guilty.
Personally, there are many points of the contract that I would like to see cleared up. This is one, and IBM's insistance that they have an irrevokable and perpetual license is another. Maybe IBM would be so kind as to leak a copy of the contract so that we can see what is really going on...
I would guess that the 80-line piece of code that she saw was not related to any of the "enterprise" functionality that she mentions. The pieces just aren't fitting together well, and it is confirming to me that SCO is making a mountain out of a molehill (that may not even exist.)
First, ClearChannel isn't terribly affected by the changes, at least as they stand. The radio cap was left at 8, so they aren't going to be buying up a lot of new radio stations because of this ruling. The item that may give them more potential is the ability to buy newspapers that are in the same market as their radio stations, but radio diversity will not be affected by that.
Second, very few people have mentioned the unfortunate fact that something had to be done; the courts were prepared to throw the current cross-media ownership rules away completely on First Amendment grounds. Those who are informed on both sides of the issue acknowledge this fact. You may disagree with the changes that were made today, but please don't argue that the rules should have been left the same or even tightened, as they would have been dumped anyway.
Lastly, I don't believe that the changes are effective until 60 days after they have been published by the FCC, so there is still time to write your Representative/Senator to encourage them to overturn the ruling.
For a better review of what happened today, see the FCC's website with the commission's opinions.
I also assume the following:
I would say that you should go with HTTP for sure. Of course, you can provide both, but there are some key reasons for using HTTP.
Easier Configuration Perhaps I'm just not that swift, but I've found that web servers (including Apache) are easier to configure. This is especially true if you have any previous web server experience. Of course, the FTP server is more complex due to its additional features that HTTP doesn't have, but assuming that (c) is true, then you won't need to mess with group access control rights and file uploads.
Speed This whole "FTP is faster" stuff is not true. HTTP does not have a lot more overhead than FTP; it may even have less overhead than FTP in certain cases. Even when it does have more overhead, it is in the order of 100-200 bytes, which is too small to care about. HTTP always uses binary transfers and just spits out the whole file on the same connection as the request. FTP needs to build a data connection for every single data transfer, which can slow things down and even occasionally introduce problems.
Easier for Users Given assumption (d), your users will be much more familiar with HTTP URLs than FTP addresses. You could just use FTP URLs and let their web browsers download the files, but then you lose the benefit of resuming partial downloads.
Simple Access Controls Though some people need to have complex user access rules, you may very well just need simple access controls. HTTP provides this (look at Apache's .htaccess file), and you can even integrate Apache's authentication routines into PAM, if you are really hard core.
There are a few main areas where FTP currently holds sway:
Partial Downloads Web browsers typically don't support partial downloads, but the fact of the matter is that the HTTP protocol does support it (see the Range header.) The next generation of web browsers may very well include this feature.
User Controls Addressed above.
File Uploads Again, HTTP does support this feature but most browsers don't support it well. Look to WebDAV in the future to provide better support.
In summary, just use HTTP unless you need complex access rules, resumption of partial download, or file uploading. It will be easier both on you and your users.
You would think that, and you would probably have a case for it (logical, not legal.) The barriers to entry into the software market are very low -- all I need is a computer and I can start cranking out new software that includes revolutionary new ideas. On the other hand, the barriers to entry into medicine are very high -- you would probabily need millions, if not billions, of dollars to discover, test, and patent a new medicine. This means that there are naturally fewer new ideas in medicine than in software, hence the need for additional protections on the few that do occur, hence patents. So, if the costs were low enough to where you were able to do medicial research in your spare time, there would probably be less of a need for patent protections as there would most likely be a constant stream of innovation anyway.
I suppose that it doesn't matter, though, since patents have long since lost their original purpose and have become strategic tools for corporations.
No, you don't understand the argument. Patents are bad when they betray the very thing that they seek to create -- new ideas. The fact that something is easy to copy has nothing to do with the patent argument.
Have you ever thought about what patents do to a field where there is already rampant innovation? People are coming up with new ideas all the time in the world of software. When things are moving as quickly as they are, patents tend to discourage innovation by threatening developers with the chance of a lawsuit. If I independently come up with a great idea, and then find out that Microsoft has a patent on a distant, yet vaguely similar concept, there is no way in hell that I will further develop on that idea. I would rather try to find something that involves less risk, even if Microsoft's patent doesn't seem to cover my new idea.
This is somewhat tolerable in most other fields, as the idea overlap tends not to happen quite so frequently, but the world of software is a very young field where new ideas happen every minute (of course, it depends on what you call a "new idea," but I'm using the term loosely here, just like the Patent Office does.)
Without IP laws there will be no innovation.
That is very easily disproved. Have you ever noticed that one of the most innovative things to come along in recent years -- the Web -- is not patented? Keep your eyes open; you'll notice a lot of things in society that are innovative, yet not patented.
But I'll keep writing those software patents and suing the theives (yes -- THEIVES) who infringe them anyway.
I feel sorry for the poor guy who comes up with "your" idea on his own. In all reality, he wouldn't have "stolen" the idea from you, but you can sue him into oblivion anyway. Between you and him, I can honestly say that you are the thief, as you are the one who are stealing his money for the crime of thinking up something new. Kind of ironic, isn't it?
Of course, patents do have a place in the world. I just don't believe that software is a placed where they are needed at the moment. You should really look into how software patents are being used by companies now; it reminds me more of the Cold War philosophy of Mutually Assured Destruction (MAD) than of promoting the arts and sciences.
Obviously she hasn't been keeping tabs on how long it takes new standards (read: IPv6) to be implemented on the Internet.
To correct my previous post, the site that is broken is www.computerhistory.org.
It would seem that the site is not viewable using Konqueror (2.2.2). It doesn't seem to be Konqeror's fault, it is just that the site does not send a valid HTTP response header (or any header, for that matter), so it freaks out the browser. Mozilla 0.9.8 is able to compensate for it, so you may want to try it instead.
Well, there is a very easy solution that does not necessitate the death of either KDE or GNOME. If a person wants to have only one option, hell, let's give it to them! RedHat can remove the choice between the two in the default installation and the inexperienced will be none the wiser.
Of course, there are those who would complain ("It's not fair to the other one!"), but they would both be available under the advanced installation.
As opposed to the rest of us, who are NOT prohibited from violating any laws, especially copyright laws.