Those of you who tracked the SCOforum events know that some of the breakout sessions were led by SCO's Ron Record, both this year and last. Some of the material we keep finding on the Internet that damages SCO's current claims about ELF and binutils has his name on it too because he's done a number of excellent presentations over the years, such as the one we just told you about from SCOforum 2004 which shows binutils being in GNUtools. [Update: The talk slides have moved here.]
Here's his resume. As you can see, he seems to be anticipating needing a new job soon, writing on his resume, "I may soon be seeking employment as an Open Source Solutions Architect". Naturally, one wonders several things at once.
Update: The resume has now been altered and currently reads, "I am not actively seeking alternate employment at this time." My paralegal brain parses that out to mean if something wonderful fell in his lap, who knows? But that's probably just me.
What does he know that makes him write that? Is the company going bust? Or is it he's had enough? Or is the company thinking about more layoffs? Or maybe he just notices the direction of the arrow on the graph. Or perhaps, since there is no date on the resume, he may have written those words some time ago. Record has been with SCO, oldSCO first, since 1983. He was SCO's Lead Technical Architect, it says, on SCO Linux 4.0, "Powered by UnitedLinux". He almost singlehandedly did the SCO Skunkware project, along with thousands of volunteers around the world, of course. His resume lists him as the author of this paper on it, which begins (and I've marked the parts that stand out to me):
The UNIX technical community has a longstanding tradition of publishing the source code to programs in order to share technical accomplishments and facilitate peer review. Examples of this include sendmail, bind, the X11 graphical windowing system and dozens of USENET newsgroups devoted to the exchange of source. The recent rise in popularity of the Apache web server and the Linux operating system have provided a spotlight for "Open Source" software. How does SCO fit in this picture? How can SCO customers take advantage of this type of software? How can SCO developers contribute to this movement and leverage the eyes and minds of thousands of programmers on the Internet?...
Recent months have seen an explosion in Open Source awareness. However, freely available source code has been with us for dozens of years. Much of the infrastructure of the Internet is based on Open Source software. Many of the core components of a UNIX operating environment are Open Source....
Many Open Source components derived from research work done at Universities. Partly in support of this research the UNIX operating system source has traditionally been offered to Universities at a minimal licensing fee. When SCO acquired the rights to early UNIX source (the Mini UNIX operating system; the UNIX V6 operating system; the PWB UNIX operating system; and the UNIX V7 operating system, which also covers Editions 1-5, and the 32V), source licenses were made available at cost....
SCO recently engaged in an Open Source project which oversees the development and distribution of lxrun, a Linux emulation system. This open source project is being incorporated into UnixWare 7 as a supported feature of the operating system. ...
The lxrun project is an example of how rapidly an open source project can evolve. It's also an example of one of the many Skunkware components that are being absorbed into the standard supported product.
He wrote that in 1999. Today SCO would have us all believe that Unix was always a closely guarded Sooper Seekrit. In 1999, Record wrote a paper on "Porting Open Source Software to SCO," which helpfully explained the following:
Perhaps the single most important step in porting any software is the creation of an appropriate build environment. Fortunately, on SCO OpenServer 5 and UnixWare 7, much of the work has already been done for you. On either platform, simply install the base Operating System, native development system, Java Development Kit and the SCO Skunkware CD included in the Operating System media kit.
If you are not a licensed Development System user you can still build an appropriate development environment by utilizing the GNU development system along with the native libraries and headers. On OpenServer you will need to install the "Linkers and Application Libraries" package of the Development System (no license key is required). On either platform you can simply install the Development System sans license key.
After having installed the Operating System, development system of choice, and SCO Skunkware you will now have access to the standard tools necessary to build most Open Source packages. These tools include the GNU Compiler Collection, Bison, Flex, GNU Make, autoconf, automake, and a wide variety of header files and libraries....
Another configuration area that often causes problems is the building of shared libraries. The ltconfig script contains the platform-specific instructions and options for creating shared libraries.
Record was also a founding member of the 86open Project, which was a 1997 project made up of individuals who wished to address the fragmentation of Unix by developing a way for applications to run smoothly on all types of Unix or Unix-like operating systems on Intel, as the project's home page explains:
On October 1997, a group informally calling itself the 86open project issued a communiqué, discussing the need for a standard binary executable for the various Unix and Unix derivatives which run on Intel 80X86 "PC"-architecture systems.
The group, which had met earlier that year at the headquarters of SCO, eventually included representatives or developers involved with the most popular such operating system suppliers:
The aim of this effort was to encourage software developers to port to the Unix-Intel platform by reducing the effort needed to support the diverse mix of operating systems of this kind currently available.
The original target was a binary format specification which would supportable by each OS, without emulation, in addition to (but not to replace) each OS's native format. The early discussions centered around Linus Torvalds' scheme involving a standardized programmers' function libraries, and agreement on numbering schemes for signals and other interfaces.
The group was making reasonable, if slow, progress into mid 1998. At that time, SCO was involved in the development of lxrun, software which ran Linux-format binaries under the two SCO operating systems (OpenServer and UnixWare).
The possibility that SCO could run Linux binaries made the need for 86open less important. Most of the BSD programs already have solid capabilities for running Linux binaries.
The lxrun package is now stable and runs well. It was officially announced by SCO at LinuxWorld in March 1999, and was later ported by Sun to allow Linux binaries to run under SolarisX86.
With these announcements, the need for a distinct common binary standard is gone. The operating system vendors, one way or another, have chosen a common binary format -- the Linux ELF format, which is now supported on the systems of all the developers which originally joined 86open.
It is therefore only logical that the 86open project declare itself dissolved. Our goal -- the development of a single binary that software vendors can trust will run on most Unix and Unix-derivatives on PC platforms -- has been realized. It didn't come about the original way we had planned, but we achieved what we set out to do.
Thanks to everyone for your participation and interest.
Chair, 86open project
Interesting little bit of ELF history, don't you think? Who copied whom, then? And so what do you think: did SCO know back in 1997 exactly how ELF in Linux was designed? Did it object? This group met at SCO's headquarters, and Record was there. Here's who the FAQ says was a member of the steering committee:
Q11: Who is involved?
Here is the current membership. Note that only names are given, not affiliations, deliberately (see Q9). Members of the steering committee are in bold:
Tim Bird, Keith Bostic, Chuck Cranor, Michael Davidson, Chris G. Demetriou, Ulrich Drepper, Don Dugger, Marc Ewing, Steve Ginzburg, Jon "maddog" Hall, Ron Holt, Jordan Hubbard, Dave Jensen, Dion Johnson, Kean Johnston, Andrew Josey, Evan Leibovitch, Robert Lipe, Bela Lubkin, Tim Marsland, Greg Page, Bruce Perens, Ron Record, Andrew Roach, Tim Ruckle, Joel Silverstein, Bryan Sparks, Chia-pi Tien, Linus Torvalds, Erik Troan.
Record was not on the steering committee, but he was a founding member, for crying out loud. If you read the FAQ, it explains the name, 86 because Unix on Intel was often referred to as the X86 architecture, and open because they intended their work -- to develop "a method to allow a single binary program to run, unmodified, on any participating OS" -- to be made freely available for all to use. Do you realize the significance of that? They were basing their work on Linux's ELF format, and then planned to release it freely to the world to use. It may have been an informal group, but it was public, and it met in SCO's building, and one of the founding members was Ron Record, who is still with SCO in 2006. Around the same time, SCO wrote lxrun to do the same thing. The 86open FAQ provides more details:
Q18: How can you get a single binary to work identically across all these diverse systems?
Most Unix-on-Intel binary packages are already largely similar. Almost all such operating systems use the "ELF" binary 'packaging'; the various operating systems have small but significant differences, though, that make each system's ELF binary unusable on others'.
Because of earlier binary compatibility efforts such as the iBCS2 (which has been a part of UNIX since System V/386 Release 3.2), most of the older functionality is already quite similar between the systems. Most of the divergence has been in post-iBCS2 developments such as lstat() and mmap().
The 86open group plans to solve this problem by producing a standard set of library functions that would be provided on each participating OS. A binary using these standard functions would dynamically link into the local library containing them, thus allowing it to operate regardless of the different internals of the underlying OS.
It is up the library implementation on each OS to hide any OS-specific behavior behind the standard functions, allowing programmers to concentrate on a single Application Programming Interface (API) for a binary that will work on all systems.
Q19 This might work in concept, but is it practical?
Yes, absolutely. One such proof-of-concept is the the lxrun project, which allows Linux binaries to work on SCO and Solaris operating systems by mapping Linux OS-specific system calls to their SCO equivalents by use of a 'shim' library.
The feasibility of a common Unix-on-Intel binary by use of a single library specification was agreed to by all the programmers involved.
Q20: What will be in this new library?
That's what's being worked on at this time. The emphasis is on defining a set of functions that is "sufficient, yet limited", in the words of Linux creator Linus Torvalds. The intention is to include all the basic functions necessary to create applications (and act as a base for other libraries, such as for X Windows), while removing redundancies and unnecessary code according to the groups' consensus.
The group is starting with a conventional Unix 'libc' (GNU's glibc2) as its point of reference. While any participant is welcome to create its own implementation of the 86open library specification, the reference will be based on glibc....
Q22: How will you ensure that the specification is open?
The license of GNU glibc requires that it's freely available in source code, and that all modifications to it be similarly available. Furthermore, 86open is committed to maintaining a reference implementation of its library specification that is available in source code and freely re-distributable.
The lxrun page tells us this:
Lxrun is a user-space program that allows users of SCO(r) OpenServer(tm), UnixWare(tm), and Sun(r) Solaris(tm) x86 operating systems to run ELF and a.out format Linux binaries. It was originally written by Mike Davidson of SCO. It is now maintained under the Mozilla license as an open-development effort. The source maintainer is Steven Ginzburg. All suggestions, ideas, and contributions of source code and patches are welcome.
I think the company had to know, don't you?
And if everyone knew that 86open deliberately followed Linux's ELF format, and knew about lxrun, how does it happen that SCO is suing over ELF in 2003-2006, claiming it violates its Most Holy IP, when the company and individuals working there have to know it's not fair and it's years too late even if it were fair?
That is the part of this entire saga that puzzles me so. How do people justify this course? They all sat together at meetings and worked together. Linus was there. How can anyone who worked on the 86open project just go along with attacks on Linux's integrity just because business interests collided? I simply don't understand how that is possible. Why did Record stay after SCO began its scorched earth antiLinux policy? Who knows? Groklaw isn't about personalities and I never want to attack any human, only policies. Maybe he just needed a job, as simple as that. But he's a large part of the SCO history, which makes this all relevant. And it does puzzle me. Not only that but what puzzles me even more is why the legal team didn't ask Record about ELF before they filed such a claim. Or did they and just barreled ahead anyway? And what about the experts? Don't they know this history? If I can find it, why didn't they?
It's sad, really, to think of all Record's seen over the years and all that has happened to the company that he must have loved. A lot of people loved the Santa Cruz Operation. Here's something Record wrote back when the SCO-Caldera deal was announced:
Oh, by the way, hi - i'm new to this list. My name is Ron Record
and I promote Microsoft alternatives and open source solutions within SCO....
I'm stoked about the Caldera/SCO deal. It will likely bring a lot more focus to
the Open Source work that i've been involved in. As for the Unix business, i guess
i should quote Ransom Love, CEO and founder of Caldera:
"Caldera will further broaden and validate both the Linux and UNIX
industries and communities, by providing open access to its unified
Linux and UNIX technologies, and by offering support, training and
professional services to customer worldwide. Caldera is fully committed
to supporting and servicing the SCO OpenServer and UnixWare communities."
Sorry about quoting a CEO from a press release. I will be able to say more once
the deal is completed. I have a very good feeling about how Caldera is going to
drive Unix forward.
It gives you the feel of the man, doesn't it? It's impossible for me to dislike the man, and if he needs a job, I sincerely hope he finds a good one. But his dream, "a desire to see the UNIX cathedrals build
bazaar wings and, conversely, the Linux bazaars to incorporate some features
of the cathedral development model" was never realistic. Linux, in all frankness, didn't need Unix. It was the other way around, which is why the Unix companies were forever trying to get Linux apps to work smoothly on what they were selling. Linux just kept attracting developers, and that is the fundamental reason why it succeeded. It really had nothing to do with IBM or any other commercial Unix company hitching a ride. It's all about developers, you know. And Linux had them then and it has them now. That's why IBM and HP and all the rest of the enterprise players were attracted to Linux. First came the chicken, and *then* the egg. SCO has been telling it backwards.
And so now, we solemnly add yet another piece of damage to all the human damage that has resulted from this pitiful litigation strategy. But honestly, if the SCO employees that knew the score had clued their bosses in on the futility of this litigation, even if only the detail about ELF and binutils, might it have helped prevent some if not all the damage to the industry? I can't help but wonder, first if it might have, and second why it seems not to have happened. Unless...