linux unix cincinnati penguin
Dentar, Inc.
About
Philosophy
Contact
Dentists
Services
Specialties
Schedule
New Trends
What's "Dentar?"
Referrals
Policies
Hardware
Partners
Portal

August 13 2007

SCOX loses more.

SCOX stock price plummets. Investors bail out.

August 10 2007

SCO Loses

The judge has ruled that SCO does not own the UNIX copyrights. This is pretty much the end for SCO, which has held on much longer than people thought it would. They held on that long because Microsoft gave them lots of money to finance their lawsuits, via a "license" purchase.

November 01 2005

IBM Subpoenas KPMG

IBM has subpoenaed KPMG, SCO's former accounting firm, in order to try to get documentation on the transaction between Novell and SCO in 1995, when SCO supposedly bought all the copyrights for UnixWare.

October 07 2005

IBM Drops Patent Counterclaims

IBM is dropping their patent counter claims because SCO wants to waste time litigating and IBM has apparently decided that, after doing the math, it's not worth the time or effort to win these counterclaims.

August 09 2005

SCO guilty of violation of which it has accused IBM

The deposition of SCO employee Erik W. Hughes, revealed that the LKP (Linux Kernel Personality) of UnixWare somehow used some code from the Linux kernel. This is infinitely ironic. The very company that is accusing IBM of stealing THEIR code is using GPLd code illegally in their own product! This is the ultimate in hypocrisy, especially from a corporation that decided all on its own that the GPL was "unconstitutional."

July 14 2005

Unsealed SCO Email Reveals Linux Code is Clean

According to an email that was recently unsealed in SCO vs. IBM, an outside consultant hired by SCO in 2002 failed to find copyright violations in the Linux kernel code. This is not a surprise.

July 5 2005

Judge denies SCO's motion to change IBM case again

The judge just denied SCO the motion to change the IBM case again for the third time. Both companies now have a deadline to present all of their evidence. Did I mention I think SCO deserves to lose?

Jan 21 2005

SCO Scores one small victory

SCO just had the judge rule against IBM on one piece; IBM must produce lots of source code to SCO so that SCO can "prove" that they so far have not been able to; that IBM supposedly has maligned them by "stealing" their code and putting it into Linux.I fully expect (and hope) that this will get SCO nowhere but delaying the imminent; a full and embarrassing loss. SCO is no longer a technology company. They are a (purchased) litigation company. SCO deserves to lose big.

Aug 06 2004

It's been a year!

SCO's case has failed to really make much progress, and the industry isn't taking them seriously anymore, and neither are many of SCO's clients (or former clients as the case may be.) One internet provider decided to purchase a "SCOSource" license only to cause anger amongst many of their own clients. Many of their clients dumped them and moved on to more enlightned providers. SCO's suit against Chrysler is all but dead, Autozone has received a stay until IBM's suit is finished, and Red Hat is still suing SCO. SCO's stock value has been hovering below $5.00 for quite a while.SCO forum happened this week, and with it, there is usually a big jump in the stock's value. This time it went up only to go back down again Friday.

Jun 13 2003

SCO Update

Today is the "deadline" for IBM to "comply" with SCO's extortion demand. It is unlikely that IBM will bow down to SCO group. There will likely be a long court battle, which most people predict that SCO will lose in the long run. SCO has already lost the loyalty of many of its dealers. It is unfortunate when a company turns to lawsuits as its main business model. It's unethical, dishonest, and SCO should be ashamed of what they have become. SCO used to have a good thing going, and they threw it away.

Mar 14 2003

The problem with The SCO Group

On or about March 6, 2003, The SCO Group filed a One Billion dollar lawsuit against IBM. According to The SCO Group: "IBM is affirmatively taking steps to destroy all value of Unix by improperly extracting and using the confidential and proprietary information it acquired from Unix and dumping that information into the open-source community." Although The SCO Group maintains that this lawsuit is not a direct attack on open source, they have failed to take into account the consequences this could hold for the entire Open Source community and the millions of people and businesses who have invested time, money, and resources to:

  • Build programs that contribute to the Linux and Open Source community
  • Integrate Linux into their infrastructure, and use it to power their businesses, governments, and schools.
  • Port their programs over to the Linux environment to extend their lives beyond what is capable with legacy UNIX products

The Linux kernel team is very dedicated to writing original works, and is conscious of not including any copyrighted code, as that is the entire point of writing it in the first place.

