Update June 17, 2006: The link to the LUG report with the photos is broken now. Try this on the Internet Archive. And happily there is a mirror here.

1. Definitions and explanations on Findlaw here and here and elsewhere here and here and here on Gigalaw.

2. Utah is one of the states that has passed the Uniform Trade Secrets Act.

Utah's version, Utah Code Ann.Section 13-24-1 et seq. is here. (Another resource for case law is Lexis' free case law search tool here, then choose Utah, then state law, and type in search terms "trade secrets". You can do a Federal search there too.) Here are its "Definitions" because the link works sometimes and then not other times:

13-24-2. Definitions.

As used in this chapter, unless the context requires otherwise:

(1) "Improper means" includes theft, bribery, misrepresentation, breach or inducement of a breach of a duty to maintain secrecy, or espionage through electronic or other means.
(2) "Misappropriation" means:
(a) acquisition of a trade secret of another by a person who knows or has reason to know that the trade secret was acquired by improper means; or
(b) disclosure or use of a trade secret of another without express or implied consent by a person who:
(i) used improper means to acquire knowledge of the trade secret; or
(ii) at the time of disclosure or use, knew or had reason to know that his knowledge of the trade secret was:
(A) derived from or through a person who had utilized improper means to acquire it;
(B) acquired under circumstances giving rise to a duty to maintain its secrecy or limit its use; or
(C) derived from or through a person who owed a duty to the person seeking relief to maintain its secrecy or limit its use; or
(iii) before a material change of his position, knew or had reason to know that it was a trade secret and that knowledge of it had been acquired by accident or mistake.
(3) "Person" means a natural person, corporation, business trust, estate, trust, partnership, association, joint venture, government, governmental subdivision or agency, or any other legal or commercial entity.
(4) "Trade secret" means information, including a formula, pattern, compilation, program, device, method, technique, or process, that:
(a) derives independent economic value, actual or potential, from not being generally known to, and not being readily ascertainable by proper means by, other persons who can obtain economic value from its disclosure or use; and
(b) is the subject of efforts that are reasonable under the circumstances to maintain its secrecy.

4. Miscellaneous resources on software trade secrets and the SCO case in particular and cutting edge issues.

5. Case law here.

Happy hunting.

A comment was posted:

"You might want to reexamine the opinion of Dickinson R. Debevoise http://cm.bell-labs.com/cm/cs/who/dmr/bsdi/930303.ruling.txt

"From the BSDI-USL lawsuit http://cm.bell-labs.com/cm/cs/who/dmr/bsdi/bsdisuit.html"

I did. It was helpful input. If the import of the suggestion was that it would be meaningful to the present situation, I have to disagree in part and agree in part. First the differences I see.

Specifically, Sontag believes the "SCO technologies" which were misappropriated into AIX, IRIX, and the derivative UNIX-alikes (including Linux) are:

JFS ( Journalling File System). -- This is unbelievable. Did Sontag really say that? To this day SCO doesn't have code of that name. JFS was developed by IBM. To judge by the header files, it appears to base heavily on the Berkeley (BSD) Fast File System.

NUMA (Non Uniform Memory Access), a SGI/Stanford collaboration. -- They don't even claim to have anything to do with this one. That's a good thing, too: NUMA is very much a hardware issue. SCO doesn't do hardware.

RCU (Read-Copy-Update ). -- This is an algorithm. There's nothing in here which required, or could even benefit, access to the source code of an implementation in a differently structured system.

SMP (Symmetrical Multi-Processing). -- SMP predates UNIX. SCO was a latecomer in implementing SMP, and as far as I can tell none of its license holders use the SCO version: they all have their own implementations, all of which are superior to the SCO implementation. The link shows Linux's implementation, which was initially very much a primitive "Giant Kernel Lock" implementation that has been around for decades, Later versions of the Linux SMP implementation differ strongly from any UNIX implementation.

Having worked on Linux for IBM, I can state categorically that the separation between AIX and Linux is complete. Nearly all of the people working on the Linux kernel have no access to AIX source code. It's theoretically possible that some people do have such access, though I know of nobody, but IBM has guidelines for that case, just to be on the safe side: don't read AIX code and write Linux code in the same place. Read the code, go elsewhere and write. Even this, though, would hardly be useful: AIX is UNIX, Linux is Linux. The kernels have such completely different structures that any code import would be a waste of time: it's easier to write it from scratch.

SCO's talk about SMP scalability is nonsense. They don't have any useful technology in that area. Linux scaled better than UNIX System V long before IBM came on the scene. It's true that IBM is doing a lot of work in that area, but it's based on the PowerPC architecture, and SCO's version of System V doesn't support that platform. So what use would the code be, even if it were a drop-in replacement on the i386 platform?

