Groklaw - Business is Business and Credit Where Credit is Due

	When you want to know more...

Home
Archives
Site Map
Search
About Groklaw
Awards
Legal Research
Timelines

ApplevSamsung
ApplevSamsung p.2
ArchiveExplorer
Autozone
Bilski
Cases
Cast: Lawyers
Comes v. MS
Contracts/Documents
Courts
DRM
Gordon v MS
GPL
Grokdoc
HTML How To
IPI v RH
IV v. Google
Legal Docs
Lodsys
MS Litigations
MSvB&N
News Picks
Novell v. MS
Novell-MS Deal
ODF/OOXML
OOXML Appeals
OraclevGoogle
Patents
ProjectMonterey
Psystar
Quote Database
Red Hat v SCO
Salus Book
SCEA v Hotz
SCO Appeals
SCO Bankruptcy
SCO Financials
SCO Overview
SCO v IBM
SCO v Novell
SCO:Soup2Nuts
SCOsource
Sean Daly
Software Patents
Switch to Linux
Transcripts
Unix Books

Gear

Groklaw Gear

You won't find me on Facebook

Donate

No Legal Advice

The information on Groklaw is not intended to constitute legal advice. While Mark is a lawyer and he has asked other lawyers and law students to contribute articles, all of these articles are offered to help educate, not to provide specific legal advice. They are not your lawyers.

Here's Groklaw's comments policy.

What's New

STORIES
No new stories

COMMENTS last 48 hrs
No new comments

Sponsors

Hosting:

On servers donated to ibiblio by AMD.

Webmaster

Business is Business and Credit Where Credit is Due

Monday, March 15 2004 @ 08:36 PM EST

There is an article in CIO magazine on GNU/Linux use in business. It's called "The Myths of Open Source," and one by one it debunks them, by interviewing executives who have made the switch already and are happy with GNU/Linux for their business use.

The myths thoroughly debunked are:

MYTH 1 - THE ATTRACTION IS THE PRICE TAG ( It's performance improvement.)
MYTH 2 - THE SAVINGS AREN'T REAL (". . .there's a zero marginal cost of scale because open source doesn't require additional licenses as an installation grows.")
MYTH 3 - THERE'S NO SUPPORT ( ". . .existing users of open-source software appear perfectly happy with open-source support arrangements.")
MYTH 4 - IT'S A LEGAL MINEFIELD (If you're worried, third-party indemnification is an option.)
MYTH 5 - OPEN SOURCE ISN'T FOR MISSION-CRITICAL APPLICATIONS ( Are banks mission-critical enough for you?)
MYTH 6 - OPEN SOURCE ISN'T READY FOR THE DESKTOP ("Siemens, for example, says it has performed extensive testing with 'real-world, nontechnical workers,' finally declaring that Linux has now matured as a desktop system. The tests confounded the company's expectations.")

The bottom line, the article says, is summed up by Andy Mulholland, chief technology officer for Cap Gemini Ernst & Young:

"'The lesson of the Web is that standardization is better than differentiation,' Mulholland claims. 'Is there a virtue in doing things differently? Is there a virtue in doing things the same way as everybody else?' As the past decade has shown, standardization with a proprietary flavor—think Microsoft—has its drawbacks: bloatware, security loopholes, eye-popping license fees and an unsettling reliance upon a single vendor. In offices around the globe, an era of open-source standardization, determined to condemn such drawbacks to history, may be dawning."

Of course, the legal angle is the part I am most interested in, and the article quotes some attorneys who mock SCO's GPL-is-unconstitutional claim, calling it "silly" and "bizarre". I'm pointing it out for you journalists, just so you know there are independent attorneys watching SCO's claims and finding them silly and bizarre. Now that SCO is pushing their "independent" attorneys, I thought you'd like some legal resources to contact.

InternetWeek adds this:

"But to business and IT managers, open source isn't about code we don't have to pay for. In this case, free means freedom, as in the freedom to choose and use software as we wish, with no proprietary barriers.
"Look at it this way: We've been on a product-upgrade treadmill for the past decade, and we've learned that the lack of choice about when to stop upgrading some products can be costly. If one company controls the source code and doesn't let others patch and update as they see fit, we consumers are forced to upgrade--no freedom there. Open source, on the other hand, lets financial managers control the timing of their cash outflows. Given the financial principle of the 'time value' of money (the same amount of money is worth more now than it is later), the freedom to upgrade when and if we want can contribute to successful financial management. Sounds like capitalism to me."

ComputerWorld has an article, "Big Business Opens Up to Linux", and someone suggests that you factor in “the lack of viruses when calculating TCO.”

A Positive Word About SCO

