EOF - Linux vs. SCO—A Foregone Conclusion
When a disruptive technology appears in an existing marketplace, established players initially take pains, ostrich-like, to ignore it. Disruptive technologies usually start out as underpowered or as answers in search of a question, making it easy to belittle and discount the interloper. However, once a disruptive technology gains traction and starts making in-roads to established territory, the powers-that-be wake to the fact with one of two responses—they either embrace the disrupter or attempt to crush it.
Linux is a disruptive technology par excellence. Linux began its life as a hobbyist novelty and a graduate school project. Even after it made its way into the world over the Internet, it lagged behind UNIX systems in terms of capabilities, documentation, support and the ability to leverage the hardware platforms on which it ran. What made (and still makes) Linux disruptive is that it works. The open-source development model, incremental but steady as the proverbial tortoise, relentlessly advanced the GNU/Linux operating system and tools to reach and then surpass the startled proprietary hare. The cooperative spirit of the Open Source community and the assurances provided by licenses such as the GPL, LGPL, BSD copyright, NPL/MPL and others help prevent the fragmentation endemic in proprietary UNIX and provide the legal basis for the open-source process.
The divide between the powers that embrace Linux and those that would crush it is wide and deep. Long-standing leaders, such as IBM, HP and Oracle, had the vision to build new businesses with and on the Linux platform, despite or because of their investment in proprietary software, including proprietary UNIX. Foremost in the opposite camp is of course Microsoft, longtime foe of UNIX and natural-born enemy of Linux, for both its open pedigree and the open-source model.
Poor misguided SCO meanders somewhere in the chasm between the two extremes. The SCO Group, reborn from Linux distributor Caldera and reminted with the SCO name, now feels rejected as its base of UNIX licensees migrate to Linux. With its claims against IBM and attempt to extort monies from Linux users, SCO is trying to turn Caldera's earlier enthusiastic embrace into a crushing clinch.
Outpaced technology companies have a long and sorry tradition of seeking in court what they cannot achieve in the open marketplace. Legal remedy in lieu of a successful business strategy always invokes the doctrine of unintended consequences. SCO's attempts to recover lost business from IBM AIX royalties will lead IBM and other licensees only to curtail their already declining proprietary UNIX shipments. Attempting to extract license fees from enterprise Linux users and embedded Linux deployers may delay Linux deployment in the short term, thereby stalling SCO's attempt to generate license revenues.
Self-deception is a typical response to disruptive technology. SCO's stated Linux Licensing Fees of $699 US for enterprise use and $32 US for embedded deployment represent a fantasy worldview that is out of line with the pricing and practices of both markets. On the enterprise side, this tidy sum is twice what Microsoft demands for its Windows products in comparable applications. For embedded systems, the SCO invoice outstrips typical low-volume royalties by a factor of at least three and is several orders of magnitude more for high-volume shipments in consumer electronics applications. For enterprise, the SCO fee quickly would exhaust available IT budgets; for embedded, it would overwhelm already slim margins on devices with bills of materials in the key $50–$200 US range.
None of these legal machinations would enhance the position of SCO UNIX one bit, nor would they garner Darl McBride any new Linux-based revenues. In SCO's imagined universe, where it prevails in the IBM suit or in its Linux licensing campaign, SCO still loses—does SCO imagine that it could capture, wound or even kill Linux as a commercial platform? It ain't gonna happen. A stuffed penguin in McBride's den would not lay any more golden eggs. Angry enterprise and embedded Linux users would not turn around and license SCO UNIX—it offers no technological advantage over Linux, even in high-end systems, and is completely inappropriate for embedded applications. Serious developers and users would wish a plague upon both SCO UNIX and SCO-licensed Linux. Diehards would stick with Linux and help to create a version scrubbed of any SCO detritus. Lesser souls might migrate to BSD or even end up in the clutches of Microsoft. None of these scenarios helps SCO, whose licensing-based revenue fantasy then reveals itself as a nightmare, first and foremost for SCO itself.
McBride and company need to realize that in the long term, SCO's claims would ensure that all SCO code, whether (temporarily) in Linux or in SCO UNIX, becomes untouchable and unmarketable, in any form.
So, McBride, Boies, et al. —go ahead, continue gunning for Linux and open source. Ready. Aim. Shoot yourself in the foot. Then, please hobble out of the way. Some of us are trying to do business.
James Ready is president and CEO of MontaVista Software, Inc., and has more than 25 years of technical and entrepreneurial experience. Cofounder of Ready Systems, he pioneered the development of the first commercially viable, real-time operating system (RTOS) product—the VRTX real-time kernel.
Realizing the promise of Apache® Hadoop® requires the effective deployment of compute, memory, storage and networking to achieve optimal results. With its flexibility and multitude of options, it is easy to over or under provision the server infrastructure, resulting in poor performance and high TCO. Join us for an in depth, technical discussion with industry experts from leading Hadoop and server companies who will provide insights into the key considerations for designing and deploying an optimal Hadoop cluster.
Sponsored by AMD
Built-in forensics, incident response, and security with Red Hat Enterprise Linux 6
Every security policy provides guidance and requirements for ensuring adequate protection of information and data, as well as high-level technical and administrative security requirements for a system in a given environment. Traditionally, providing security for a system focuses on the confidentiality of the information on it. However, protecting the data integrity and system and data availability is just as important. For example, when processing United States intelligence information, there are three attributes that require protection: confidentiality, integrity, and availability.
Learn more about catching the bad guy in this free white paper.
Sponsored by DLT Solutions
| Designing Electronics with Linux | May 22, 2013 |
| Dynamic DNS—an Object Lesson in Problem Solving | May 21, 2013 |
| Using Salt Stack and Vagrant for Drupal Development | May 20, 2013 |
| Making Linux and Android Get Along (It's Not as Hard as It Sounds) | May 16, 2013 |
| Drupal Is a Framework: Why Everyone Needs to Understand This | May 15, 2013 |
| Home, My Backup Data Center | May 13, 2013 |
- New Products
- Linux Systems Administrator
- Senior Perl Developer
- Technical Support Rep
- UX Designer
- Web & UI Developer (JavaScript & j Query)
- Designing Electronics with Linux
- Dynamic DNS—an Object Lesson in Problem Solving
- Making Linux and Android Get Along (It's Not as Hard as It Sounds)
- Using Salt Stack and Vagrant for Drupal Development
- Reply to comment | Linux Journal
3 hours 37 min ago - Nice article, thanks for the
14 hours 17 min ago - I once had a better way I
20 hours 3 min ago - Not only you I too assumed
20 hours 20 min ago - another very interesting
22 hours 13 min ago - Reply to comment | Linux Journal
1 day 7 min ago - Reply to comment | Linux Journal
1 day 7 hours ago - Reply to comment | Linux Journal
1 day 7 hours ago - Favorite (and easily brute-forced) pw's
1 day 9 hours ago - Have you tried Boxen? It's a
1 day 15 hours ago
Enter to Win an Adafruit Pi Cobbler Breakout Kit for Raspberry Pi

It's Raspberry Pi month at Linux Journal. Each week in May, Adafruit will be giving away a Pi-related prize to a lucky, randomly drawn LJ reader. Winners will be announced weekly.
Fill out the fields below to enter to win this week's prize-- a Pi Cobbler Breakout Kit for Raspberry Pi.
Congratulations to our winners so far:
- 5-8-13, Pi Starter Pack: Jack Davis
- 5-15-13, Pi Model B 512MB RAM: Patrick Dunn
- 5-21-13, Prototyping Pi Plate Kit: Philip Kirby
- Next winner announced on 5-27-13!
Featured Jobs
| Linux Systems Administrator | Houston and Austin, Texas | Host Gator |
| Senior Perl Developer | Austin, Texas | Host Gator |
| Technical Support Rep | Houston and Austin, Texas | Host Gator |
| UX Designer | Austin, Texas | Host Gator |
| Web & UI Developer (JavaScript & j Query) | Austin, Texas | Host Gator |
Free Webinar: Hadoop
How to Build an Optimal Hadoop Cluster to Store and Maintain Unlimited Amounts of Data Using Microservers
Realizing the promise of Apache® Hadoop® requires the effective deployment of compute, memory, storage and networking to achieve optimal results. With its flexibility and multitude of options, it is easy to over or under provision the server infrastructure, resulting in poor performance and high TCO. Join us for an in depth, technical discussion with industry experts from leading Hadoop and server companies who will provide insights into the key considerations for designing and deploying an optimal Hadoop cluster.
Some of key questions to be discussed are:
- What is the “typical” Hadoop cluster and what should be installed on the different machine types?
- Why should you consider the typical workload patterns when making your hardware decisions?
- Are all microservers created equal for Hadoop deployments?
- How do I plan for expansion if I require more compute, memory, storage or networking?




Comments
Re: Linux vs. SCO--A Foregone Conclusion
SCO is already dead. Even if in the 1/10000000000 chance they should win against IBM. The very most it would do is slow down Linux while code is rewritten. Besides who would buy there Software anyway? I would run Windows Servers before using SCO Unix... yuk.. And from what I has seen so far. I over estamated the chances of them winning to begin with. Not one legal eagle, not being paid by SCO, is saying they have any chance.
Time to ignore SCO and leave them to there fate. IBM will finish them and if not IBM. Novell, RedHat, AutoZone and others are standing in line to slap them around in court.
It is a shame after all the work from all the people that worked on UNIX for decades. It's legacy is going to be that of SCO. Remembered by failed court battles instead of the grand father of whatever Linux will become. Unix was once a great OS and now The SCO Group has turned it into crap. I just hope our court system here in the USA can put an end to this before too long.
Slime Bags The SCO Group and my old friend UNIX should Rest in Peace!
Re: Linux vs. SCO--A Foregone Conclusion
Do it go and kill them
Cees
Re: Linux vs. SCO--A Foregone Conclusion
Good ment advice, at least that is what they told me in the army. It worked as well. Shoot, aim, shoot.
Re: Linux vs. SCO--A Foregone Conclusion
I hope you did not shoot in your own foot?????????????
Re: Linux vs. SCO--A Foregone Conclusion
Agreed! SCO hurry and shoot youself and get the heck out of the way. We got systems to setup.
Re: Linux vs. SCO--A Foregone Conclusion
Go and kill them
Cees