decoration decoration

When you want to know more...
For layout only
Site Map
About Groklaw
Legal Research
ApplevSamsung p.2
Cast: Lawyers
Comes v. MS
Gordon v MS
IV v. Google
Legal Docs
MS Litigations
News Picks
Novell v. MS
Novell-MS Deal
OOXML Appeals
Quote Database
Red Hat v SCO
Salus Book
SCEA v Hotz
SCO Appeals
SCO Bankruptcy
SCO Financials
SCO Overview
SCO v Novell
Sean Daly
Software Patents
Switch to Linux
Unix Books


Groklaw Gear

Click here to send an email to the editor of this weblog.

You won't find me on Facebook


Donate Paypal

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

No new stories

COMMENTS last 48 hrs
No new comments


hosted by ibiblio

On servers donated to ibiblio by AMD.

Tigran Aivazian Says His SMP Contributions to Linux Kernel While at SCO Were Approved by his Boss
Friday, December 12 2003 @ 03:01 PM EST

Groklaw has reported before on contributions made to the Linux kernel by Christoph Hellwig while he was a Caldera employee. We have also offered some evidence of contributions by oldSCO employees as well. Alex Rosten decided to do some more digging about the contributions of one kernel coder, Tigran Aivazian.

Tigran contributed code to the kernel, including to SMP, while working at oldSCO, and he informs us he did it with the approval of his superiors there at the company and his boss knew the code would be distributed under the GPL.

This paper is a group effort. Alex's research was shared with others in the Groklaw community, who honed, edited, and added further research. Then the final draft was sent to Tigran himself, so he could correct and/or amplify, which he has done.


~by Alex Roston

One of the most interesting bodies of evidence in the SCO case is the work of Tigran Aivazian, a truly excellent programmer who's made some fantastic contributions to Linux. Mr. Aivazian worked for Old SCO before the Caldera purchase and then went on to work at VERITAS. Mr. Aivazian has been a kernel maintainer for several years in two separate areas, the BFS filesystem and INTEL P6 microcode update support as noted here.

Note that the link refers to of the kernel maintainers list. A later update of the same list (2.4.20 maintainers) shows him in charge of "INTEL IA32 MICROCODE UPDATE SUPPORT," (obviously a renaming of "INTEL P6 MICROCODE UPDATE SUPPORT") and he's also still in charge of the BFS filesystem, though his email address has changed to tigran (at) Intermediate versions of the list and most of the URL's shown below list him as tigran (at)

In other words, he's a longtime maintainer of two parts of the Linux kernel, both while at SCO and at VERITAS. BFS filesystem support isn't terribly important to most Linux users. According to the Filesystem HOWTO the "UnixWare BFS filesystem type is a special-purpose filesystem. It was designed for loading and booting UnixWare kernel." In other words, you won't need BFS unless you're experimenting with some kind of UnixWare implementation. However, the appearance of the BFS kernel in Linux is interesting because it's a clearcut case of a SCO programmer transferring something that could be described as an enterprise enhancement from UnixWare to Linux. According to this note by Tigran, it's been part of the standard kernel since October 28th of 1999.

At this point, you may be wondering two things: first, whether Mr. Aivazian is some kind of rogue coder, a guy who couldn't keep his employer's trade secrets, so let me assure you that this is not the case. Take for example this email, where we discover that Tigran Aivazian, writing from his email address, is finally able to speak publicly about certain facts that previously he wasn't free to discuss:

"The stuff below is no longer a secret so I think I can share it with you. It does mention Linux quite a few times and may even answer someone's question as to whether SCO is interested at all in Linux."

The next question you likely have is, were his Linux contributions authorized by the company and did they realize it would be distributed under the GPL? As frequent Groklaw contributor Harlan put it upon reading a first draft of this piece, "These are the good guys. Chris Hellwig, Tigran Aivazian, Steve Pate, Jun Nakajima, and Niels Christiansen have each taken time out to write about what they are doing, and to explain or teach others. This is communal computing - exactly what Ken Thompson and Dennis Ritchie wanted to preserve when Bell Labs pulled their group out of the MULTICS Project."

We contacted Mr. Aivazian about this matter, and he wrote back as follows:

"Yes, my very humble contributions to the Linux kernel (BFS filesystem and IA32 microcode update driver) done during my work as an escalations (UnixWare kernel) engineer at SCO were approved by our then-director Wendy Jones (who now works for Sun I think) and by higher management as well (I have bad memory on names, so I can't remember exactly, I think it was on Doug's level or so).

"For example in the case of BFS filesystem the matter was as follows. I did NOT use any of the UnixWare (or other) proprietary code for the implementation, of course. However, despite this fact, I still (for courtesy and generally being cautious) requested permission from Wendy (Development director) before the release under GPL and she confirmed that SCO has no claims to this work whatsoever and has no objections to its release under GPL, because it is not connected to UnixWare source code in any way."
[emphasis added]

Let's move along to the the microcode update feature of the Linux kernel, which Mr. Aivazian also maintains. This particular kernel code is much more important than the BFS filesystem because it deals with installing updates from Intel into their CPUs. It's a part of the kernel you don't hear much about, but should someone discover a major Pentium bug the phrase "IA32 microcode update support" will suddenly be on everyone's lips. Microcode update support was added as of kernel version 2.3.46, and it has also been backported to kernel 2.2.18.

In terms of the SCO vs. IBM case, Mr. Aivazian's work is important for two reasons. First, he has worked on SMP, though not all of his SMP work takes place in kernel space. Second, he's done an enormous amount of work toward making Linux into an "enterprise level" operating system. Paragraph 114 of SCO's Amended Complaint reads as follows:

"114. IBM has breached its obligation of confidentiality by contributing portions of the Software Product (including System V source code, derivative works and methods based thereon) to open-source development of Linux and by using UNIX development methods in making modifications to Linux 2.4.x and 2.5.x, which are in material part, unauthorized derivative works of the Software Product. These include, among others, (a) scalability improvements, (b) performance measurement and improvements, (c) serviceability and error logging improvements, (d) NUMA scheduler and other scheduler improvements, (e) Linux PPC 32- and 64-bit support, (f) AIX Journaling File System, (g) enterprise volume management system to other Linux components, (h) clusters and cluster installation, including distributed lock manager and other lock management technologies, (i) threading, (j) general systems management functions, and (k) others."

Keep reading and you'll see that Mr. Aivazian, who worked for SCO while he did most of the work we're about to discuss, made major contributions toward helping Linux "achieve," as SCO puts it in their complaint, "high-end enterprise functionality."

Let's start by looking at Mr. Aivazian's contributions to SMP. Here we discover him being thanked by the maintainer of the SMP HOWTO.

Here we see, in the file header to smpboot.c, that Mr. Aivazian is credited with fixing a minor problem called the "0.00 in /proc/uptime on SMP" bug. Here we see the letter where he made his suggestion for dealing with the problem:

Here Tigran talks about a bug in linux-smp. To be more exact, he's adding to the bug description. The bug was originally found in the "read(2)" section of the code and Aivazian takes things one step further, noting that the bug is also in the "write(2)" section of the code. You can see that he worked as part of SCO's Escalations Research Group.

This takes place on the 16th of October in 1998. In other words, three years after Caldera financed the purchase of a dual Pentium board so Alan Cox could develop SMP, a SCO coder was also making contributions to SMP and this was before the Caldera-oldSCO deal.

On this thread from 1999, long before IBM started working on Linux, he discusses "SMP safe operation."

Here's another SMP thread from 1999, with Tigran writing from his email address.