Since Mr. McBride, in his interview with Dan Farber, complained that Groklaw never says anything positive about SCO, I wish to turn over a new leaf. Here is something I can honestly thank SCO for, all their contributions to the Linux community.

For example, on this page, on their website, they list what they call "SCO Community Contributions", including to the Linux kernel and to RPM. Here's what they say about RPM:

"RPM 1.0 was developed with SCO funds. Working with Red Hat, we developed the first package manager."

The RPM page adds:

"RPM 1.0 was developed with SCO funds. As business partners with Red Hat back then, we used their Linux system as the base for our SCO Network Desktop product. We needed a more robust package management system than the RPP system they were using at the time. Therefore, SCO helped fund the development of RPM."

Here is what they say about their contributions to the kernel:

"SCO has contributed several Linux kernel enhancements, including Windows support, IPX support, NFS, and more."

Indeed, as Groklaw has chronicled already, they are being modest, and there is "more". This page provides the same list they had back in November of 2002, so maybe they don't realize they still have this page on their website. They might want to rewrite this part:

"Knowing the importance of the development community, SCO continues to contribute to the open-source and development community. Here are some of the contributions we have made and are making to the community."

All their kernel contributions they list are on the Linux Kernel page and they include:

Minor modifications to enhance support for Windows environments like Sun's Wabi and WINE (Ron Holt)

Initial release of the Sangoma frame relay driver (Jim Freeman)

Extensive work on the kernel's IPX support (Greg Page, Jim Freeman)

SPX support (Jim Freeman)

Certain mutations of the kernel's NFS support (Olaf Kirch)

Initial release of the TLAN network card driver (James Banks)

Dynamic PPP channel work (Jim Freeman)

Early support of the SMP development effort (hardware provided to the SMP development team)

General occasional kernel hacking and patching (Torsten Duwe)

Help with the original IBM Token Ring driver (Greg Page)

They also, they say, contributed to the Uniform Driver Interface Project, which they describe like this:

"The UDI Project intends to allow a single device driver to support an I/O card across the platforms and operating systems appropriate for its interconnect."

The UDI page on SCO's site adds:

"SCO International, Inc. (SCO) is advancing the state of the art in device driver technology. As an active member of Project UDI, the industry group that designed UDI (the Uniform Driver Interface), SCO has worked jointly with a number of system vendors and IHVs, including Adaptec, Compaq, Hewlett-Packard, IBM, Intel, Interphase, Lockheed Martin, SBS Technologies, STG, Sun Microsystems and Unisys, to define and promote a cross-vendor, cross-platform device driver interface.
You can download the UDI Feature Supplement and Development Kit for UnixWare 7.1.1 from the SCO Download Site Select "UnixWare 7 Release 7.1.1 UDI Feature Supplement" as the product name. This product is based on the final review draft of the 1.01 UDI Specifications.
The UDI 1.01 specification set is available from Project UDI .
UDI is a device driver interface that allows one driver to be run on a variety of operating systems. A driver that is coded to the UDI specification can run on any operating system for which UDI support is available; it will no longer need to be rewritten to use each system's specific set of functions and structures. A driver coded to UDI would use UDI interfaces rather than DDI, SDI, MDI or other proprietary OS interfaces. Generally, though, the same functionality, or a superset, is available in UDI.
Implementations of the UDI environment have been demonstrated on UnixWare 7, OpenServer, and UnixWare 2.1, along with operating systems from other vendors. See the Project UDI web site for a complete list.
UDI support will be included in all SCO operating systems, including OpenServer, UnixWare 7, and Monterey-64."

If you click on the link to the UDI project, the specifications page says it is "hosted by Caldera". Here's the page of papers from SCO Forum 1999 on UDI. One of them, "UDI HDK Roadmap" by Matt Kaufman, mentions on page 2 that UDI would be incorporated into Project Monterey, as well as all SCO OSs. What I'm wondering about is, do SCO's ABI files enter into this project? Maybe some of SCO's partners on the UDI project could take a look in their files and see what SCO contributed and under what terms. Here is a list of some of the folks who were given credit for UDI IA-32/IA-64 ABI Binding Specification, Version 1.01:

"The authors would especially like to thank their significant others for putting up with the many hours of overtime put into the development of this specification over long periods. Thanks to the following folks who contributed significant amounts of time, ideas, or authoring in support of the development of this specification or in working on the prototype implementations which helped us validate the specification:

Allyn Bowers (Intel)
Steve Bytnar (System Technologies Group)
Mark Evenson (HP)
Kurt Gollhardt (SCO)
Matt Kaufmann (SCO)
Robert Lipe (SCO)
Scott Popp (SCO)
Kevin Quick (Interphase)
John Ronciak (Intel)
Rob Tarte (Pacific CodeWorks)
Linda Wang (Sun)
Finally, thanks to David Roberts (Certek Software Designs) for designing the Project UDI logo.