"According to some of those who have had a look at the offending code, it DID come from IBM after all.  There are reportedly many lines of identical code, and at least some of the Linux code even carries an IBM copyright notice.  Well, this is a surprise to me and a delight at SCO headquarters in Utah, I'm sure, but I'll bet my house that SCO does not prevail and here's why....a case of a single person who did two very similar implementations based on his earlier research.  Both his UNIX and Linux versions (works B and C) were derived from his original research (work A) which was not exclusively limited to UNIX.  His paper shows that was the case and while SCO may see it as the smoking gun, IBM will see it as the proof of innocence.

"What SCO owns (forgetting for the moment Novell's contrary ownership claim and perhaps AT&T's) is the copyright on this particular work as applied to UNIX.  But Linux is not UNIX, so applying the same ideas -- even the same code if it comes originally from an upstream source -- is not necessarily copyright infringement. 

"Say I write a new high-level programming language, then do nearly identical implementations of that language for UNIX and Linux and the UNIX version is made part of some official UNIX distribution.  Does that mean the Linux version violates the UNIX copyright?  No.  But I wrote both versions and the code is identical.  Surely that is a copyright violation?  No.  This isn't a matter of clean rooms and virgins and reverse engineering, it is a matter of precedence and authorship.  Sequent (now IBM) did not give up all its rights to the code when it was made part of UNIX.  They were very careful to plan it that way."

There is one part of this story that has me puzzled, although I'm happy he thinks SCO will lose. The puzzle is, how can it be an offense for IBM to donate code to Linux that IBM has a copyright on Maybe I am missing something. On the other hand, Cringley reports a conversation with DiDio in th same article.

SCO is suing principally over derivative code, they say. As Mark Heise, one of their attorneys said, "Through contributing AIX source code to Linux and using UNIX methods to accelerate and improve Linux as a free operating system, with the resulting destruction of UNIX, IBM has clearly demonstrated its misuse of UNIX source code and has violated the terms of its contract with SCO."

Let's leave out of this discussion whether IBM did or didn't do what SCO claims. We can't know that yet anyway. Let's just talk about derivative code and what a SCO victory would mean, if their expansive definition of derivative code is accepted. They appear to be saying that derivative code should also mean code written using ideas or methods others before you thought up, even if you write everything from scratch. This is nothing less than saying real innovation in software must stop this exact minute.

I'm not a programmer, but derivative code as I understand it normally could be defined as taking a program and using the code to make something new, or adding to it. The original code is in the finished product, at least to some extent, along with the addition. In a non-software analogy, it's kind of like Disney taking the work of the Brothers Grimm and using the story to make a movie that is taken from the book but is also a lot different. The main characters are the same; the general plot is the same; the tone and many of the elements and features may be the same, prince, dance, lost slipper, pumpkin coach, nasty stepsisters, etc. But there are unique new features that only the movie has, like a musical score, for example, visual cartoon characters, mice and birds that not only sing but can sew a ball gown, and the wicked stepsisters don't have their eyes pecked out by birds in the movie (the Brothers Grimm were... um..a tad grim).

There is no doubt that Disney started with and used ideas that the Brothers Grimm invented. Disney could have invented a brand new story, with all new characters, after all. But he had a creative idea after reading Cinderella and saw a way to do something new with this old story, and the result was a cultural enhancement that has become part of every American childhood. And we still have the book too, even in electronic form.

For many years, Disney was just raking in the dough and the mind share too. How many kids today know about the original story compared with the movie? If they read Cinderella, it's most likely a book version of the movie, with illustrations from the movie, and with an ad for renting the DVD, not the Brothers Grimm.

What are the Brothers Grimm to do? Well, they're long dead and gone, but their great-great-grandkids start thinking about this. They're low on money, and while they could write some stories of their own and make money that way, they don't really want to work and didn't think they'd be successful anyway, so they decide to bring Disney to court and force him to pay them for using their family's great ideas, their valuable IP, the family jewels.

After all, without the original story by their great-great-grandfathers, there could have been no Cinderella movies, no Cinderella dolls, no songs, no games, no lunch boxes, no kiddie makeup kits with mirrors with pictures of Cinderella on the back, no Cinderella-at-the ball costumes, no comic books, no little girl fantasies as part of the culture of growing up female in America. Just think of all the money the Family Grimm, heirs to this valuable IP, could be receiving, when as it is, they are almost broke.

This is, in essence, SCO's argument. They should be paid for some old code virtually no one wants any more, because others wrote, from scratch, something new and more appealing, using an idea that came to them in part as a leaping off point from their work. We're not talking now about stealing software code. SCO wants to own inspiration too.

Wait, you say: Disney was allowed to use the Cinderella story, because it was in the public domain.

Yes, and are you sorry Disney was able to creatively build on the original?

What SCO does not comprehend apparently is that Linux is beating UNIX at everything precisely because it is open and because everyone can build on everyone else's ideas. The GPL guarantees it. Innovation in software thrives in expansive, low-barrier-to-entry environments where talent is free to be expressed and ideas can build on the ideas and work of others. While no one is compelled to use the open source method or licenses, what is the result when one does?