Neither of the URLs above discusses the SMP in the kernel in any depth, but it makes clear that a SCO programmer was actively helping to make someone else's Linux work properly under SMP. What's even more exciting about this discussion is that the programmers are talking about improving get-cycles(), which is a tool for counting CPU cycles. Improving this code provides Linux with improvements in performance testing and scheduling. Also, as you doubtless know, code that runs properly under SMP is, according to SCO, "enterprise capable" code.

In another thread, also from 1999, Tigran provides a bootlog showing an SMP error in the 2.3.32 kernel.

Linus accepts the bug report and replies that he's removing the bad code.

On January 4th of 2000, Aivazian talks about code that might be "...not only inconsistent but disastrous (on SMP if list is modified at teh (sic) same time)" and here's the reply from Manfred Spraul. He agrees that the code can cause SMP problems. Once again, we see the SCO programmer helping Linux coders make their code run with SMP.

Here's a patch to the 3c509 driver, (3c509 is an ethernet chip) where Tigran and two other programmers discuss possible problems relating to SMP code. However, you'll also note that the patch wasn't accepted.

A couple other references to the conversation can be found here, where Tigran is writing directly to Linus, and here.

In this post Tigran talks about making the piece of code under discussion SMP safe. This is a big deal for Aivazian, because as we'll see later, he prefers to use the vmalloc function (rather than the kmalloc function) for his microcode update work.

This is from kernel 2.3.35. The person who replies to him is Alan Cox, who implemented the first version of SMP for Linux. Cox dislikes Aivazian's suggestion.

Tigran replies, noting that he sent Alan a private e-mail on this subject, and suggesting a patch.

This idea is kicked around by Aivazian, who notes that he looking for some code for testing this subsystem.

James Lokier, Manfred Spraul, and Bill Wendling discuss this for a little while. Meanwhile, on a different subthread, Tigran suggests that perhaps it's time to use a patch he submitted some time back.

Then he changes the name of the thread to "smp-safe vmalloc (was Re: [Patch] Polling on more than 16000 file descriptors)" and continues in this post.

Note that this is some very high-level discussion about SMP, though it appears, in the next mail from Bill Wendling, that this particular idea didn't work very well.

You'll notice that in addition to the issues with SMP, much of the discussion above centers around Aivazian's concerns with vmalloc and kmalloc. Aivazian is credited with making vmalloc.c SMP safe in May of 2000.

* linux/mm/vmalloc.c
* Copyright (C) 1993 Linus Torvalds
* Support of BIGMEM added by Gerhard Wichert, Siemens AG, July 1999
* SMP-safe vmalloc/vfree/ioremap, Tigran Aivazian , May 2000
* Major rework to support vmap/vunmap, Christoph Hellwig, SGI, August 2002

This listing is from kernel 2.5.69, but note the date of Aivazian's contributions.

Aivazian's concerns with vmalloc, both in the 2.5.69 kernel and in the kernels he was discussing in January of 2000, are very significant for two reasons. First, because the improvements to the vmalloc function are minor performance enhancements, (the previous vmalloc interacted with SMP in a fairly clumsy manner, the new one is much more subtle in the way it interacts with multiple CPUs) and second, because Mr. Aivazain prefers the use of vmalloc for the IA32 microcode update feature he maintains. To quote his Linux Magazine article on the microcode update:

"The microcode_write() routine performs the following steps...

"4. Allocates a kernel buffer (using vmalloc()) large enough to hold the user-supplied sequence of microcode chunks. If this request fails, we return to user space without freeing mc_applied, hoping that it may be needed later. The vmalloc() function is preferred over the kmalloc() function because the buffers may be very large (on the order of 100-200K), and we do not need a physically contiguous area but only a virtually contiguous one; so vmalloc() can suffice."

This, of course, brings us to the microcode update program. You should note that the microcode update feature was a work-in-progress for some time. He developed it while he worked at SCO but continued to maintain it while employed at VERITAS. He did not work alone. Roland Smith has pointed out that he believes the actual microcode binary data itself comes from Intel and that Mr. Aivazian also received help from Intel employees.

Now things get really interesting. In the Linux Magazine article above, Aivazian states, "The other Unix-like IA32 operating systems known to the author that support microcode update (on P6 family only) are SCO OpenServer 5.0.6 and SCO UnixWare 7.1.1. The Linux implementation was written from scratch in the author's spare time and was not based on any Unix or non-Unix version."

We should also note that, as Mr. Aivazian explained above, he uses a different approach to the microcode update feature than was used by SCO. As he tells us in the Linux Magazine article:

"Obviously, any device driver needs some user space program to interact with it, even if it is one of the existing programs like dd(1) or cat(1). It is therefore important to decide early on how much work is to be done in the kernel and how much in user space.

"For the Linux implementation of the driver, the author decided to perform all the work of selecting the appropriate microcode chunk, checking the revision, validating the checksum, and applying the microcode in kernel space. The only work left for user space is to convert the microcode from the format supplied by Intel to one that is easier to manipulate in the kernel and to control the kernel driver via the ioctl(2) system call.

"This design choice is not the only possible one. To give an example, I will mention a non-Linux implementation of the microcode update feature, namely that of SCO UnixWare 7.x. Since the UnixWare kernel allows the running process to bind itself to the current CPU so that it can safely operate on the data structures corresponding to that CPU (knowing that it will never be scheduled to run on a different CPU), it is possible to implement the microcode update feature almost entirely in user space. I say "almost" because the ability to execute privileged instructions, such as reading and writing MSRs, is still restricted to the code running in the kernel."

Moving along, we find this URL, where Mr. Aivazian asks for comments on a patch to kernel 2.3.47. Note the reference to "lock_kernel" (locking is an important SMP concept,) smp_lock.h, and the variable "smp_num_cpus."

So we can see that there's an enormous amount of SMP-related stuff in this file, which as I noted earlier, is now part of the Linux kernel. (The user portion of the microcode update feature is here.)

Let's put SMP issues aside for now (after all, every piece of kernel code needs to be SMP-safe) because this is an important point to make. To explain why, let's begin by defining microcode. According to Frank Wales:

"... the instruction set for the processor is broken down into a small set of elements that are designed to be activated in various combinations, a bit like the keys on a piano. Combine a few this way, and the processor adds the contents of that memory location to this register. Combine some others another way, and the processor jumps to this address in memory for its next program instruction. And so on.

"The specification for all these combinations of parts that make up all the CPU's instructions is what the microcode represents. It's basically the programming within the processor that makes it work as the CPU specification says it should..."

The purpose of microcode update is to update the microcode on an Intel CPU. If, for example, the eight Pentium IV chips in your big server are discovered to have a bug, you can do two things. You can wait until Intel brings out new chips (or hands out a BIOS upgrade) and replace the chips in your server, which could get expensive, or you could download the fix from Intel and update the microcode yourself by using the microcode update feature Tigran Aivazian put into the Linux kernel. Now each time the machine boots, the correct microcode will be loaded into the CPUs and your server will now run correctly. (Using of the microcode update feature is not absolutely necessary - the kernel has other ways of detecting and avoiding CPU bugs, but it certainly is a very useful tool.)

So why all the SMP code? The answer is simple. Microcode update might be working with the internal structures of multiple CPUs. In order to load the new code to multiple CPUs correctly, the microcode update feature has a need for SMP capabilities that goes well beyond merely being "SMP-safe." As Mr. Aivazian tells us in the Linux Magazine article, "On an SMP system, we must follow the procedure for updating the microcode for each processor separately, using a different microcode update for "mixed-stepping" SMP systems."

