decoration decoration
Stories

GROKLAW
When you want to know more...
decoration
For layout only
Home
Archives
Site Map
Search
About Groklaw
Awards
Legal Research
Timelines
ApplevSamsung
ApplevSamsung p.2
ArchiveExplorer
Autozone
Bilski
Cases
Cast: Lawyers
Comes v. MS
Contracts/Documents
Courts
DRM
Gordon v MS
GPL
Grokdoc
HTML How To
IPI v RH
IV v. Google
Legal Docs
Lodsys
MS Litigations
MSvB&N
News Picks
Novell v. MS
Novell-MS Deal
ODF/OOXML
OOXML Appeals
OraclevGoogle
Patents
ProjectMonterey
Psystar
Quote Database
Red Hat v SCO
Salus Book
SCEA v Hotz
SCO Appeals
SCO Bankruptcy
SCO Financials
SCO Overview
SCO v IBM
SCO v Novell
SCO:Soup2Nuts
SCOsource
Sean Daly
Software Patents
Switch to Linux
Transcripts
Unix Books
Your contributions keep Groklaw going.
To donate to Groklaw 2.0:

Groklaw Gear

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


Contact PJ

Click here to email PJ. You won't find me on Facebook Donate Paypal


User Functions

Username:

Password:

Don't have an account yet? Sign up as a New User

No Legal Advice

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

Here's Groklaw's comments policy.


What's New

STORIES
No new stories

COMMENTS last 48 hrs
No new comments


Sponsors

Hosting:
hosted by ibiblio

On servers donated to ibiblio by AMD.

Webmaster
Trade Libel
Sunday, June 22 2003 @ 08:33 PM EDT

What it is:

"1. Definition of Trade Libel
"Trade libel is the intentional disparagement of the quality of property. "Unlike classic defamation, [the defamatory statements] are not directed at the plaintiff[base ']s personal reputation, but rather at the goods a plaintiff sells or the character of his or her business, as such." Guess v. Superior Court , 176 Cal.App.3d 473, 479 (1985). The disparagement must result in pecuniary damage to the plaintiff. The disparagement may be in the form of a false statement of fact or opinion. (see 5 Witkin Sum. Cal. Law Torts 573, citing Rest.2d, Torts 626)."

Law against it (states may have their own in addition):

The Lanham Act makes it illegal:

"Any person who ... in connection with any goods or services ... uses in commerce any ... false or misleading description of fact, which ... in commercial advertising or promotion, misrepresents the nature, characteristics, or qualities ... of his or her or another person's goods, services or commercial activities ... shall be liable in a civil action by any person who believes that he or she is likely to be damaged by such act."

A few more resources.

Relief you can request would include an injunction to stop whatever disparagement is occuring, very much what the folks in Germany got.

SCO Protest and Anti-Protest
Sunday, June 22 2003 @ 08:09 PM EDT

There was a protest against SCO in Utah on Friday by Linux groups there, who look like a mighty pleasant and creative group of clean-cut folks, as reported on Slashdot and local papers. You can look at pictures of the protest here. You can watch a video of the protest here.

Protesters allege that SCO sent out employees and signs that said terrible things such as "I love software piracy" and "Give Communism a Try" and that they tried to pretend they were part of the protest. If this is true, first of all shame on SCO and second, they are maybe not realizing that trade libel is actionable, and Linux is trademarked.

Here is a picture of the SCO security guard walking past some signs propped up against the wall of the SCO building near a door in which you can see the "I love software piracy sign".

Compare it with these shots one protester took of the signs.

Here is a picture of one group of protesters. Do they look like pirates or commies to you? Or just a nice family that loves Linux enough to join in a show of support for their favorite operating system?



Here is the "I love software piracy sign up close. If you look through the pictures of the protest, here and there you will see the sign, always in the back, always with the face of the person holding it not visible.

Eyewitness Confirms Nasty Signs Came From Inside SCO Building

I have just confirmed in an email interview with a member of the Utah protest group that the nasty signs about piracy and communism seen at the protest against SCO were not brought or carried by anyone in their group. Here is what the email says happened:

"First, I was the first protester there, as we had everybody meet at two other locations, I was there to catch anybody coming early. As soon as the crowd started driving in at 3, this group of people came out of the sco building with their posters. ...After milling around, they planted their posters at the sco entrance (which we were not allowed to approach), went back in the building, then afterwards, to their cars in the sco lot and left."

What kind of smear campaign is this? To paint Linux users as pirates and worse? "Terrorists use Linux" and "communists like Linux", etc.? It's truly defamatory.

The truth is that what happened in Utah on Friday demonstrates questionable ethics not among Linux users but at SCO headquarters. Whose idea was it, I wonder, and will there be an apology? Thanks to the internet, the story is out, and the proof is available for one and all to see. Personally, I am shocked and offended.

I also hope everyone takes a look at all the photographs of the event, because the people that showed up for this event look so appealing and clean-cut and good-natured and pleasant even in their protest that all you have to do is look at them and then at the horrible, libelous signs to know who is on the dark side. Take a look at the photo of the security guard's face as he sculks past the signs and then look at the faces of the protesters and ask yourself: who do you trust? If SCO would do something this dishonest and underhanded, can we trust what they are saying about the code and where it came from? Which reminds me. One of the protesters wore a black tee shirt that said: "Open Source. It's the difference between trust and antitrust."

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.


Let's Hit the Books
Sunday, June 22 2003 @ 06:37 PM EDT

I have seen several websites offering legal analysis of the SCO case that are based on what I would call "How I Think the Law Ought To Be". Such arguments, moral or ethical arguments, although of value for other purposes, will have no influence on a judge, because that isn't his job. That's for the legislature. His job is to interpret what the law currently is. I apologize I have no time today to put this in any logical order.

So to help you think the way the judge will be thinking, so you can think of something or notice something that could prove helpful, here are some legal resources explaining how the law is currently.

read more (211 words)   View Printable Version
Post a comment

What's a Trade Secret?
Saturday, June 21 2003 @ 09:57 PM EDT

For those who would like to understand this claim better, here are some resources to get you going:

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.


The BSDI Case -- Exhibits, Exhibits, Exhibits Until My Eyes Water
Saturday, June 21 2003 @ 08:58 AM EDT

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.


read more (2036 words) 2 comments  View Printable Version
Most Recent Post: 06/24 01:31PM by Anonymous

Well, He Should Know.
Friday, June 20 2003 @ 07:27 PM EDT

For analysis of the Byte interview with Chris Sontag of a few days ago by Greg Lehey,who is a FreeBSD guy and who worked in IBM's Linux Technology Center, writing "a clone of the AIX Journalled File System, the predecessor of the JFS ported by the JFS for Linux project," go here:
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.

And on his blog, he says IBM carefully kept AIX and Linux coders separate:
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?


Why Cringley Says SCO Will Lose
Friday, June 20 2003 @ 12:44 PM EDT

He says they will lose because it now appears, the common code was each written by the same person, based on his own earlier research:

"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.


On Disney and Derivative Code
Friday, June 20 2003 @ 11:53 AM EDT

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.


1 comments  View Printable Version
Most Recent Post: 06/20 12:23PM by Anonymous

Some Caldera Contracts Are Online
Thursday, June 19 2003 @ 09:45 PM EDT

I went looking for any contracts online that might have derivative code clauses. This model corporate contract on Findlaw defines "derivative code" simply by copyright law:

""Derivative Works" shall have the meaning set forth in the United States Copyright Act, 17 U.S.C. Section 101, et seq." That would seem a normal definition.

Then I fell on this: Findlaw lists a number of older Caldera contracts on this page, dating from 1999 to 2000.

This contract, between SCO and Caldera in 2000, is interesting for the following clauses on the contract's pages 32 and 33, Clause 2.15 "Intellectual Property":

"(e) To SCO's Knowledge, no third party is infringing or misappropriating any of the SCO IP Rights....(g) The Contributing Companies and the Contributed Company Group have taken reasonable and practicable steps designed to safeguard and maintain the secrecy and confidentiality of, and its proprietary rights in, all material trade secrets or other confidential information constituting SCO IP Rights....To SCO's Knowledge, all development employees of the SCO IP Rights, and all other officers, employees and consultants of the Contributed Company Group have executed and delivered an agreement regarding the protection of proprietary information and the assignment to his/her employer or principal of the SCO IP Rights arising from the services performed by such persons, except where this absence of such agreement would not have a Material Adverse Effect on the Group Business."

In (h) of 215, it makes reference to a "SCO Disclosure Letter", which lists "license, sublicense, agreement or other permission pursuant to which SCO or the Contributed Business Group is entitled to use third party IP Rights (excluding shrink wrap licenses to commercially available software sold at retail) as of the date hereof, the absence of which would have a Material Adverse Effect on the Group Business that a third party owns and that SCO or the Contributed Business Group uses pursuant to a license, sublicense, agreement or other permission, and describes and identifies such license, sublicense, agreement or other permission (excluding shrink wrap licenses to commercially available software sold at retail)", but this letter was not online. Oddly, governing law state for that contract was to be NY and venue chosen was CA:

" 13.1 Governing Law; Venue.
"(a) Governing Law. The internal laws of the State of New York (irrespective of its choice of law principles) will govern the validity of this Agreement, the construction of its terms and the interpretation and enforcement of the rights and duties of the parties hereto, except that the fiduciary duties of the directors and managers of parties hereto and its Affiliates shall be governed by the law of the jurisdiction of such company's formation.

"(b) Venue. The parties agree that any dispute regarding the interpretation or validity of, or otherwise arising out of this Agreement, shall be subject to the exclusive jurisdiction of the California State Courts in and for Santa Clara County, California or, in the event of federal jurisdiction, the United States District Court for the Northern District of California sitting in Santa Clara County, California, and each party hereby agrees to submit to the personal and exclusive jurisdiction and venue of such courts and not to seek the transfer of any case or proceeding out of such courts.

"13.2 Assignment; Binding upon Successors and Assigns. None of the parties hereto may assign any of its rights or obligations hereunder without the prior written consent of the other parties hereto; provided, however, that the sale or other transfer of the stock of any Contributing Company shall not be deemed an assignment provided that this Agreement remains enforceable against the Contributing Company after such stock sale or transfer. Subject to the preceding sentence, this Agreement will be binding upon and inure to the benefit of the parties hereto and its respective successors and permitted assigns."

Caldera also has on the list of their contracts "GNU General Public License -Caldera Systems", which ends with these words:

" This General Public License does not permit incorporating your program into proprietary programs. If your program is a subroutine library, you may consider it more useful to permit linking proprietary applications with the library. If this is what you want to do, use the GNU Library General Public License instead of this License."

This would indicate to me that when Caldera provided these contracts and license agreements to Findlaw, evidently in 2000, judging from the latest date, it included the GPL as one of the ones it knew it was utilizing.

Coder Visits SCO and Sees Code
Thursday, June 19 2003 @ 07:33 PM EDT

I can't encourage you enough to visit this article in today's Linux Journal. Ian Lance Taylor, a long-time free software programmer, flew to Utah at his own expense to see the infamous SCO proof code and met with Sontag and Stowell there. They showed him their presentation personally, including the 80 lines of code. His insights are very valuable. He writes, as I wrote the other day, that the key to this case isn't so much a small amount of identical code. It's what is the definition of derivative code? SCO told him their interpretation, which is very expansive, and he reacts thus:

"All programs run on Unix use a Unix API; do they therefore become derivative works? Presumably not. However, when writing a program that runs on Unix, I might look at Unix source code if I have access to it; does that make my program a derivative work? It seems, from SCO's comments, that it might claim this is so.

"I am not a lawyer. However, I hope the courts will not accept SCO's broad definition of derivative work. I think it would be dangerous for free software and for software development in general. Software thrives by extending work done by others. If adding a component to an existing piece of software means the component is owned by the owner of the existing software, then few people will add components. That would not be good for anybody.

"It's worth noting that if a court does accept such a broad notion of derivative work, it will weaken SCO's defense against the allegations that Linux code was copied into UnixWare. That would seem to put SCO on the horns of a dilemma; I don't know how it plans to resolve it."

Here is what Aberdeen Group's Bill Claybrook says is his understanding of SCO's definition, in his article on how companies can avoid legal problems with SCO:

"Derivative code, as defined by SCO, is extensions to the Unix kernel or code written to run in the System V kernel. The SCO-IBM lawsuit partly concerns derivative code. SCO claims that IBM[base ']s release of derivative code to Linux is a violation of its contract with SCO. IBM claims that it owns the derivative code and can do anything with it that it wants."

Here's why the definition is so important. If SCO's interpretation were to be accepted, it would mean that even trying to remove and rewrite the code would be useless. SCO would still claim it, if I have understood their argument:

"As noted above, it feels large chunks are derivative. It argued that even a full replacement would be in part based on the prior effort, and thus would itself be derivative, at least under the terms of the IBM contract.

"This may be a deep misunderstanding of the free software process. If Linux becomes encumbered to the point where commercial users must pay a fee, I expect that many independent developers will stop working on it. Linux development will slow down and may eventually stagnate. The people in charge at SCO may not understand that."

It's possible Ian is right, that SCO and the attorneys simply are a bull in a china shop, oblivious of their effect because they are what they are. However, information is powerful, and I hope they read what he wrote and think about it, because if they achieve their current aims, it will harm them too in the long run. It has already hurt them in the short run. It is not too late for them to tack and move in a better direction.

Here's another page I can recommend, Karsten Self's SCO page. There are some comments posted there that I will be commenting on as I can, particularly the Sun issue.

Meanwhile, if anyone reading this blog has any textbooks defining "derivative code", please email me the definition, with title of book, author(s), page number(s), and publisher. If you want to scan in the page instead of typing, that's fine. A court would be influenced in all likelihood by evidence that SCO's definition is way outside the definition normally accepted in the field.

April 2014
SunMonTueWedThuFriSat
30
31
01
02
03
04
05
06
07
08
09
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
01
02
03
Click on any day to search postings for that date.

Articles Only


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 )