It's too idealistic, you say? Businesses have to be practical? Linux needs to "mature", as SCO's McBride has stated as his justification for the lawsuit? But which kind of development has resulted in the best software, proprietary or open?

We don't have to imagine anything. Let's look at the three basic models of how derivative code is handled, proprietary, BSD, and GPL. And let's see which has resulted in the best software.

Proprietary code by definition requires a cabal of insiders to create it and maintain it. No trespassing. Outsiders keep out. To get in to use it, you must pay and it's use but don't look. There is no getting out. Derivative code must come back to the original owner. Under Microsoft's new Shared Source Initiative, for example, they show selected ones some of their code, but if any derivative works are created, the derivative code must be returned to them, and they do not pay the programmers who extended their code for them and are free to use the derivative code themselves for their own profit. If you were a programmer, would that inspire you to do your best work under that arrangement? You might do it for money, but for the sheer fun of it? The creative joy?

Then there is BSD. It places absolutely no conditions on derivative works, which may turn out to be of interest if the allegedly stolen code and methods turn out to be BSD code. But in this part of the software world, you can take BSD code, create a derivative work, then release it with the BSD base as your proprietary program. This is, of course, why Microsoft et al like this license better than the GPL. They can take the hard work of other people and with very little effort themselves, make mucho dinero or just take it and then keep others out by extending it just a bit so it doesn't interoperate with outsiders.

Then there is the GPL. Here, derivative code must also be released under the GPL, meaning all the rights you have from the code you got must flow through into your code for the benefit of the next user/programmer. There is, naturally, a lower financial incentive to writing this kind of code, so we'd expect this license to attract only a few hopeless idealists, who couldn't be expected to create anything useful, particularly for the enterprise, as businesses like to call themselves.

If we are thinking like SCO, we would expect that the best code would come from the proprietary model, then BSD, then GPL. However, because we can look back instead of imagining forward, we know the exact opposite has happened. Proprietary has produced the least innovation. Think Windows 95 to 98 to NT to 2000 to XP. You've seen one, you've seen them all. A tweak here, a tweak there.

BSD has resulted in forked code. It's obvious why: you can make a profit from peeling off and selling your own product. Cooperation is not encouraged by the license, if only because not everyone wants to work hard and then watch helplessly while some company takes their labor and then fences it off where others can't use it, can't even interact with it because of proprietary add-on "features". Companies like it, though, so it doesn't die, but it hasn't traditionally attracted the numbers that GNU/Linux has.

Then there is the GPL. Why, oh why, do people write GPL code, when there is absolutely nothing in it financially for most of them? Stallman says, for freedom and to encourage a community. Linus says, for fun. And why is it fun? Because creativity is fun. Interacting creatively with other people's brains is exhilarating, and the more the merrier. And what has been the result? The creative explosion that is making proprietary software companies worry they will soon be obsolete. In Halloween I, the leaked Microsoft memo, it described open source software like this:

Open Source Software (OSS) poses a direct, short-term revenue and platform threat to Microsoft -- particularly in server space. Additionally, the intrinsic parallelism and free idea exchange in OSS has benefits that are not replicable with our current licensing model....Commercial software is classic Microsoft bread- and-butter. It must be purchased, may NOT be redistributed, and is typically only available as binaries to end users.....Open Source (BSD-style) -- A small, closed team of developers develops BSD-stye open source products & allows free use and distribution of binaries and code. While users are allowed to modify the code, the development team does NOT typically take 'check-ins' from the public.... Open Source (CopyLeft, Linux style) -- CopyLeft of GPL (General Public License) based software takes the Open Source license one critical step farther. Whereas BSD and Apache style software permits users to 'fork' the codebase and apply their own license terms to their modified code (e.g. make it commercial), the GPL license requires that all derivative works in turn must also be GPL code.

Now, that's not a perfect description of GPL, because it implies you can't make any money from GPL software, whereas Red Hat just announced a profitable last quarter. (And they didn't do it by suing anybody either.) But it captures the essence of my point here. And which does Microsoft, the former poster child for proprietary code see as superior, as far as software is concerned? (I say former, for SCO has unquestionably moved ahead in the rankings in this last month.) Here's what the memo revealed:

Recent case studies (the Internet) provide very dramatic evidence... that commercial quality can be achieved/exceeded by OSS projects. Linux and other OSS advocates are making a progressively more credible argument that OSS software is at least as robust -- if not more -- than commercial alternatives...The ability of the OSS process to collect and harness the collective IQ of thousands of individuals across the Internet is simply amazing.

It's not so amazing if you just stop thinking about money for one little second and think about good software. If you do, you have to know that sailing your own boat with some friends is greatly superior to being a galley slave forced to row in whatever direction someone over you directs. And Microsoft knows it. I'm sure SCO knows it too, because they realize and even say that Linux is ruining their business. The part they got wrong is the why of it: they allege it is all IBM's doing, whereas in fact excellence is just built in to the open process.