In other words, if there's more than one CPU, the kernel's microcode update code has to know how to handle the problem. It has to separately check each of the CPUs and make sure they are capable of accepting a microcode update. Then it needs to get processor flags from the CPU it's currently working on and check the microcode which is to be applied to that CPU against those flags so it can make sure that it's updating the right type of CPU. After that, it checks the current revision of the CPU against the microcode it is attempting to load, so it can make sure that the CPU isn't already more advanced than the microcode you want to use. Finally, it makes sure that the microcode has been properly applied to the CPU and gives an error message if the update doesn't work for some reason. Then it goes on to the next CPU and does everything again.

Needless to say, SMP-aware microcode update is definitely an enterprise-level feature, and it interacts with other enterprise-level features, such as the Symmetric Multiprocessing in the main kernel. And who's responsible for this wonderful enterprise-level tool? A SCO programmer.

Also, in addition to the multiple SMP calls, the microcode update feature also uses vmalloc. As you'll recall, Aivazian shows great concern for vmalloc in many of the messages we review above, and he's also credited for making the kernel's vmallo.c. code SMP-safe. This doubtless led to improvements in microcode update reliability because any problems in vmalloc might be reflected in microcode update's performance. As you can see from the way these two issues intertwine, Mr. Aivazian obviously knows how to keep his ducks in a nice, neat row.

While the microcode update feature and SMP work are very important, in terms of the SCO vs. IBM case, the most interesting contributions Mr. Aivazian made were to the kernel debugger.

The kgdb page at describes kgdb as follows:

"kgdb is a source level debugger for linux kernel. It is used along with gdb (the gcc debugger - Alex) to debug linux kernel. Kernel developers can debug a kernel similar to application programs with use of kgdb. It makes it possible to place breakpoints in kernel code, step through the code and observe variables.

"Two machines are required for using kgdb. One of these machines is a development machine and the other is a test machine. The machines are connected through a serial line, a null-modem cable which connects their serial ports. The kernel to be debugged runs on the test machine. gdb runs on the development machine. The serial line is used by gdb to communicate to the kernel being debugged.

"kgdb is a kernel patch..."

That's right. kgdb is not included in the main kernel. Linus has opposed the addition of a kernel debugger for years - but if you apply the kgdb patch and rebuild the kernel, kgdb will feed its output to the regular gcc debugger, gdb, which is located on a separate machine. Why is this valuable? Because even if the kernel you're working on contains some truly evil code which melts your CPU and obliterates your hard drive when it crashes, the debugging information, up to the point where your code crashed, is sent to another computer so you can use the standard gcc tools to discover exactly how the disaster happened.

You'll note on this page that the kgdb patch was initially available for kernel 2.2.5, which was released in March of 1999, about a year and half before Caldera bought SCO.

According to the author of the piece, Martin Pool, Mr. Aivazian integrated "thread support" and "support for multiple processors" (that is, SMP) into the kgdb code that had been contributed by the "Lake Stevens Instrument Division." To quote Mr. Pool, this code is for "on-line debug support for multiprocessor machines, which is an enterprise feature inasmuch as that word has meaning."

This is significant because Paragraph 84 of SCO's Amended Complaint says that they believe Linux could not have succeeded without "...access to expensive and sophisticated design and testing equipment," and this idea is rehashed several times in the course of SCO's complaint. If the ability to use one machine to debug another isn't "sophisticated design," I don't know what is. It's certainly "expensive," particularly if you're debugging SMP code and need a multiprocessor motherboard, and it might even fall under SCO's definition of "testing equipment." According to Roland Smith the "testing equipment" portion of SCO's complaint probably refers to an In Circuit Emulator, such as the one pictured here.

According to Dave from the sales staff at American Arium, their version of an In Circuit Emulator for Pentium chips costs anywhere from ten thousand to forty thousand dollars.

Beyond being an enterprise-level enhancement, kernel debugging is also interesting because it is tightly tied to the kernel's SMP support, and we know that SMP is one of the things SCO claims could not have happened without IBM support. In fact, kgdb can be used to test the kernel's SMP modules.

In other words, at least one SCO programmer was putting important contributions of code into the Linux kernel since before SCO was bought by Caldera, and one of the things he contributed to is an important testing suite to help make SMP safe. One of the functions of a programmer is to debug code, so kgdb is an important general addition to the kernel.

To continue, here we see a Mr. Aivazian responding to a letter from Andrea Arcangeli about which debugger Arcangeli should include in his own source tree.

Here's a kgdb patch from the 2.4.19pre10 kernel:

You'll notice four separate listings for Tigran Aivazian, as follows. You'll also note that kgdb references an enormous amount of code for SMP:

"+ * Integrated into 2.2.5 kernel by Tigran Aivazian "

"+ * Change History
+ *
+ * Tigran Aivazian Remote debugging support."

"+(modified by Tigran Aivazian )
+ Putting gdbstub into the kernel config menu."

"+ * 3/99: Added TIOCGDB for remote debugging with gdb if compiled with
+ * Tigran Aivazian"

Here's another patch for kgbd dating from October of 2003. In fact, this is meant to work with the 2.6pre6 kernel. Once again, Tigran Aivazain is mentioned twice for his earlier contributions and you'll also find considerable amounts of SMP.

The references above demonstrate that Mr. Aivazian tried to add debugging code to the official kernel and had influence on the development of kernel debugging for Linux. It should also be obvious that besides containing SMP code the kernel debugger is also very useful for writing good SMP code. This enterprise-level enhancement dates back to kernel 2.2.5 - once again, long before the Caldera-SCO purchase and long before IBM programmers began contributing to the Linux kernel.

It seems everything Mr. Aivazian does works together. If SMP or vmalloc.c doesn't work, the microcode update feature might fail, so he works on SMP and vmalloc.c. If either SMP or microcode update is crashing, he needs to know why, so he works on the debugger. The thing that makes this important to us is that SCO's complaint accuses IBM of illegally helping to develop enterprise level features in Linux. To quote paragraph 82 of SCO's Amended Complaint:

"Virtually none of these software developers and hobbyists had access to enterprise-scale equipment and testing facilities for Linux development. Without access to such equipment, facilities and knowledge of sophisticated development methods learned in many years of UNIX development it would be difficult, if not impossible, for the Linux development community to create a grade of Linux adequate for enterprise use."

But here we see the SCO programmer working on "enterprise-scale equipment and testing facilities" - and SCO's name is literally all over it. Also, from the way all Mr. Aivazian's work connects together, we can also conclude that he has made a very important contribution toward creating "a grade of Linux adequate for enterprise use."

Now let's go back to paragraph 114 of SCO's Amended Complaint. IBM is accused of giving Linux:

"(a) scalability improvements, (b) performance measurement and improvements, (c) serviceability and error logging improvements, (d) NUMA scheduler and other scheduler improvements, (e) Linux PPC 32- and 64-bit support, (f) AIX Journaling File System, (g) enterprise volume management system to other Linux components, (h) clusters and cluster installation, including distributed lock manager and other lock management technologies, (i) threading, (j) general systems management functions, and (k) others."

Looking back at Tigran's work, we see that a SCO programmer is responsible for much of what SCO itself is complaining about. Aivazian has been responsible for the following:

(a) scalability improvement: - SMP in a nutshell. Mr. Aivazian has programmed SMP, vetted SMP code by others, notified others about SMP bugs, worked on a testing suite that's useful in debugging SMP code, and provided documentation for SMP.

(b) performance measurement and improvements - Mr. Aivazian has done a great deal of work toward giving us a nice kernel debugger, which of course can help us measure and improve performance. As you'll recall, he also advised Andrea Arcangeli in his efforts to improve the of get_cycles() function, which is the code for measuring CPU cycles which we discussed above. Lastly, his improvements to vmalloc, as I noted earlier, represent minor performance improvements.