In these paragraphs of their complaint, The SCO Group asserts that:
  1. Prior to IBM's involvement, Linux was the software equivalent of a bicycle. UNIX was the software equivalent of a luxury car. To make Linux of necessary quality for use by enterprise customers, it must be re-designed so that Linux also becomes the software equivalent of a luxury car. This re-design is not technologically feasible or even possible at the enterprise level without (1) a high degree of design coordination, (2) access to expensive and sophisticated design and testing equipment; (3) access to UNIX code, methods and concepts; (4) UNIX architectural experience; and (5) a very significant financial investment.
  2. For example, Linux is currently capable of coordinating the simultaneous performance of 4 computer processors. UNIX, on the other hand, commonly links 16 processors and can successfully link up to 32 processors for simultaneous operation. This difference in memory management performance is very significant to enterprise customers who need extremely high computing capabilities for complex tasks. The ability to accomplish this task successfully has taken AT&T, Novell and SCO at least 20 years, with access to expensive equipment for design and testing, well-trained UNIX engineers and a wealth of experience in UNIX methods and concepts.
  3. It is not possible for Linux to rapidly reach UNIX performance standards for complete enterprise functionality without the misappropriation of UNIX code, methods or concepts to achieve such performance, and coordination by a larger developer, such as IBM.
Paragraph 84 is incorrect on the following points:
  • Prior to IBM's involvement, Linux was more like a small, nimble sporty car.
  • Prior to IBM's involvement, SCO's version of UNIX was more like an old cadillac, with no new technology.
  • After IBM's involvement, Linux is still like a small, nimble sporty car, and SCO still isn't innovating very much. My personal opinion is that The SCO Group hasn't come out with anything exciting in at least five years.
  • The latest releases of Linux-based distributions are chock full of new, exciting technology.
  • Linux developers had already had a good degree of design coordination. Just because it's not formally called that does not mean that they're not actually designing a kernel in a coordinated fashion.
  • Linux developers had plenty of test equipment to work with, many donated by people other than IBM or The SCO Group.
  • UNIX methods and concepts are all spelled out in POSIX, which SCO does not own.
  • SCO employs a very small fraction of those with "UNIX architectural experience"
  • Very signifcant financial investment? Indeed. With thousands of Kernel programmers donating their spare time, there have already been millions of man-hours poured into the Linux kernel. Time is money
Paragraph 85 disproves their point:
  • Had IBM poured SCO source code and proprietary information into the Linux kernel, it would not still be this far behind the UNIX kernel in terms of scalability.
  • Again, SCO repeats here the "well-trained UNIX engineers" mantra. They do not hire but a mere fraction of those in the world who have this sort of talent.
Paragraph 86 directly contradicts paragraph 85.
  • So, did Linux reach UNIX performance standards or not? If it hasn't reached there yet, then what's the complaint? SCO Group claims in paragraph 84 that IBM has taken Linux to an enterprise level. In paragraph 85, they claim that Linux still hasn't reached enterprise levels as it can only so far scale 4 processors. In paragraph 86, they turn around again and state that Linux HAS reached UNIX performance standards.
  • The SCO Group, in this paragraph is pretty much stating that the Linux kernel programmers don't have the talent to be able to write a kernel without the divine guidance from The SCO Group's or IBM's help.
Given:
  • The SCO Group's most recent hypocrisy and conduct in the UNIX/Linux community (i.e. marketing what they're fighting)
  • Their treatment of the Open Source community since their Caldera days
  • The SCO Group's lack of innovation over the past five years
  • SCO Group's poor support for their reseller channel
  • SCO Group's poor (non existent) support for what used to be their educational channel

Are SCO Products Worth Selling??

I can no longer, with clear conscience, encourage the use of The SCO Group's products. I will, of course, continue to support existing installations, but will not recommend any new ones, and will encourage customers to migrate away from any SCO Group products when it is feasible. Only if it is not feasible (e.g. application is specially coded for just SCO) will I encourage continued use of an S.C.O. product.

It is a shame that is has to come to this, because I put a lot of effort to get certified with their technical certifications for both of their flagship products, and they have rendered themselves mostly irrelevant in the marketplace with their actions.

If you are using any SCO product and are interested in moving away from it, please give us a call. Dentar, Inc. is happy to recommend non-SCO, Linux-based products for almost any function.