Ah, yes, legal authorities on the subject. Ever think that maybe this guy has "delved" way deeper into this subject than reading a bunch of geeks bitching and moaning on tech sites?
Ha ha ha ha ha! My friend, attorneys are not automatically thorough, or even correct, just because they went to law school. I have frequently had to correct lawyers who made mistakes while working for me in a corporate capacity. Once I fired a lawyer doing some personal work for me when her explanations of the law (in her specialty area) were completely at odds with what I, a layman, had read. After giving up arguing with her, I completed the legal process myself, and guess who turned out to be right?
So no, given the ridiculously oversimplified analysis and the fact that this so-called attorney chose to brag about it here, I did not think this guy has "delved" deeper into the subject at all.
And by the way, this will probably surprise you, but calling me "fucko" doesn't actually make you sound less stupid.
P.S. sorry, everybody, for responding to two trolls in a row. I'm bored today. Mod this down so nobody else has to read it!
Now, I'm not a tech guy, but try to look at it from our perspective - they presented us with a list of infringing filenames, and lo and behold, those files are identical.
You are an attorney, though, right? Aren't you supposed to spend a little time researching the issues? I have no idea what your company's linux deployment looks like, but I'd hate to hear you are costing your company a bundle of money due to laziness.
Previous coverage on slashdot, groklaw, and many other web sites have delved way deeper into this than you. In fact, I am somewhat suspicious you are actually a troll, since I can't believe a Fortune 500's legal department can't crank out a more sophisticated analysis than "the files sure look identical". Even us non-legally-trained bozos know that a show of identical looking files is light years away from a case that SCO owns any copyright whatsoever that is being infringed in any way by Linux users. And, in fact, all the facts most of us have seen point the other direction.
When SCO is gone and your IT department points out to your bosses the ungodly amount of time and money you cost the company due to jumping the gun (especially when your competitors didn't take the same silly steps), I'm sure part of those costs will be recouped from the legal department's payroll!
Ok, let's get this straight. The BBC news division is reporting that Tom Baker made this claim, which has been denied, in turn, by somebody back at the BBC entertainment division.
So I think this can still be filed under "rumors", same as 4 days ago when this appeared on the bbc.co.uk website. Way to stay on top of late-breaking news,/.
Much more than their capturing of all port 80 traffic, I am irritated by what has happened to email.
Every time I send a message with a typo in the domain name, my message goes straight to Verisign's email servers. Though they are kind enough to send a bounce back to me, in the meantime they have the ability to
Read my entire message
Stick my name and email address into their database for marketing and resale
I don't think they care one bit about the $2000. In fact, I bet the RIAA would PAID for the result they got: major news coverage and a bunch of parents starting to think "maybe we should tell our kids it's not OK to steal just because it's convenient".
I think they're looking for a change in the public mentality, and a bunch of precedent showing that they are capable and willing to enfore their intellectual property rights.
Personally I have a feeling that once this is well-established, we might see the record companies think about moving to the much more sensible electronic distribution models we all want to see.
You have some fair questions that deserve a response. I am more than willing to pay a fair fee, even for some things my team is capable of doing, if Red Hat can do it more efficiently and eliminate pain-in-the-rear maintenance. In fact, that's exactly what we were doing before. Red Hat has a wonderful service called "Red Hat Network", for which you receive notifications & priority downloads for patches. At $60/year per machine I had it deployed on every server and thought it was quite a fair deal. I would probably pay double for this service if I had to.
In fact, if you think about it, over a few years this is probably not a lot less money than one would fork over to Microsoft for a license. (ok, it's less, but not orders of magnitude less). And sorry, but Red Hat's R&D costs are a fraction of what Microsoft's were. I think they probably have the potential for quite a nice profit margin on these $60 subscriptions. I don't think any tears need to be shed for Red Hat.
The difference between $60 Red Hat Network and the $800 entperprise subscription is supposedly for two things, neither of which benefit me. One is kernel enhancements. The async I/O has no benefit for me; we neither needed a speed pickup nor did we even notice one when we switched. The second benefit is 4-hour response time technical support. I much prefer to use my highly skilled staff, who are 2-minute repsonse time and always know more than the folks at Red Hat who pick up the phone.
So I am not claiming Red Hat deserves nothing. I am claiming their RHN service is just fine for folks like me who want software updates. I even think the extra $740 is a good deal for the support agreement they offer. If my team all quit, I would probably call Red Hat when we had technical problems. But in the meantime, we don't need it. It's just because of the $!@!@ RDBMS vendor that we had to upgrade.
There are circumstances in which you can be perfectly happy with the free version of Red Hat, but you you are forced for other reasons to purchase a commercial support contract. It happened to me. Imagine a shop where with more than enough in-house expertise to support the free version of Red Hat and deal with its frequent release cycle, and had the full buy-in of management on this arrangement.
The catch; using a commercial piece of software in the mix. In our case, a certain database. Being closed-source and totally non-self-servicable in case of serious problems or bugs, it is imperative to have a support contract for the commercial software. Almost all the RDBMS vendors have now altered/clarified their support policy: they will *not* honor a paid support agreement if you are running the free version of Red Hat underneath their software.
Why this policy exists is a question I will let somebody else speculate about...
There is exactly one major RDBMS vendor I could find that will officially support its software running on the free version of Red Hat (as of April 2003, at least), and that vendor is IBM with their DB/2 product.
Unfortunately, we were too time-constrained to port our system to DB/2, so in the end we caved and paid for Red Hat Enterprise so we could get RDBMS support on our existing platform. To this day we have not called Red Hat tech support once and don't expect to do so, ever. The thousands of dollars we paid covered the 3 minutes of effort the sales guy put in over the phone. Not a bad deal for Red Hat. If I were starting from scratch, knowing about the new support policies from the RDBMS vendors, I would have done the project using DB/2.
PostgreSQL would have been an even better choice, except our project required real-time database replication, and PostgreSQL is just now getting to the point where that works well enough.
Slashdot Mirror
So no, given the ridiculously oversimplified analysis and the fact that this so-called attorney chose to brag about it here, I did not think this guy has "delved" deeper into the subject at all.
And by the way, this will probably surprise you, but calling me "fucko" doesn't actually make you sound less stupid.
P.S. sorry, everybody, for responding to two trolls in a row. I'm bored today. Mod this down so nobody else has to read it!
Previous coverage on slashdot, groklaw, and many other web sites have delved way deeper into this than you. In fact, I am somewhat suspicious you are actually a troll, since I can't believe a Fortune 500's legal department can't crank out a more sophisticated analysis than "the files sure look identical". Even us non-legally-trained bozos know that a show of identical looking files is light years away from a case that SCO owns any copyright whatsoever that is being infringed in any way by Linux users. And, in fact, all the facts most of us have seen point the other direction.
When SCO is gone and your IT department points out to your bosses the ungodly amount of time and money you cost the company due to jumping the gun (especially when your competitors didn't take the same silly steps), I'm sure part of those costs will be recouped from the legal department's payroll!
So I think this can still be filed under "rumors", same as 4 days ago when this appeared on the bbc.co.uk website. Way to stay on top of late-breaking news, /.
Every time I send a message with a typo in the domain name, my message goes straight to Verisign's email servers. Though they are kind enough to send a bounce back to me, in the meantime they have the ability to
Shouldn't this be the main concern?
I think they're looking for a change in the public mentality, and a bunch of precedent showing that they are capable and willing to enfore their intellectual property rights. Personally I have a feeling that once this is well-established, we might see the record companies think about moving to the much more sensible electronic distribution models we all want to see.
In fact, if you think about it, over a few years this is probably not a lot less money than one would fork over to Microsoft for a license. (ok, it's less, but not orders of magnitude less). And sorry, but Red Hat's R&D costs are a fraction of what Microsoft's were. I think they probably have the potential for quite a nice profit margin on these $60 subscriptions. I don't think any tears need to be shed for Red Hat.
The difference between $60 Red Hat Network and the $800 entperprise subscription is supposedly for two things, neither of which benefit me. One is kernel enhancements. The async I/O has no benefit for me; we neither needed a speed pickup nor did we even notice one when we switched. The second benefit is 4-hour response time technical support. I much prefer to use my highly skilled staff, who are 2-minute repsonse time and always know more than the folks at Red Hat who pick up the phone.
So I am not claiming Red Hat deserves nothing. I am claiming their RHN service is just fine for folks like me who want software updates. I even think the extra $740 is a good deal for the support agreement they offer. If my team all quit, I would probably call Red Hat when we had technical problems. But in the meantime, we don't need it. It's just because of the $!@!@ RDBMS vendor that we had to upgrade.
The catch; using a commercial piece of software in the mix. In our case, a certain database. Being closed-source and totally non-self-servicable in case of serious problems or bugs, it is imperative to have a support contract for the commercial software. Almost all the RDBMS vendors have now altered/clarified their support policy: they will *not* honor a paid support agreement if you are running the free version of Red Hat underneath their software.
Why this policy exists is a question I will let somebody else speculate about...
There is exactly one major RDBMS vendor I could find that will officially support its software running on the free version of Red Hat (as of April 2003, at least), and that vendor is IBM with their DB/2 product.
Unfortunately, we were too time-constrained to port our system to DB/2, so in the end we caved and paid for Red Hat Enterprise so we could get RDBMS support on our existing platform. To this day we have not called Red Hat tech support once and don't expect to do so, ever. The thousands of dollars we paid covered the 3 minutes of effort the sales guy put in over the phone. Not a bad deal for Red Hat. If I were starting from scratch, knowing about the new support policies from the RDBMS vendors, I would have done the project using DB/2. PostgreSQL would have been an even better choice, except our project required real-time database replication, and PostgreSQL is just now getting to the point where that works well enough.