(c) serviceability and error logging improvement - the microcode update feature, which Tigran Aivazian created, helps provide serviceability.

Once again, these are all "enterprise level" features, and Mr. Aivazian has been doing this work since at least 1998. Further, he did almost all the work we've seen here both before SCO was purchased by Caldera and before IBM began working on Linux. And he did it with authorization from his superiors at SCO.

Thanks to everyone who read the previous version of this story, making it a true open-source effort, particularly bruzie, D, Doughnuts Lover, emebit, John Gabrial, gunnark, Harlan, jamesw, kevin, rsmith, Ruidh, snorpus, tazer, and Frank Wales. Special thanks, of course, go to Mr. Tigran Aivazian who was kind enough to read this manuscript and offer some final corrections. He wishes to make clear that the views he expresses are his own, not those of his employer.


Tigran Aivazian Says His SMP Contributions to Linux Kernel While at SCO Were Approved by his Boss | 153 comments | Create New Account
Comments belong to whoever posts them. Please notify us of inappropriate comments.
You ROCK PJ !!
Authored by: farfrael on Friday, December 12 2003 @ 03:09 PM EST
Nothing else to add, awesome work ...

Thank you so much for your work !
Thanks to every contributor to this paper.

[ Reply to This | # ]

Tigran Aivazian Says His SMP Contributions to Linux Kernel While at SCO Were Approved by his Bos
Authored by: Anonymous on Friday, December 12 2003 @ 03:20 PM EST
Excellent, this is the kind of stuff we always knew existed. Brilliant work

SCO have got a lot of exlaining to do ;-)

