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

Gear

Groklaw Gear

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


You won't find me on Facebook


Donate

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

STORIES
No new stories

COMMENTS last 48 hrs
No new comments


Sponsors

Hosting:
hosted by ibiblio

On servers donated to ibiblio by AMD.

Webmaster
IBM Files a Notice of Errata
Friday, August 13 2004 @ 08:23 AM EDT

IBM has filed a Notice of Errata. It makes a correction to the Memorandum in Support of the Motion to Strike the Declaration of Christopher Sontag, filed August 4, 2004.

Apparently, someone noticed that the quotation from the Joan Thomas Declaration of August 4 was not correctly quoted in the Memorandum. So it isn't new information, since the Joan Thomas Declaration is already on file, and it is not being changed. But it's correcting a mistake in the quotation from it in the Memorandum.

How does such a thing happen? First, we are all humans. Second, motion practice is always a time pressure thing. Usually, as you can imagine, there are several drafts of a document, especially when you are incorporating information from others, and it may be arriving in pieces here and pieces there. Sometimes, I'm sorry to say, it's the paralegal that goofs or the secretary or even the attorney, and nobody notices until it is filed, in the haste of pulling it all together. We've seen SCO make a correction in this lawsuit too, when it had to file a corrected motion, with whole sections revised. It just happens sometimes. And when it does, you just correct it with a Notice of Errata or a corrected motion or whatever you need to do to get the correction filed appropriately. You don't ever pretend it didn't happen or hope no one notices.

Frank Sorenson used a handy tool created by the Free Software Foundation,'wdiff', which is both Free and free, to make an easy comparison of the old version with the new. In the wdiff results, the new wording (which is the original Thomas Declaration wording also) is in bold, and the corrected material has a line through it, so you can easily see the differences.

To duplicate, the results for yourself, all you do is this: type up the original text, and let's say it is called memo1.txt. Then do the same for the new version, named memo2.txt. Once you have them both, you do this:

# wdiff -w "" -x "" -y "" -z "" memo1.txt memo2.txt

And here is what you would get, corrected words in the Memorandum in bold and the old wording crossed out.

********************************

wdiff version:

Even setting aside the fact that he has no personal knowledge of the operation of CMVC, Mr. Sontag's conjecture regarding his proposed "top-down" approach is simply wrong, as set forth in the accompanying Declaration of Joan Thomas. (See, e.g., 8/4/04 Declaration of Joan Thomas ¶¶ 7-8) 8-9) ("Contrary to Mr. Sontag's assumptions, there is no top-level directory or subdirectory name in CMVC that contains the word 'AIX'. Even the names 'AIX', from which we could extract all AIX source, and only AIX source, from that directory and its subdirectories. The vast majority of the AIX-related directories and files themselves on CMVC, in fact, do not usually even contain the word 'AIX.' 'AIX' in their names. ... [D]etermining which components in CMVC are part of the AIX operating system is a time-consuming process that requires that engineers intimately knowledgeable about the AIX operating system and about CMVC to engage in a time-consuming, multi-step process to extract the source code files that are part of the AIX operating system from the tens of thousands of other source code files that are not part of the operating system.") ******************************

Original version in memorandum, or memo1:

Even setting aside the fact that he has no personal knowledge of the operation of CMVC, Mr. Sontag's conjecture regarding his proposed "top-down" approach is simply wrong, as set forth in the accompanying Declaration of Joan Thomas. (See, e.g., 8/4/04 Declaration of Joan Thomas ¶ ¶ 7-8) ("Contrary to Mr. Sontag's assumptions, there is no directory or subdirectory name in CMVC that contains the word 'AIX'. Even the names of the files themselves do not usually contain the word 'AIX.' . . . [D]etermining which components in CMVC are part of the AIX operating system is a time-consuming process that requires engineers intimately knowledgeable about the AIX operating system and about CMVC to engage in a time-consuming, multi-step process to extract the source code files that are part of the AIX operating system from the tens of thousands of other source code files that are not part of the operating system.")

***************************

Corrected wording in Notice of Errata, or memo2:

Even setting aside the fact that he has no personal knowledge of the operation of CMVC, Mr. Sontag's conjecture regarding his proposed "top-down" approach is simply wrong, as set forth in the accompanying Declaration of Joan Thomas. (See, e.g., 8/4/04 Declaration of Joan Thomas ¶¶ 8-9) ("Contrary to Mr. Sontag's assumptions, there is no top-level directory in CMVC that contains the word 'AIX', from which we could extract all AIX source, and only AIX source, from that directory and its subdirectories. The vast majority of the AIX-related directories and files on CMVC, in fact, do not even contain the word 'AIX' in their names. ... [D]etermining which components in CMVC are part of the AIX operating system is a time-consuming process that requires that engineers intimately knowledgeable about the AIX operating system and about CMVC engage in a time-consuming, multi-step process to extract the source code files that are part of the AIX operating system from the tens of thousands of other source code files that are not part of the operating system.")


  


IBM Files a Notice of Errata | 240 comments | Create New Account
Comments belong to whoever posts them. Please notify us of inappropriate comments.
OT Here Please
Authored by: Anonymous on Friday, August 13 2004 @ 08:31 AM EDT
So we can keep the thread tidy.

[ Reply to This | # ]

Corrections Here Please
Authored by: Anonymous on Friday, August 13 2004 @ 08:33 AM EDT
You know why...

[ Reply to This | # ]

IBM Files a Notice of Errata
Authored by: bliss on Friday, August 13 2004 @ 08:40 AM EDT

Wow ... first post :-)


I suspect that someone with CMVC access could script
some sort of pull of source code from the system. There
has to be a process to *build* AIX which references all of
those files and that could be used as a foundation to
backtrack.

IBM is complying with the discovery and seeking to avoid
assisting the fishing expedition - manually examining
things instead of developing the methods to pull things
automatically. Of course, the manual process lets them
carefully determine the history of source that has moved
in to AIX - consider the JFS non-controversy SCOX brought
up and you'll understand this issue.





---
Information becomes fragmented, knowledge does not. What causes fragmentation in
information is scholasticism - Ramitani

[ Reply to This | # ]

IBM Files a Notice of Errata
Authored by: hardcode57 on Friday, August 13 2004 @ 08:51 AM EDT
And now we just wait for the SCO press release stating that IBM 'admits
deceiving the court'.:)

[ Reply to This | # ]

Major mistake
Authored by: proto on Friday, August 13 2004 @ 08:53 AM EDT
This is a major mistake. Probably due that someone legal didnt quiet understand
what someone technical tried to explain. As a CEO with a small software company,
I am know that IBM is right. It is very very hard to get all version out of a
version control system. Takes a lot of work even to get back to an older
version.

Having said that, the original way of putting it, was that there was no
subdirectory with AIX. Maybe some tech guy read this on Groklaw and went to his
boss to correct it. Now it only says there is no top level directory named AIX,
which opens up the possibility that there is a subdirectory AIX exactly the way
SCO hopes there is.

For instance a structure like:

- OS
--- AIX
--- Linux
- Games
--- Doom IV

etc. etc.

Also the limiting statement, top-level directory from which we could extract all
AI sources, is tricky as it obvious that this could mean:

- OS
--- AIX
----- Version1
----- Version1.1
----- Version2

etc.

This would make the statement true, but vulnerable to an attack by SCO if SCO
ever learnt the truth.

My guess is is that IBM's version control is a lot better than ours, still not
nearly good enough to be proud of it (like MS, SUN etc.), because it is hard to
do right. They are simply to ashamed to admit that they cannot get these old AIX
versions back because they made a mess of it. That would probably hurt IBM more
than the whole SCO case.

Trust me one thing though, the more SCO puts its attention to version control,
the more it will become clear that their request cannot be fulfilled. Only
question is how much bad publicity does it generate for IBM.

[ Reply to This | # ]

IBM Files a Notice of Errata
Authored by: josmith42 on Friday, August 13 2004 @ 09:39 AM EDT
"[D]etermining which components in CMVC are part of the AIX operating system is a time-consuming process that requires engineers intimately knowledgeable about the AIX operating system and about CMVC to engage in a time-consuming..."
"[D]etermining which components in CMVC are part of the AIX operating system is a time-consuming process that requires that engineers intimately knowledgeable about the AIX operating system and about CMVC engage in a time-consuming..."

These two sentences, to my untrained eyes, say the same thing, with slightly different wording. I'm assuming they don't mean the same thing in legalese. Here's my question: How is the meaning different? And if it isn't different, why would IBM bother to change something so minor if it doesn't change the meaning?

---
Forty-two: the answer to the question of life, the universe, and everything.

[ Reply to This | # ]

Verson Control Software...
Authored by: Anonymous on Friday, August 13 2004 @ 09:43 AM EDT
SCO may be thinking for something like MSFT's Source Safe. Each product has
a top level directrey in which the entire product is stored. But Source Safe has

a major problem when it comes to trying to pull old version. Each file change
creates a new version of the file; a standard build only pulls the newist
version of the file; thus, to rebuild an older release you need to script the
system to pull the version of the file used in the build of that release.

Linux used to use CVS. This has the same issues; to over come this issue, the
Linux team has created new projects for each release. i.e. We decided to
release V1.0 to the public, so we copy all current versions into a new
directory tree.

Even this doesn't solve the issue of what SCO wants. SCO has asked for every
version of every file. A file may change mulitply times between between
releases; thus, pulling the top layer of each release wont get you all the
changes.

No version control system I've ever worked with will let you pull each version
easyly. Basiclly, you need to identify each file in a release and then pull each

version of the file from the system.

The final result would like something like (just looking at the 'ls' command)...


AIX_2.0
-- ls.c.2.0.0
-- ls.c.1.0.5
-- ls.c.1.0.4

AIX_1.0
-- ls.c.1.0.0
-- ls.c.1.0.3
-- ls.c.1.0.2
-- ls.c.1.0.1

I'm assuming that they change the top version number of the file to match
the release. If they don't then AIX 2.0 could be release with ls.1.0.6; this is

also likely.

[ Reply to This | # ]

Knowing IBM as I do...
Authored by: Anonymous on Friday, August 13 2004 @ 09:46 AM EDT
I'm betting that Joan Thomas has been trying for years to get resources to
improve the code tracking systems and now as she tries to explain its
inadequacies, some damn lawyer is trying to put words in her mouth and she's not
going to stand for it!

[ Reply to This | # ]

OT: 2003 vs 2004 — "from little things, big things grow"
Authored by: belzecue on Friday, August 13 2004 @ 09:46 AM EDT

A trip down memory lane
Word Doc | Google cache (HTML)

Is SCO going to sue Linux vendors?

SCO is a Linux vendor and a member of United Linux. We have no interest in suing Linux vendors. While we haven’t formulated the details of our new SCOsource effort, we’re confident that we can work together with other vendors to clear up IP issues in a fair and amicable way.

Two weeks ago an industry publication headlined a story saying SCO was threatening to sue Linux vendors.

The story was wrong. SCOsource is now one day old. We haven’t made any plans to sue Linux vendors, and we certainly haven’t threatened any vendors. This story was damaging to the Linux community and made assumptions that were incorrect.

But isn’t hiring Boies, Schiller and Flexner a clear signal that SCO is getting ready to sue people?

Not at all. SCO is working with BSF for their expertise at dealing with complex legal problems. Resolving intellectual property issues does not automatically mean litigation...

SCOForum 2003 - Major Accounts Survey Results
P owerpoint file | Google cache (HTML)

17 participants, top answer listed for each item:

The reasons you use SCO operating Systems
- Reliability

Potential SCO operating system improvements needed in the next 2 years
- Increased hardware support

Reasons you would upgrade your current SCO environment
- Hardware upgrade

Potential future SCO services needed in within the next year
- Driver development

Areas where SCO needs to improve
- Resolve the Linux intellectual property issues

Do you want to develop on the SCO platform, or develop elsewhere & run on the SCO platform?
- Develop on SCO 27%
- Develop elsewhere 36%
- Develop on both 36%

Who are your current system vendors where SCO operating systems are involved? And what system vendors are you considering on your next rollout?
- HP/Compaq
- Dell
- IBM

SCOsource: where it all began
Pow erpoint file | Google cache (HTML)

Upcoming Plans for SCOsource

First deliverable: SCO System V for Linux

Why license SCO’s Intellectual Property?
- Customers are requesting it
- Increase shareholder value through existing IP
- Strengthen Linux by licensing value-add IP
- Increase UNIX application use on Linux
- Customer Pricing: $149 per processor

 

[ Reply to This | # ]

Astroturfers, post here.
Authored by: Anonymous on Friday, August 13 2004 @ 10:05 AM EDT
Thanks for your co-operation.

[ Reply to This | # ]

Please take your anti-SCO blinders off!
Authored by: Anonymous on Friday, August 13 2004 @ 10:12 AM EDT
All you say about configuration management is true, to an extent, but filtered
through your anti-SCO biases.

First you need to understand that about the time I started using Linux, I was
also an administrator of a DSEE system at the time we began to migrate our
projects to ClearCase (1991-94). When I began administration of the repository,
the dependency information was all screwed up making it impossible to create the
same release twice. Even with the screwed up dependencies, I would prefer to
query the revision history database to comparing release snapshots.

Nobody with CM experience would prefer looking at snapshot releses to examining
the meta data which is available in a relational database as it is with CMVS.

[ Reply to This | # ]

Warts
Authored by: AllParadox on Friday, August 13 2004 @ 10:41 AM EDT
More paradoxes.

One of the things I learned as a trial lawyer was to look for warts. Airbrushed
photographs of models in fashion magazines have no flaws. The rest of us have
scars and moles and warts.

Real, human, mortal people make mistakes. We make mistakes contstantly (sic).
A frequently effective test of the credibility of a witness is to look for
"warts": flaws, mistakes, errors, misjudgments. Very good liars know
to leave in the warts, but this makes it very complicated to remember the story,
and many liars do not reach this point of analysis.

I applied the "wart test" both to my client's witnesses and to
opponent's witnesses.

It takes a concious effort to stop and mentally review a story told by a
witness, to look for warts. If there are none, then some hard, probing
questioning is appropriate. If there are still none, then we most likely have a
liar. These witnesses are very dangerous to use, especially if it is the
client, and if witnesses for the opponent, provide excellent openings to
discredit the opponents entire case.

On the flip side, "warty" witnesses tend to be very credible, because
they are telling the truth. Once, when cross-examining a police officer, I
asked if she made mistakes. She replied: "Oh sure. Lots, every day. I
try to fix what I can, but sometimes I can't." Right then, I decided it
was a perfect time to sit down and shut up.

I also apply the test to attorney product. As a matter of professionalism, all
typos and grammatical errors in legal documents should be corrected. All
factual assertions should be checked and re-checked, against the original
document when possible.

"Should" is the operative term, however. Real people have warts, and
real people make mistakes in trascription and interpretation.

All stories by attorneys are suspect. They are, after all, salespeople. They
are selling a concept. It is their job to present the best portrait of the
concept.

This IBM correction is a "wart". In my opinion, it adds to the
persuasiveness of the IBM argument, instead of detracting. When reviewing the
document, they found a statement that was stronger than the facts deserved.
They could easily have gotten away with not correcting it. They exposed the
wart anyway.

This is my biggest problem with the TSG arguments, and the presentations from
the TSG attorneys. The presentations are "wart-free", in spite of
glaring inconsistencies. They never corrected multiple typos and grammatical
errors, perhaps because they wanted to maintain the appearance of perfection.

The result was perfect presentations that no one can believe.

---
All is paradox: I no longer practice law, so this is just another layman's
opinion. For a Real Legal Opinion, buy one from a licensed Attorney

[ Reply to This | # ]

The Primary Substantive Difference
Authored by: rsteinmetz70112 on Friday, August 13 2004 @ 11:06 AM EDT
From my reading of the change the primary substantive difference is that in the
first version, IBM claimed there were no subdirectories containing AIX in their
names, in the amended version they refer only to top level directories.

The sense of the rest of it is left pretty much intact.

It doesn't seem to affect the thrust or strength of IBM's argument much but does
eliminate the possibility of tripping up someone in a deposition.

---
Rsteinmetz

"I could be wrong now, but I don't think so."

[ Reply to This | # ]

IBM Files a Notice of Errata
Authored by: Anonymous on Friday, August 13 2004 @ 11:57 AM EDT
> "Contrary to Mr. Sontag's assumptions, there is no directory or
subdirectory name in CMVC that contains the word 'AIX'.

I shouldn't be too surprised if this change is the result of a developer at IBM
noticing this particular statement on Groklaw.

I'd have been truly amazed if absolutely none of the sub-directories in the
source control system contained the word AIX.


[ Reply to This | # ]

why conditional includes make the SCOG discovery request physically impossible
Authored by: gdeinsta on Friday, August 13 2004 @ 12:41 PM EDT

A little background for non-geeks: source code may contain portions that are marked to be included conditionally. For example, if the code contains

#if AIX
#include "foo.h"
#endif

then the line '#include "foo.h"' is only to be included if the compiler has been told that the value of AIX is non-zero. This can be done on the command line as part of the compile instruction, e.g.

cc -dAIX=1 bar.c -o bar

says to compile bar.c, generating the program bar, and while compiling it assume the value of AIX is 1. This would cause the compiler to include the file foo.h in accordance with the #include directive. Had the -dAIX=1 not been specified the compiler would have skipped over that line of code, hence not have included foo.h in the program.

So a single source file may be compiled in multiple ways. Often for operating system kernel code there are many of these conditional compiles controlled by dozens or hundreds of variables. For example, some code may be used on one particular processor but not another. Even within a family of processors there are often significant differences between the various models, enough that the kernel has to use different code in places.

The compiler can also get these conditional compile variables from the environment in which it is run. For example on some Unix systems "_tahoe" is automatically defined as 1 for all compiles. In addition both Unix and Linux allow a process, such as a compiler, to inherit defined strings from its parent process. Thus the compiler may respond to variables not defined or visible on its command line.

So how can you determine if a particular piece of code is included in a program or not? You can not know what is included unless you know the details of the build environment. In the example, if the command line says

cc bar.c -o bar

there is no way to know whether or not foo.h is included in the program without actually running the compiler on a machine that is identical to the original development machine. Hence in order to know what is included in a program you must have an exact duplicate of the machine upon which it was originally compiled. This is a real problem for software manufacturers. In order to be able to fix bugs in older releases of the software they are forced to keep old machines around, preserved in amber as it were. They actually do this; they have old machines sitting around just in case a bug fix is needed for that release and platform.

No-one keeps around all their old development machines, and in any case development machines (unlike QA machines) are frequently reconfigured. It is therefore physically impossible to find all intermediate or development versions of the source code, because you can never determine which files were included and which ones weren't.

[ Reply to This | # ]

IBM Reply due Aug 16 - 56(f) argument
Authored by: Thomas Frayne on Friday, August 13 2004 @ 02:01 PM EDT
IBM's reply to SCOG's memo in opposition to the PSJ motion is due next Monday. I have organized IBM's and SCOG's related arguments, and have started adding comments. I would like anyone that would like to help with arguments that might be useful in IBM's reply to add comments as well. Here is my comment on SCOG's 56(f) argument that I inserted at PSJ-PromptAdjudication#TF09:

SCOG has had ample time for discovery on the issue of IBM's infringement of SCOG's copyrights by IBM's Linux activities. SCOG should have had evidence on this issue before it made its first false public statements on this issue early in 2003. It should have been trying to refine that evidence at the time IBM filed its Lanham act counterclaim in September, 2003. It should have been able to provide the precise information related to this issue that was required by the December compel order. Failing that, it should have stated in its January response affidavit a list of examples of claimed copyright infringement in Linux, with specific justification for each item that stated what SCOG knew about that item, what court ordered information was missing, and how SCOG could use specific discovery (not 2 billion lines of code) to discover that missing information. SCOG did not provide this list in January, nor on April 19. In its 86 page opposition to the PSJ, SCOG presented the beginnings of this list (see TF02), but did not state the missing information that it expected to find from the further discovery, beyond stating that it could take depositions. (SCOG claims that it does not have sufficient information yet to take its first deposition.)

In the third paragraph of the above section, SCOG quotes: "It is unreasonable ... to demand a detailed explanation of the evidence the appellants in this case hoped to discover. The appellants had no real opportunity to conduct discovery and, in terms of specifying how the desired evidence would preclude summary judgment, could do little more than state that it was relevant to one of their theories of recovery. (Radich v. Goode)..." However, in the current case, the judge has ordered that SCOG provide detailed information on what rights in Linux were infringed by what code in SysV illegally copied into Linux. Further, the judge denied SCOG's request for another 2 billion lines of discovery, and stated that further discovery would be considered only after SCOG fully complied with the court order by April 19 and provided a detailed explanation of the evidence that SCOG hoped to discover to justify its request to re-open discovery. By implication, since IBM's discovery response also had a deadline of April 19, SCOG was supposed to produce the court-ordered information from the information it had on March 6, and from what it could deduce from that information, without relying on IBM's response to the March 6 court order. The Protective Order even forbade SCOG's employees from looking at the new discovery from IBM.

SCOG seems to think that this court's ruling was in error. It seems to think that it can make the discovery process more efficient by demanding another 2 billion lines of code when it has not had time to review the hundreds of millions of lines that IBM has already produced, and has not had time enough to produce one detailed example of its copyright infringement claims that it has been claiming for more than a year to have mountains of evidence for, enough to proceed to trial without discoverys, time enough to respond to two court orders with enough information to justify seeking more.

Since IBM has not raised the issue of ownership, SCOG does not need that issue settled for a decision on whether IBM's Linux activities have been shown to violate SCOG's alleged copyrights. The only fact that needs to be established is whether Linux contains code copied from SysV.

[ Reply to This | # ]

IBM Reply due Aug 16 - Procedural Posture
Authored by: Thomas Frayne on Friday, August 13 2004 @ 03:14 PM EDT
IBM's reply to SCOG's memo in opposition to the PSJ motion is due next Monday. I have organized IBM's and SCOG's related arguments, and have started adding comments. I would like anyone that would like to help with arguments that might be useful in IBM's reply to add comments as well. Here is my comment on SCOG's Procedural Posture argument that I inserted at PSJ-PromptAdjudication#TF10:

======TF10====== Procedural Posture: SCOG argues that it will need expert witnesses to prove at trial that the cases of "substantially similar" code are evidence of illegal copying. This is true, but irrelevant at this point in the procedure. Before SCOG can go to trial on the issue of IBM's Linux activities infringing SCOG's copyrights SCOG must do several other things required by the procedure, e.g.:

* State the facts known clearly enough to justify discovery that will allow SCOG to identify precisely what blocks of code in Linux that SCOG claims were copied from what blocks of code in SysV, and why SCOG claims the copying infringed SCOG's copyrights. SCOG should have done this in its response to IBM's Lanham Act claim, before starting related discovery. It has still not done so. SCOG's latest request for further discovery was rejected by the court, and now SCOG has filed a "renewed" request for the same information that the court declined to compel IBM to provide.

* State its factual claims clearly enough that IBM and the court will know precisely what blocks of code in Linux that SCOG claims were copied from what blocks of code in SysV, and why SCOG claims the copying infringed SCOG's copyrights. SCOG has still not done so. It claims that it would be able to discover this information if the court ordered IBM to produce another 2 billion lines of code. However, the court said that it would consider ordering more discovery from IBM only after SCOG had fully complied with the court order and provided a detailed justification of its request for more discovery. See TF02 for evidence that SCOG knew the factual evidence it was claiming, but withheld the information about that evidence in its April 19 response to the March court order.

* Make a prima faciae case that, if the claimed facts are true, a reasonable jury could conclude that IBM's Linux activities infringed SCOG's copyrights. SCOG has not and cannot make such a case from the detailed information it supplied on April 19, and should not be allowed to make such a case from information it had or should have derived from information it had on April 19, unless it shows that information needed for this purpose and required before April 19 was withheld by IBM. SCOG has not shown that IBM withheld any information required by April 19, much less before. See TFxx for evidence of this.

Expert witnesses will be suitable once SCOG has satisfied these requirements. However, SCOG has been given ample opportunity to do so, and has not done it. The time is ripe for a decision on the PSJ. If SCOG gets past that, it will be time for it to start deposing expert witnesses.

[ Reply to This | # ]

Probably doomed to fail despite anybody's (even IBMs) best efforts
Authored by: Anonymous on Friday, August 13 2004 @ 03:16 PM EDT
As a developer, I can assure you that much of the "interesting" work
on any project is done in "sandbox" environments; these are code sets
copied to a developer's own machine, and perhaps 90% or more of intermediate
code changes go on in such sandboxes, until it comes time to check in the
changes and align the changes with the work of others (also working in
sandboxes).

Sandboxes are NEVER permanent (except perhaps in mickeymouse engineering shops
(no offense to the Disney folks). They are not saved, rarely backed up (too
big, and too fleeting), and there is often no way to even determine the overall
state or contents without a huge amount of work -- none of which is possible
after the sandbox is deleted ("rm -rf mysandbox").

What SCOG is asking for is so totally out of whack with accepted practice that I
can only think Sontag purposely invented comments just to confuse the judge.
IBM presented the "tagged" versions from CMVC already; intermediates
that *might* exist probably account for only a very tiny fraction of any work
that was done, and it is extremely unlikely that any worthwhile data could be
derived even IFF developers kept every single copy of every single sandbox they
make (I've been known to make several in a single day on similar systems and
projects).

Sontag is full of it.

[ Reply to This | # ]

IBM Files a Notice of Errata - small changes really.
Authored by: Anonymous on Friday, August 13 2004 @ 05:29 PM EDT
One thing that I'd like to note, which I'm not sure that has been explained
already, is that in things like RCS / CVS / etc projects are listed under
various different names. Bear in mind the 'AIX' is _not_ a single project, it
is an OS release with many different supporting programs, each with its own
source tree, program versions and tags, etc...

To the contrary of what some here have speculated, I don't think it's possible
to get everything AIX related, and start a 'build' of AIX through any short list
of CMVC commands. You'd have to get a list of products and versions for the
projects that shipped with a specific version of AIX and build these components
individually.

The revised statement doesn't have less of an impact on the situation, nor does
it carry less weight than the original. Looking at the changes, it's fairly
easy to conclude that:

1) There was a sub-directory (or sub-directories) somewhere in one of the
product lines that included the text "AIX" (thus the need for the
removal of the "or subdirectory named" AIX).

2) This is not some kind of "top-level" directory that all things AIX
reside in. Chances are, a small set of files related to a portion of code which
is specific to AIX for some module of a project (thus the addition of the
qualifications spelling out as much: "...from which we could extract all
AIX source, and only AIX source, from that directory and its
subdirectories.").

This is a simple case of someone found an execption to the general rule that
there isn't a directory named/containing AIX somewhere buried in a product's
source tree that happens to be a component of the AIX distribution (plus a
change in the paragraph references from the J Thomas declaration). Remember,
IBM has turned over source for over 250 products, so it doesn't suprise me that
somewhere a directory contains AIX in its name in the source tree. Even if a
directory named "AIX" existed in the source in one of over 250
products, it obviously doesn't point to all things AIX (in reality probably only
a small part of one of many products that in combination create AIX as an OS).

Sorry if someone already pointed this out buried in another thread somewhere.

-TomcaT-

[ Reply to This | # ]

"Real" Source Code Control
Authored by: BitOBear on Friday, August 13 2004 @ 09:37 PM EDT
I have seen several posts above casting bread on how, when you use CVS (etc)
you'd have sub directories with 'AIX' in there somwhere not at the root and
(aspersion) and (supposition) and (sniggle) and so on.

In point of fact one should not mistake CVS for a comprehensive version
management tool approprate for a large company to use for centralized version
control. The analogy doesn't fit.

Let's take a quick tour...

If we relax the definition of the word "directory" a tad, there needs
must be some feature somewhere that contains the root of the question "how
to build AIX" or more likely "how to build version N of AIX". If
you equate this group of instructions with the concept "directory"
then you do get just such a starting point. So we have pundits saying that
there "must be" some such directory somewere. Small value that, it
doesn't mean anything in terms of the request to produce...

In practice as systems grow more complex, the idea that "all of system
(whatever) in its current, past, and future guises is descretely stored in
location (whatever)" becomes clearly unworkable.

Consider the lowly header file "stdio.h". In a comprehensive version
control system supporting AIX, OS/2, plan 9, (etcetera, od nausium, amen) it
becomes desireable to "unify" the interface file so that the single
file is consistently used in all the products that must interract.

In such a system, the "cumulative diff" technique of RCS and so CVS
would be completely untennable. Among other things, one wouldnt want to check
in and brand "Versions" so much as "change sets." That is,
you would want each feature change to go in separately so that you could block
or approve particular features instead of whole file versions.

(If you want to look at just the easy-to-see examples of this kind of tracking,
just look at the BitKeeper discussions floating around on the Linux Kernel
Mailing List. Finding citations is left to the reader. 8-)

Having never seen nor heard tell of the internal workings of IBM's version
control system, I can still easily imagine a "repository" that isn't a
"file system". In this repository there is a database system in which
"each file" exists as a basic template and a bunch of "change
sets" on that template. All the templates and all the change sets exist
all co-mingled, and there is just this one big repository.

Now each "system" or "subsystem" or "unit of work"
probably floats around in there as little more than a database query (or more
precisely a queriable (sp?) data set). There would then be another data set
that dictated products and another that dictated packages and another that
dictated programs, each cast over the set of all files used.

Individual developers, separate from "systems integrators", would use
a tool to create "development arenas" or "build arenas"
(e.g. real file-system directories) based on various tags and system or project
data sets. These arenas may well exist for a transient time and to address a
spesific issue. For instance I may spend a month in an arena looking into how I
could improve a kernel scheduler. I may end up making twenty five change sets,
of which only the 3rd and 7th apply, because the other experiments were (as
experiments often are) "less than fruitful".

Now holding all that in your head, think about what IBM sells when it
"sells a version of AIX."

You know how you see people who keep telling you to use the phrases "Linux
Kernel" and "GNU/Linux Operating System" and "GNU/Linux
Distribution"? Well the reason is that "A (GNU/Linux)
Distribution" may well contain more than a thousand separate
"packages" with any number of "programs". (Or if not a
thousand, at least a hundred packages and a thousand programs, but you get my
point. 8-)

So lets look at some abstract feature.

Let's say there is a "build-JFS-image" library. This library is
shimmed-over by "mkjfs" as a separate command in linux, but is part of
a large "disk management interface" in OS/2. If this library was
really just one big C source file (for simplicity) with 100 change sets, which
of those 100 change sets are properly "part of AIX"? Is it just the
change sets that have been part of official releases of AIX or is every change
set from every experimental arena that was ever compiled to run under every
internal and expermential release of each kernel that was considered for
distribution as AIX, or is it all of them, or what?

Simple compositing says that you end up with a cartesian product. To produce
"every piece of AIX source code" you might well have to produce every
legal combination of change-sets for every file in every program in every
package in every product, times every candidate for each, to "produce every
version of AIX ever".

You would also have to find all the one-off things. You know, build arenas for
"deliberately damaged" elements like the version of build-JFS that
makes "damaged JFS images" so that the "fix-JFS" library can
be tested.

You also have to look at global changes, for instance, if you had a change set
called "big-endian JFS support" you would have to go look to see if
you ever built "AIX with JFS support for big-endian systems" even if
you never made such a release, and so on.

It is almost, but not quite, an NP-Incomplete problem. It is certian that there
is a hideous multiplicative effect.

So I would imagine that the statement that "there is no top-level directory
called 'AIX'" is a whopper of an understatement.

There is almost certianly a "file" that documents the
package-version-parameter_list groups for each element of each release of AIX.
There is also, almost certianly a tool that will let one "start at the
top" of that dependency tree and "go get" "spesific
builds".

There are also probably tens of thousands of spurious changes and tidbits that
never made it into *anything* that IBM would call "AIX" but which were
part of the experimental or ongoing evolution of the AIX product.

In order for IBM to *honestly*, and with due dilligence, say to the court that
they have produced "all the AIX source code (ever)", they would likely
have to perform an almost Hurclean task of tracking down the provenance and use
of easily thousands of individual change sets.

I do not find the statements made in the declaration "slippery" or
"disengenuous" at all.

[ASIDE: to repeat and expand my disclaimers... I do not work for any of the
involved parties and have no first hand, nor reliable second hand, information
on the actual way IBM acutally performs Version Control. This analysis is based
on my general knowledge of how the task of "version control" for
non-trivial projects can suck up almost unlimited resources and how projects
evolve over time. Given an unbounded request for something like "every
version of (whatever)" and my lay-understanding of the weight a court would
probably put on the word "every", I don't belevie the request could be
honestly satsified. There would almost axiomatically always be one more version
that wasn't produced. This post discusses the nature of that beast in the
atainable abstract.]

Finally, consider: "Mr. Torvalds, please produce the source code for every
version of the Linux Kernel you have ever worked on." The number of faild
and rejected patches submitted to him alone would make this task impossible.
Even giving unrestricted access to the BitKeeper instance holding the kernel
work wouldn't satisfy the request. He'd have ot fish through past backups and
scratch build arenas for all the patches he failed outright. Now ask the same
of a company, any company, for any software product...

(Excerpt or copy the above at will, with attribution, but this may be worth less
than the photons it's printed on... 8-)

[ 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 )