As it happens, UDI was not universally popular with the Linux folks. Here's an email from back when, describing the unease some felt:

From - Sat Jun 17 06:06:47 2000
Message-ID:
Date: Sat, 17 Jun 2000 01:54:14 -0600
From: Warren Young
Organization: -ENOENT
X-Mailer: Mozilla 4.72 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
Newsgroups: comp.unix.sco.misc
Subject: Re: SCO Linux???
References:
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Original-NNTP-Posting-Host: 56k111-118.cyberport.com
Lines: 67
NNTP-Posting-Host: 199.45.228.130
X-Trace: 17 Jun 2000 01:59:09 -0600, 199.45.228.130
Path: news.randori.com!news.voicenet.com!newshub.northeast.verio.net!verio!cpk-news-
hub1.bbnplanet.com!denver-news-
feed1.bbnplanet.com!news.gtei.net!coop.net!news.coop.net!news.gj.net!56k111-118.cyberport.com
Xref: news.randori.com comp.unix.sco.misc:61905
X-Mozilla-Status: 8010
X-Mozilla-Status2: 00000000

fred smith wrote:

> > Robert Lipe wrote:
> : Warren Young writes:
>
> :>I guess it's a given that [SCO will] integrate the UDI patches that the
> :>core Linux kernel development team refuses to use.
>
> Pardon my ignorance, what is UDI, and what would its presence do for/to
> Linux?

It's a standardize device driver interface. The idea is for all Unixes to support it, allowing a device driver to be ported to new versions of Unix with just a recompile.

(See http://www.projectudi.org/ for more details.)

The current sentiment among the Linux kernel people is that they don't want UDI in the kernel. I've heard several reasons for this:

1. UDI -- being an extra layer of indirection -- slows the device driver down with respect to a "native" device driver.

2. The Linux kernel people would rather see native drivers than UDI drivers for particular hardware. If UDI remains an add-on that Linux distributors have to add themselves, there will be more pressure on hardware vendors to avoid UDI, at least for Linux.

3. Since UDI is a standardized interface, it should also be an ABI, at least for a particular platform. (UDI doesn't promise a cross-platform ABI.) An ABI means that a device driver could work with multiple versions of the Linux kernel without needing to be recompiled.

If Linux had a driver ABI, hardware vendors would start shipping binary-only drivers: there are few binary-only Linux drivers right now because of the threat of interface changes. Obviously, binary-only drivers go totally against the grain of Open Source.

4. There's concern that UDI would create a drag on kernel innovation: that UDI would either make some kernel changes impossible because of the way it thinks device drivers should work, or that the UDI component might not be able to benefit from improvements made to the native driver interface. The latter would make Linux look bad if UDI became the de facto Linux driver interface, because the improvements would not show up on systems using UDI drivers. The Linux kernel folk would then have to petition the UDI standards body to make a change: Open Source and bureaucracies do not mix.

5. Accepting UDI into the kernel would require the kernel folk to find someone to keep the Linux UDI component in synch with the rest of the kernel. Since UDI is already unpopular for the above reasons, there's skepticism as to whether someone can be found that's willing to synch UDI up every time the native driver interface changes.

6. ABIs are good in one sense, but they also stifle innovation. Just look at UnixWare: their DDI is at version 8 right now, implying that they've changed the interface 7 times since they created DDI. Linux changes its device interface as often as every point release. Is Linux out of control and chaotic, or is it continually being refined? It depends on your point of view, but the fact is, the Linux kernel folk refuse to give up this ability to change the device driver interface at will.

Warren -- See the *ix pages at http://www.cyberport.com/~tangent/ix/

Of course, a lot of the links are dead now on UDI info, which is part of what is making me so interested. Anyway, thanks, SCO, for all your contributions to Linux, and especially to the Linux kernel. We're sure it's your modesty that has you list only part of your contributions.

P.S. Don't forget to let Congress know about your wonderful contributions to the kernel and the community back when you thought you could make money from GNU/Linux and were a Linux company and didn't have Microsoft whispering in your ear, so Congress can gauge your sincerity about claiming now that Linux is a "security threat."

Business is Business and Credit Where Credit is Due | 370 comments | Create New Account

Comments belong to whoever posts them. Please notify us of inappropriate comments.

URLs and News Updates Here Please

Authored by: nealywilly on Tuesday, March 16 2004 @ 03:26 AM EST

Please post supporting (or refuting, I guess) URLs and News Updates here.