[ Reply to This | # ]

Tigran Aivazian Says His SMP Contributions to Linux Kernel While at SCO Were Approved by his Boss
Authored by: ktaute on Friday, December 12 2003 @ 03:30 PM EST
PJ, have you ever considered asking IBM for a contribution when they get their
legal fees?

With this kind of information, I would think they would pay you a BUNCH!

Did Tigran or any of the others mention that IBM has contacted them for any

[ Reply to This | # ]

Tigran Aivazian Says His SMP Contributions to Linux Kernel While at SCO Were Approved by his Boss
Authored by: pfusco on Friday, December 12 2003 @ 03:30 PM EST
Simply amazing. I wonder if IBM has plans on asking Mr. Aivazian to testify in
court should that day ever happen.

Also, I just need to say that your work and the work of all the others on this
site have been exemplary and I have come to respect more and more the members
here. Thank you for keeping us so well informed PJ

only the soul matters in the end

[ Reply to This | # ]

Tigran Aivazian Says His SMP Contributions to Linux Kernel While at SCO Were Approved by his Bos
Authored by: Beyonder on Friday, December 12 2003 @ 03:32 PM EST
explaining? nah, SCO will just come up with more crap, like their ever famous
comments such as: "no, we were never talking about SMP", or
something silly.

Like with the code they showed at the SCOforum thing, which turned out to be
public domain, they suddenly doubled-back and said they never claimed it was a
real examle of code, just a demonstration, and tried to claim they never
mentioned or referred to IBM (though IBMs name was on the slides).

Anyone remember that fiaSCO? well, here we are again.
Time and time again I wonder why people are surprised by any of this, or take
SCOs word for anything (even as in a situation like giving them the benefit of
the doubt), that has to stop.

If anyone here has ever worked for a place that got bought out then turned into
a pump and dump, you should recognize what SCOs been doing, it should have an
all too familiar eerie feeling about it...

[ Reply to This | # ]

Tigran Aivazian Says His SMP Contributions to Linux Kernel While at SCO Were Approved by his Bos
Authored by: Anonymous on Friday, December 12 2003 @ 03:34 PM EST
Sometimes I wish I could hug you. It probably wouldn't be considered
"acceptable" behaviour. And who knows I might be a repulsive maniac
so you shouldn't let me.
At least not in real life.

But this being the world of the virtual where evertything is literally
"virtually" possible. I send you a great big hug. My thanks and all
my admiration.

No guns, no bombs...just brains
The way it should be.

[ Reply to This | # ]

SCO Responds!
Authored by: Anonymous on Friday, December 12 2003 @ 03:41 PM EST
"We would have gotten away with it, if it wasn't for you meddling Groklaw

[ Reply to This | # ]

Tigran Aivazian Says His SMP Contributions to Linux Kernel While at SCO Were Approved by his Boss
Authored by: Anonymous on Friday, December 12 2003 @ 03:48 PM EST
> Let's move along to the the microcode update feature of the Linux
> kernel,

You're missing an end-blockquote tag right before that.


[ Reply to This | # ]

Higher level verification.
Authored by: kyricc on Friday, December 12 2003 @ 03:48 PM EST
Great stuff! Has anyone tried to verify with this 'Wendy Jones' or anyone
else that this was done with their apporval? I don't deny or disbelieve
anyones word, but I think verification of those claims will give some validity
to the comments for those doubters still out there.

[ Reply to This | # ]

Tigran Aivazian Says His SMP Contributions to Linux Kernel While at SCO Were Approved by his Boss
Authored by: koa on Friday, December 12 2003 @ 03:51 PM EST
At this point, why hasn't the law firm representing IBM hasn't hired PJ yet??

I mean, seriously.. Just when I thaught every conceivable stone was turned, over
goes another....

Fabulous. Period.

...move along...nothing to see here...

[ Reply to This | # ]

Tigran Aivazian Says His SMP Contributions to Linux Kernel While at SCO Were Approved by his Boss
Authored by: Anonymous on Friday, December 12 2003 @ 03:56 PM EST
This article has shown that SCO has been a contributor to SMP on Linux. Does
this invalidate the claim that IBM isn't allowed to? Does pointing out a
double standard like this in court affect anything? Does it prevent them from
claiming damages from IBM's SMP contributions (legally)? Couldn't SCO
justifiably say that they were only giving Linux partial support (kinda like the
Vulcans' support for warp technology on the new Enterprise series)? Its all
very interesting, but I'm not convinced it will affect the case.

[ Reply to This | # ]

Authored by: Anonymous on Friday, December 12 2003 @ 03:58 PM EST
That should be "Ethernet" which is a proper noun and probably also a
trademarked term.

[ Reply to This | # ]

Tigran Aivazian Says His SMP Contributions to Linux Kernel While at SCO Were Approved by his Bos
Authored by: whoever57 on Friday, December 12 2003 @ 04:06 PM EST
But here we see the SCO programmer working on "enterprise-scale equipment and testing facilities" - and SCO's name is literally all over it.

My interpretation is a little different. What happened was that Tigran and others showed that the job could be done without those enterprise-scale equipment and facilities.

In other words, instead of buying a $40k emulator, they strapped a couple of PCs together and debugged it with a lashup that, although pricy for an individual, was not beyond reach of said individual. This, of course also ignores donations of equipment by companies (Caldera included).

For a few laughs, see "Simon's Comic Online Source" at

[ Reply to This | # ]

Well, big deal.
Authored by: Anonymous on Friday, December 12 2003 @ 04:30 PM EST
Of course Caldera/SCO contributed significantly to the Linux kernel. That is
not the question. The question is what IBM might have contributed out of SCO's
copyrightable material to Linux, unless we disregard all the hyperbole IP
hogwash from SCO in public and concentrate on the contract issue for which they
are actually suing, in which case it does not become a question of copyright and
Linux licences, but simply a monetary issue between IBM and SCO.

It is, however, rather clear that SCO will not be able to base their evidence on
blanket statements about quality: it is quite clear that the explanation is not
simple. They will indeed now have to point out concrete code that has been
copied, and prove that it was done by IBM. And it will not just have to be
AIX-related code, but actually SCO-originating code, or they won't be able to
make their copyright-based claims stick. And their contract law case is not
interesting to Linux users. Even though it will probably be thrown out of court
because without serious copyright infringement the claims that the work is
directly relevant to the Unix contracts is not supportable.

Linux is not Unix, and IBM has not been prohibited to develop other operating

[ Reply to This | # ]

Tigran Aivazian Says His SMP Contributions to Linux Kernel While at SCO Were Approved by his Bos
Authored by: Anonymous on Friday, December 12 2003 @ 04:32 PM EST
Could it be possible to contact Miss Wendy Jones so that she could confirm that
she was the Boss then of mr. Tigran and that she authorized him to contribute
code to linux in the name of SCO ?
That would consolidate the whole argument.

[ Reply to This | # ]

OT: Back to the DDOS/SYN thing
Authored by: mikebmw on Friday, December 12 2003 @ 04:48 PM EST
I appears that SCO could have had an attack. This article from netcraft references groklaw and shows some evidence of an attack. I do agree whole heartedly with a previous comment about SCO seeming to want to link Linux developers with the attack as being more SCO spin to the press to discredit Linux and the community. Even without evidence. But then again when has a lack of evidence stoped them before?

[ Reply to This | # ]

OT--MS now owns this site.
Authored by: lpletch on Friday, December 12 2003 @ 05:14 PM EST
Got some eyeballs on that one, I'll bet. Well anyway I thought this was interesting and most here probably already know this.

United States Patent 6,632,248

Assignee: Microsoft Corporation (Redmond, WA)

Customization of network documents by accessing customization information on a server computer using uniquie user identifiers


User-selected customization information for a network (e.g., HTML) document is stored at a server with reference to user identifying information that uniquely identifies the user. Whenever the user navigates back to the network address of the HTML document, the user is identified automatically and receives a customized HTML document formed in accordance with the customization information.

Use this Link and enter the patent number above.

[ Reply to This | # ]

Tigran Aivazian Says His SMP Contributions to Linux Kernel While at SCO Were Approved by his Bos
Authored by: Alex on Friday, December 12 2003 @ 05:15 PM EST

Just one thing to add. I got a note from Mr. Aivazian this morning. He asked me to add that nothing he wrote should be considered the opinion of his current employer, VERITAS.
So I'm adding it.


Hey Darl!! Did Ross Perot draw your chart?"

[ Reply to This | # ]

SCO, Skunkware, and the Open Source Movement
Authored by: SeismoGuy on Friday, December 12 2003 @ 05:22 PM EST
After a little poking around, I found this at
Notice how references to web pages have been removed?

Is this of interest in this discussion?

SCO, Skunkware, and the Open Source Movement

Published February 1, 1999

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 ?


What is Open Source Software ?
There are a wide variety of phrases used and misused in describing software
whose source is freely available. In fact, a plethora of licensing schemes are
available for such software. Commonly used terms include Open Source, Free
Software, Freeware, Shareware and Public Domain software. Recently Eric Raymond
has created where he provides a definition of the Open Source certification mark
and links to a variety of conforming software licenses at .

Richard Stallman and the Free Software Foundation have provided an extensive
review of the many categories of software whose source is available at . This
article will not attempt to delve into the vagaries and nuances of the specifics
of each of these licenses and categories. The term Open Source Software will be
used to include all software whose source code is freely available and openly
accessible. This will include Freeware and Shareware when accompanied by source
(e.g. XV) as well as commercial products whose source is freely available (e.g.

Open Source Components in SCO Products
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.

Examples of Open Source components in standard UNIX environments include the
mail transport agent sendmail, the Berkeley Internet Name Domain BIND, Dynamic
Host Configuration Protocol DHCP, the InterNetNews server INN and the X11
graphical windowing system X.

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.

What is SCO Skunkware ?
SCO Skunkware is the generic name for a free collection of software prebuilt and
prepackaged for installation on SCO systems. The SCO OpenServer 5.0.5 and
UnixWare 7 media kits contain an SCO Skunkware CD engineered specifically for
that operating system.

Distributions are released on CD periodically and a repository of this and
previous distributions as well as updates and corrections can always be found at
. The SCO Skunkware CD can also be ordered online via .

SCO Skunkware contains a wide variety of software ranging from educational and
experimental research tools to commercial grade software suitable for use on a
production server.

It is provided for free and is not formally supported by SCO. However, Skunkware
is undergoing something of a repositioning as previously unsupported components
move into the standard supported product. What has, in the past, been known as
Skunkware will likely continue to exist as a component of a more traditionally
supported Open Source supplement.

The software on the Skunkware CD-ROM is licensed under a variety of terms. Much
of it is licensed under the terms of the GNU General Public License. Some is
licensed under the GNU Library General Public License. Other components are
licensed under the Artistic License. Many of the components are
"Freeware" with no restrictions on their redistribution while a few
components are "Shareware" meaning the author would like you to try
the software and, if you wish to use it, send her some money. A few components
are commercial products which can be used freely for non-commercial purposes.
Some components simply restrict their use to non-commercial purposes.

To determine the licensing conditions for a particular component, see the
corresponding source in the source directory. With the infrequent exception of
SCO proprietary code, all Skunkware components are accompanied by the source
used to build them.

The Santa Cruz Operation, Inc. and SCO Skunkware are not related to, affiliated
with or licensed by the famous Lockheed Martin Skunk Works (R), the creator of
the F-117 Stealth Fighter, SR-71, U-2, Venturestar(tm), Darkstar(tm), and other
pioneering air and spacecraft.

Open Source Components in SCO Skunkware
SCO utilizes Skunkware as a delivery mechanism for Open Source components which
can provide customers with integrated solutions in a wide variety of emergant
enabling technologies and productivity tools. Among these are:

The GNU C Compilation system - perhaps the most widely used cross platform
C/C++/Objective C and Fortran development environment

Mtools - utilities to access DOS disks and manipulate DOS files and directories

Industry standard scripting languages - Perl, Tcl, TclX, Tk, Python, BLT, Itcl
and Expect

Internet/Networking servers and tools - the latest releases of Apache, the
world's most widely used commercial grade web server; Squid, a high performance
cacheing proxy server; INN, a complete USENET news server; Enhydra, a Java
application server; IRC, internet relay chat clients and server

Editors and text processing tools - groff, SGML-Tools, TeX, xcoral, xemacs,
ghostscript, vim, xhtml

Java applications, servlets, classes and development kits - the Java Servlet
Development Kit, the Java Foundation Classes (Swing), the Apache JServ
server-side Java module, Apache JMeter URL performance meter, the Acme labs Java
classes and applications, VRwave VRML browser, Jikes Java bytecode compiler,
Java bytecode editors/debuggers/obfuscators/disassemblers

Multi-media content creation and viewing tools - the GNU Image Manipulation
Program (Photoshop-like facility), ImageMagick image processing suite, Xanim
animation viewer, MPEG 3 audio encoder and player, MIDI player, audio editing
and conversion tools, graphic file conversion and manipulation libraries and

System administration and security tools - Sentry and Strobe port scan detector
and optimized TCP port surveyor, Cgiwrap for secure user access to CGI, Procdump
and Top for information about live processes or core image, RPM the Redhat
Package Manager

Database servers and clients - MySQL, a threaded light-weight powerful SQL
relational database management system; Addressbook, an on-line rolodex;
Mini-SQL, another SQL relational database management system

Alternate shells and window managers - Bash/Zsh/Tcsh, WindowMaker, KDE

Skunkware also contains a gaggle of games, graphics, eye candy and amusements

X11 based adventure and video games - Xdoom, Xgalaga, Xboing, Xpool, Xmame

Mathematical recreations and research tools for exploring chaotic dynamical
systems, iterated function systems, Lyapunov and Mandelbrot sets, ...

Miscellaneous fun and interesting stuff - create graphical astrology charts,
simulate a fish tank, display your Scottish tartan

A full list of hundreds of currently shipping Skunkware components can be found

The Open Source Support Model
Open Source Software and SCO Skunkware have an alternative support model. Since
the source is available, it is often possible for the end-user to self-support
or to easily consult with local experts. Further, due to the communal and open
environment in which the software is developed (see below), there are often
quite active and technically adept online discussion groups, mailing lists, web
sites and ftp download areas for patches and updates.

One drawback to this model is that it is difficult for a vendor to provide
monolithic support for a rapidly diverging Open Source product as the user base
modifies their source code and rebuilds the system. Note that a recent survey of
vendors of an Open Source operating system (Linux) revealed that there are over
40 commercial variants of Linux. This can pose severe compatibility,
interoperability and support problems.

The Open Source Development Model
Open Source development teams are rapidly emerging as the dominant force behind
the continuing evolution of computing. Eric Raymond's paper, The Cathedral and
The Bazaar () details the philosophy, scope and social organization of this
model. "Release early and often, delegate everything you can, be open to
the point of promiscuity" is a development philosophy sharply in
contradistinction with the conservatively centralized approach of the
traditional development model in which large software projects were "built
like cathedrals, carefully crafted by individual wizards or small bands of mages
working in splendid isolation, with no beta to be released before its

SCO is attempting to synthesize these models - carefully protecting those
customers heavily invested in the stability, interoperability and compatibility
offered by the traditional approach while rapidly deploying emerging
technologies and methodologies offered by the bazaar.

Linux Emulation
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. Additional details on lxrun are available at .

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.

The Skunkware Submission Process
If you would like to contribute to the ongoing effort to provide quality Open
Source products to SCO customers:

Read the Skunkware FAQ at

Read the Skunkware submission guidelines at

Join the polecats mailing list by sending an e-mail message to with any subject line and a single line in
the body of the message: subscribe

Author and Contributors
Ronald Joe Record has worked for The Santa Cruz Operation for over 15 years.

Record holds a Ph.D. in Mathematics from the University of California.

David Eyes ( contributed to this document in design, review and
editorial matters.

About This Document
This document was created using SGML-Tools 1.0.6 in conjunction with TeX,
Version 3.14159 (Web2C 7.2) running on an SCO UnixWare 7 platform.

The source to this document is maintained at . A Makefile and formatted
varieties of this document are also available at . For instance, you will find a
postscript version at .

[ Reply to This | # ]

We need to make these reports legal (affidavit)?
Authored by: Anonymous on Friday, December 12 2003 @ 05:56 PM EST
How do we make these legal, does anyone know?

Do the parties to the reports and the subjects (former SCO programmers, etc)
need to sign something in front of a officer of some court somewhere or a
notary, etc?

Does anyone know?

Hmmm, Would this be called a open and publicly available affidavit

How is this done?

This type of open research and testimony should be a matter of legal record and
not just Groklaw reporting (and maybe once a legal document copies of the legal
docuemnts could be sent to Red Hat, IBM, SCO and the press)! Can this be taken
to the next step?



[ Reply to This | # ]

Minor errors...
Authored by: egan on Friday, December 12 2003 @ 06:20 PM EST
The letter mentioned in this paragraph is missing: "Here we see, in the
file header to smpboot.c, that Mr. Aivazian is credited with fixing a minor
problem called the "0.00 in /proc/uptime on SMP" bug. Here we see
the letter where he made his suggestion for dealing with the problem:"

I also spotted an instance of "the the" in this document.

[ Reply to This | # ]

OT - Can we (Groklaw) validate McBride's 2.2 million claim?
Authored by: Anonymous on Friday, December 12 2003 @ 06:26 PM EST

From News Forge I noticed the following:

"It's ludicrous that we even have to have this conversation," McBride said. "I mean, come on, we depend on our Web site for most of what we do -- downloading patches, providing all kinds of services. We get something like 400,000 hits per day on the site. We have 2.2 million servers (using our software) out there. Being down for two days was driving me crazy. We're not about to knock down our own site."

The "2.2 million servers (using our [SCO] software)" made me wonder if Gorklaw readers know how to check this claim? I thought that had such information, but I could not find it.

Given Mr. McBride's trackrecord regarding truth and his penchant for larger than credible numbers, could this just be another example of SCOflation?

agriffin (not logged in)

[ Reply to This | # ]

Tigran Aivazian Says His SMP Contributions to Linux Kernel While at SCO Were Approved by his Bos
Authored by: Anonymous on Friday, December 12 2003 @ 06:35 PM EST
I wonder if IBM has subpoenaed records from Tarantella f.k.a. The Santa Cruz
Operation about who contributed to what and when while they owned Unixware.

[ Reply to This | # ]

OT: So where is the SEC?
Authored by: Anonymous on Friday, December 12 2003 @ 06:53 PM EST
I'm wondering when the SEC will step in to investigate Darl McBride and
SCO. I know the wheels of justice move slow, but it really can't be any
more clear that SCO is in deep.

On a side note, I've been wishing I had the credit to short SCOX for some
time now. The move to compell results would have neted a good return.

[ Reply to This | # ]

Tigran Aivazian Says His SMP Contributions to Linux Kernel While at SCO Were Approved by his Bos
Authored by: Glenn on Friday, December 12 2003 @ 07:15 PM EST
SCOG's case has so many claims that it seems like a centipede. But one by
one. each of those legs are being pulled off while SCOG screams shrilly.
The press seems to be much like the people and the Emperor who had no clothes
on as he paraded through the town. And the OSS community, personified by
Groklaw, would seem to fit the character of the boy who called a spade a spade.
When the courts do finnaly render the verdict that the emperor indeed has no
clothes, I am wondering how some of those journalists who dutifully echoed the
SCOG ludicrous line are going to react. Methinks they will pull a SCOG and just
pretend that they never were reeled in so easily.


[ Reply to This | # ]

Tigran Aivazian Says His SMP Contributions to Linux Kernel While at SCO Were Approved by his Bos
Authored by: Anonymous on Friday, December 12 2003 @ 08:10 PM EST
This is a great article, but there are some points I fail to see mentioned.
From the perspective of wanting SCO to lose, all looks well. However, Tigran
simply making contributions does not an endorsement of old SCO make. From what
I can tell, he was making contributions during his private time with private
resources. I get the impression he simply asked his management if it were a
conflict of interest for him to contribute to the Linux kernel. In no way did I
see that old SCO tasked him with Linux development as part of his duties. His
contributions were not made by old SCO, but simply by an individual with a e-mail address. Was old SCO even aware that his contributions were in
areas he was familar with the UnixWare code and implementations? If not, does
this taint some of his contributions as not being clean room implemented? Even
if they are completely different, access to that code and methods could have
aided him considerably in knowing what path not to follow. Whilst this news
could definitely bennefit IBM in this case, it doesn't necessarily help the OSS
community. I think we need to know more about the nature under which old SCO
gave Tigran their blessings.

[ Reply to This | # ]

Tigran Aivazian Says His SMP Contributions to Linux Kernel While at SCO Were Approved by his Boss
Authored by: Anonymous on Friday, December 12 2003 @ 08:32 PM EST
Wow !
That's about what I thought except it's a whole lot more.
Thank you Tigran Aivazian.
PJ finds everything, it's a little scarey but I'm not complaining (I do not
doubt PJ's ethics).
Does SCO roast go good with mustard ?

[ Reply to This | # ]

Tigran Aivazian Says His SMP Contributions to Linux Kernel While at SCO Were Approved by his Boss
Authored by: Anonymous on Friday, December 12 2003 @ 08:33 PM EST
As Master Yoda would say,

"mmm much trouble I see do, for the darkside is all around us"

several issues with is article:

1. Mr Aivazian really only has *his* word. Does he have in writing the written
consent of his supervisor Wendy, or her superior management at the then Caldera?
I doubt not...without written evidence his word in a court of law is severely
limited. I'll argue this on these subpoints:

a. Microsoft and Sun both have their fingers in this IP pie that SCO have
wrought. Who does Wendy work for now? Sun did I hear you say? Wow. People do
have employers put *pressure* on them. People do *successfully lie* in court
for financial gain at the direct instruction of an employer. It *does* happen.
We don't live in a perfect world where everyone goes 'wow, i'm in court, I
*must* tell the perfect truth'. I'm not saying that Wendy *will* lie in
court, but I wasn't born yesterday either. What people *must* remember is that
both Sun and Microsoft have proprietary code, and both have been anti Linux in
the past (well Microsoft still is...). Businesses only want *their* business
model to succeed and will generally try to kill anything else that competes.
That's the nature of human greed and business in general.

b. Even *if* mid management knew about it and approved it in writing, upper
management may *not* have known about it. There's a thing called
misappropriation. SCO could claim that - and could also claim Mr Aivazian as a
rogue coder, as well as his supervisor as a rogue. I know i'd argue that point
in SCOs case.

c. SCO could argue that there was a conflict of interest in Mr Aivazian working
on Linux and also Unix. Remember Linux is similar to Unix in may ways. Most
employer contracts have very *tight* contracts like this. Said contracts
usually have watertight ownership provisions of anything that said employee
creates (even on his own machines, own time and own premises). Period. There
is a case at the moment of some Apple developer developing software on his own
machine, time and place for himself and now Apple are claiming ownership and
have also terminated his employement contract for breach. This is not an
uncommon thing in the IT industry. This type of contract *must* be made illegal
by governments, as it does not allow the individual any freedom. Unfortunately
since most large corporations *own* politicians...

d. SCO could argue that if Linux scalability is better than Unix, and Mr
Aivazian was working so hard on Linux in his own time and doing such a good job,
why wasn't he working on Unix scalability improvements to the same degree of

Obviously - if what i'm reading is the issue, then SCO have no issue with IBM
for smp, but should be taking action against Mr Aivazian and his supervisor
Wendy Dean. Quite simple really. And if successfully argued, then all the work
that Mr Aivazian did for the open source is deemed owned by Caldera, and
illegally placed into Linux via his employment contract (which i'd like to
peruse). There goes most of Linux' smp ability. Of course improvements to
Linux derived from anything Mr Aivazian submitted is also deemed a derivative
work. mmm. That would cripple Linux.

If SCO is able to successfully argue that parts of RCU, numa and jfs are Unix
derivatives that will also kill the rest of the Linux enterprise ability.
Businesses will drop Linux and resume Unix license purchases.

I really hope i'm wrong, but...


PS No - i'm not a troll, i'm just trying to think laterally and not be
blinkered by my emotions.

[ Reply to This | # ]

Don't forget Lineo
Authored by: Anonymous on Friday, December 12 2003 @ 08:41 PM EST
Their CEO and CTO, in public meetings such as trade shows, spoke about
"donating" SMP boards to Allen while they were Caldera / Caldera
Thin Clients ("sister" companies). CTC later became
"Lineo" in mid 1999.

Lineo execs claimed to contribute to the Linux Trace Toolkit project - important
for performance measurement, debugging, etc. Not sure if was in the form of
money or code, but if I recall correctly they were a bit vague about exactly
*what* they gave.

Lineo shipped LTT with some of their BSP tools. Those BSPs were under GPL, and
were available at their website, free.

They also had a "Reflective Memory" system which might have
similarity to RCU, and almost certainly NUMA. However, I do not know the
license used.

Lineo also offered a separate Kernel Debugger ("R2D2") created by
Zentropix. They (Zentropix) were bought by Lineo, WITH knowledge of Canopy and
Caldera and with great public fanfare in the press. In fact, that went farther
than just Zentropix.

The purchase of a number of Linux companies (Zentropix, USE (Japan), Inup
(France), RT Control (Toronto), Fireplug (Vancouver), Moreton-Bay (Melbourne),
and maybe others, were, according to their CEO in at least one public
presentation, done *at the direction* of the board of directors, INCLUDING
Canopy execs. The Lineo CTO (I think) referred to that on a few occasions,
something about a "Oklahoma land grab" or words to that effect.
These (code, company acquisitions, etc) were also discussed in the press (by
Marketing people such as Lyle Ball - on the cover of Linux Journal (?), at
public meetings like Embedded Systems Conference and others.

Lineo was very aware of GPL - so was Canopy. For example, their GPL Compliance
Toolkit was used to determine if there were potential GPL violations in a code
set by looking at various "signatures" in the code, as well as file
#include links, etc. Lineo offered the GPL Compliance Toolkit **WITH** GPL
indemnification. Again, this was discussed at various public meetings. I do
not know if they ever sold a copy, but it was certainly offered, with up to $10
million (IIRC) in indemnification for legal fees, etc. Any such plan would, I
think, have REQUIRED approval of the board - and that includes Yarro and his
team at Canopy.

Canopy sold Lineo - and the deal was completed just weeks before the Caldera
lawsuit (this "SCO" one, not the DRDOS one), in early 2003. There
doesn't seem to be any way that Canopy, and especially Yarro, could have not
known about the pending suit, given recent SEC filing information.

There were two Lineo CEOs at least: Bryan Sparks was (and might still be) a
Canopy board member. Matt Harris, an attorney, often spoke of working with FSF,
and he (with the CTO) would have helped review the GPL Compliance Toolkit.
He's now with Metrowerks (which purchased Lineo).

In other words, it seems such things went all the way to the very top. That
includes links into the Canopy boardroom.

I doubt it would take very much digging to find out if Ralph Yarro or other
board members at one or more of those public meetings if that matters, but the
board connection through Lineo and Caldera execs cannot be ignored either.

Tigran's notes show that engineering management also knew of such things at
Caldera. This had to be the case at Lineo. They ran or contributed to open
source projects, and some of their people spoke about having open source servers
in their cubicles (with "holes" in the firewall, which would require
IT help). I think the BusyBox guys may be an example, but there were others
too. And you could link to things like LTT from those

So, there goes any claim of "inadvertent" release. We see execs,
CTOs, CEOs, attorneys, Marketing, Sales, engineering and engineering management,
board members, IT workers - all of them knew about these things, and some of
them from multiple angles (for example, Alan Smart worked at Caldera, Lineo, and
Canopy). There was no apparent difference at Caldera or other Canopy Linux
companies. For example, you could download free versions of Linux at Caldera
sites, and other code such as the TrollTech Qt libraries, at others.

Anybody have notes or copies of keynote presentations from Embedded Systems
Conferences, or from trade magazines, Linux Journal etc.? If you keep back
issues, it could be very interesting to piece those together, starting in mid
1999 (just before Caldera Thin Clients renamed to Lineo). Or, just to look for
Caldera and SCO ads, articles, etc.

[ Reply to This | # ]

    SCO said they are in two shoes!
    Authored by: Anonymous on Friday, December 12 2003 @ 11:25 PM EST
    Now it makes sense all the sudden. Kevin said, SCO would be in two different
    shoes here: the UNIX licensor and also a UNIX lincensee. Some employees of this
    UNIX licensee contributed GPL code in violation of their UNIX contract. They
    would have already sued themselves, but ... well, that wouldn't make too much
    sense now, would it? But they can still go after other UNIX licensee who
    violated their contract. With a split personality, you can have the pie AND eat
    it, too.

    [ Reply to This | # ]

    Tigran Aivazian Says His SMP Contributions to Linux Kernel While at SCO Were Approved by his Bos
    Authored by: jog on Saturday, December 13 2003 @ 12:27 AM EST
    Didn't IBM ask for this information in discovery;
    perhaps in order to avoid having to depose or call


    [ Reply to This | # ]

    Tigran Aivazian Says His SMP Contributions to Linux Kernel While at SCO Were Approved by his Bos
    Authored by: MyPersonalOpinio on Saturday, December 13 2003 @ 02:22 AM EST

    Very well written article and very good research from the point of view of digging for the truth.

    Looking at some of the reactions however, I can only hope this does not become a weapon of confusion on SCOX's hands, where IBM ends up subpoenaing all the the way up to Ransom Love (and Ray Noorda?)...

    [ Reply to This | # ]

    Tigran Aivazian Says His SMP Contributions to Linux Kernel While at SCO Were Approved by his Boss
    Authored by: iZm on Saturday, December 13 2003 @ 03:13 AM EST

    This link does not work:

    On January 4th of 2000, Aivazian talks about code that might be

    Stupidity, like virtue, is its own reward.

    [ Reply to This | # ]

    Tigran Aivazian Says His SMP Contributions to Linux Kernel While at SCO Were Approved by his Boss
    Authored by: Anonymous on Saturday, December 13 2003 @ 05:05 AM EST
    My comments were suggestions, nothing more. I'm not vindicating SCO, far, far,
    far from it. Personally I want to see SCO go down like everyone else, i'm just
    sus that SCO will be low enough to have a go at its employees (past and

    Mr Aivazian didn't do numa, rcu or jfs etc. They are separate items to smp and
    enterprise ability. And personally, I believe him. But, what I believe, and
    what SCO and/or courts believe are different things. If you don't have
    something in writing, then generally you're in trouble. That's why people
    have contracts.

    That said, I don't think SCO really has ANY case :-)


    [ Reply to This | # ]

    Who owns work done on one's own time?
    Authored by: technoCon on Saturday, December 13 2003 @ 01:39 PM EST
    I've worked as an engineer for a couple decades. One feature of almost every
    job was an employment agreement assigning ownership of any invention I might
    create to the company, even if I did so on my own time.

    Mr. Tigran Aivazian has said that he contributed software to the Linux kernel
    with the approval of management. SCO might still argue that Mr. Aivazian's
    contributions were done "on his own time."

    If Mr. Aivazian was bound by such an agreement, software created on his own time
    would belong to SCO. Thus giving permission to Mr. Aivazian amounted to a
    release of SCO property under the GPL?

    I'm curious about the interplay between employment agreement and line of
    reasoning described above.

    smiles and cheers,


    [ Reply to This | # ]

    Some (minor) corrections
    Authored by: vonbrand on Saturday, December 13 2003 @ 07:43 PM EST
    - gdb is the GNU Debugger, not the "gcc debugger". After finding a
    problem, the standard tools can be used to fix it (not "gcc").

    - The kdb stuff is impòrtant, but the fact that Linus doesn't like
    debuggers (that is why there is none in the kernel!) shows that the need for
    "expensive equipment" is nonsense. Well, that is unless you consider
    a lot of highly trained and motivated hackers "equipment"...

    [ Reply to This | # ]

    Under NDAs? Tigran Aivazian et al?
    Authored by: Anonymous on Sunday, December 14 2003 @ 02:06 AM EST
    Just a question:
    Does anyone know if Tigran (or any of the other ex-SCO employees that have come forward) are putting themselves at risk talking about the work they did while at Caldera/SCO? Could they be covered by some type of end-of-employment Non-Disclosure Agreement that could get them in trouble?

    I'm not trying to stifle the party, I'm just Curious.

    [ Reply to This | # ]

    Approval and employee GPL contributions
    Authored by: Anonymous on Sunday, December 14 2003 @ 05:23 AM EST
    Don't get me wrong this lawsuit is a crock of s**t but...

    I find the statement "Tigran Aivazian Says His SMP Contributions to Linux
    Kernel While at SCO Were Approved by his Boss" an interested albeit
    slightly disingenuous statement.

    In short AFAIK old SCO had no problems with employees contributing their own
    work to GPL projects including the Linux kernel. There was no license to
    integrate SCO IP into GPL projects.

    Additionally SMP was certainly a major area of interest for SCO and a major
    rationale for the decision to take UnixWare above SCO's own more successful OS
    offering OpenServer when USL was acquired from Novell.

    It is not too much of a surprise that this would also be an area of technical
    interest to engineers at SCO such as Tigran and that if he also a Linux hobbyist
    then this would be a natural area to apply some knowledge. For many software
    engineers - software is both their work and their hobby.

    What makes me uncomfortable though is the implication of "approval".
    Tigran sought and received approval for two specific features, BFS and the
    microcode update.

    However it appears to be implied here that Tigran had tacit approval for
    "all" his subsequent contributions especially relating to SMP. There
    is no evidence for this. Unless Tigran is stating that SCO initiated a specific
    program for engineering SCO IP in to Linux then essentially this doesn't really
    have any bearing on the Scaldera's lawsuit(s).

    There is an ugly side to this implication as well. Should any corporate employee
    who has previously worked on GPL software be stopped to prevent contamination of
    the corporations IP claims? I hope not. It seems at the time SCO did a 'nice'
    thing. It gave permission to an employee to put 2 pieces of functionality in to
    the Linux kernel analogous to functionality available in UnixWare.

    SCO did not waive its IP rights by letting its employees in their own time
    contribute to GPL projects. That a SCO employee who was a Linux hobbyist could
    be interested and apply insight into SMP features is unsurprising but would not
    be a problem unless there is specific evidence of introduction of SCO IP.

    [ Reply to This | # ]

    Tigran Aivazian Says His SMP Contributions to Linux Kernel While at SCO Were Approved by his Boss
    Authored by: Anonymous on Sunday, December 14 2003 @ 05:54 PM EST
    Hey Guys, lets raise some money to buy the UNIX code when
    SCO goes bankrupt!

    I think for the article above we owe you some bucks!

    "Mr. Hawking, do you think there is intelligent life in
    this universe besides on earth? SH: I wonder
    whether there is intelligent life on earth!"

    [ Reply to This | # ]

    Tigran Aivazian Says His SMP Contributions to Linux Kernel While at SCO Were Approved by his Boss
    Authored by: Anonymous on Monday, December 15 2003 @ 01:53 PM EST
    In case anyone cares.

    Lake Stevens Instrument Division was a division of Hewlett-Packard until the
    HP/Agilent split. It is now a piece of Agilent Technologies.

    [ Reply to This | # ]

    Groklaw © Copyright 2003-2013 Pamela Jones.
    All trademarks and copyrights on this page are owned by their respective owners.
    Comments are owned by the individual posters.

    PJ's articles are licensed under a Creative Commons License. ( Details )