Slashdot Mirror
SCO Complaint Filed -- Including Code Samples
btempleton writes "The folks at Groklaw have posted a story including a preliminary copy of Caldera/SCO's amended complaint, including lines of code they allege were improperly included in Linux. The PDF can be found at this story The file lists unix filenames with line numbers and filenames and line numbers from the Linux 2.2 and 2.4 kernels, so folks can now go into real depth."
Looks like they're pointing out the JFS, EVMA and RCU stuff which everyone knows IBM contributed and probably did modify from IBM's/Dynix's own code. The dispute is about whether SCO has any rights to that code in the first place.
Fast mirror here... not that Groklaw would need :D or not ?
Carefully crafted sig.
I've mirrored the PDF file here. At 2.5MB a pop, this mirror is subject to disappear at any time, but perhaps it'll alleviate the load on Groklaw for the time being. Please post other mirrors here.
:)
Thanks PJ for all you do
"BSD: Free as in speech. Linux: Free as in beer. Windows 10: Free as in herpes." --Man On Pink Corner in #52607549.
100. The contribution of the Journaling File System ("JFS") was done in a series of "drops" of AIX code identified as "reference files" inside Linux. The first such drop occurred on or about February 2000, with multiple additions and significant follow-up work by IBM since that time to adapt AIX/JFS for enterprise use inside Linux. These drops of reference files do not necessarily become part of the source code in the Linux kernel, but rather are public displays of the Protected Materials so that anyone has access to them and can use them to construct similar file in Linux. The first drop contains (a) a partially functioning port, or transfer, of JFS from AIX to Linux; (b) a set of reference directories (named ref/) which contain the AIX reference version of AIX/JFS; (c) AIX/JFS-related utility files used to maintain and upkeep AIX/JFS; and (d) a set of directories (named directory ref_utils/) which contain the AIX reference version of utilities. Copies of AIX/JFS files into Linux are shown in Table A, below. Table A compares a 1999 version of AIX and shows the following similarities, demonstrating copying of code, structures and/or sequences.
Table A
AIX 9922A_43NIA File Line #s Linux 2.2.12 ref/File Line #s
usr/include/jsf/inode.h 16-37 include/linux/jfs/ref/jfs_inode.h 84-95,
126-138
kernel/sys/vnode.h 109-133 include/linux/jfs/ref/jfs_inode.h 96-122
usr/include/jsf/inode.h 39-40 include/linux/jfs/ref/jfs_inode.h 189-90
usr/include/jsf/inode.h 161-166 include/linux/jfs/ref/jfs_inode.h 414-421
usr/include/jsf/inode.h 172-180 include/linux/jfs/ref/jfs_inode.h 37-48
usr/include/jsf/inode.h 199-205 include/linux/jfs/ref/jfs_inode.h 52-59
usr/include/jsf/inode.h 62-66 include/linux/jfs/ref/jfs_inode.h 286-290
usr/include/jsf/inode.h 72-76 include/linux/jfs/ref/jfs_inode.h 295-302
usr/include/jsf/inode.h 83-158 include/linux/jfs/ref/jfs_inode.h 322-411
These transfers of AIX/JFS to Linux are in violation of the IBM Related Agreements, and are an improper use of AIX for adaptation to a general operating system.
101. IBM has also improperly transferred a UNIX/AIX-based enterprise volume management system ("AIX/EVMS") to Linux. Again, this was done by IBM to transfer enterprise-class capabilities from AIX to Linux, and was a violation of the IBM Related Agreements and IBM's promise not to adapt AIX as a general operating system for a non-IBM company. The purpose of AIX/EVMS is to allow the management of disk storage in terms of logical 'volumes' in a large enterprise environment. Tools with this level of sophistication and performance were entirely unavailable and unknown to the open source development community prior to IBM's improper transfer to Linux. The actual transfer "patch" by IBM can be found at http://www.sourceforge.net/project/showfiles.php?g roup_id=25076&package_id=17436. The first code drop of AIX/EVMS by IBM was v0.0.1, which occurred on 03/21/2001. The first major release of AIX/EVMS by Linux was v1.0.0, in Linux 2.4, which occurred on 03/27/2003. The latest Linux release version of AIX/EVMS is v2.2.1, which occurred on 12/20/2003. The following table, Table B, identifies the AIX/EVMA "patches" of source code improperly transferred by IBM to the Linux 2.4 version.
Table B
AIX MERCED/9922A_43NIA Line #s EVMS 1.0.0 patches to Linux 2.4.x Line #s
kernel/sys/IA64/bootrecord.h 64-170 include/linux/evms/evms_aix.h 157-263
usr/include/liblvm.h 234-250 include/linux/evms/evms_aix.h 311-327
usr/include/liblvm.h 252-272
289-307 include/linux/evms/evms_aix.h 329-349
usr/include/liblvm.h 316-363 include/linux/evms/evms_aix.h 352-400
usr/include/lvmrec.h 24-92 include/linux/evms/evms_aix.h 266-294
usr/include/lvm.h 26-35 include/linux/evms/evms_aix.h 6-11
kernel/sys/hd_psn.h 32 include/linux/
Looking at their list, there can't be more than a thousand lines there. Most of the matches are about 5-10 lines each.
And they're ALL written by IBM. And IBM's perpetual license says they own their contributions.
Most telling is that none of the code listed is from TSG, OpenServer or UnixWare, it's all IBM-authored code and the entire gambit rests on the breach-of-contract details.
Cue "Funeral March for a Marionette"...
Got time? Spend some of it coding or testing
If you look at the list, you'll notice that most of the files are header files. These header files are probably available in the off-the-shelf releases of these OS'es. They have then probably does some compare and came up with the resulting list.
If they get all sources from IBM, they probably will perform the exact same comparison, but on all the new files they got.
However, we shouldn't be so worried about this. According to one post on groklaw, the contents of these files are mostly #include's anyway.
If you are hunting, be aware that their line numbers refer to versions after the application of e.g. a rcu patch. It makes it tricky to find the actual lines, since the patches change the numbering from that in the pristeen distribution.
Here's the issue as best as can be broken down from the whole case Paragraph "IBM's Scheme"...section 91)
AIX's confidential and propriatery UNIX source code extends only to the code that IBM got from SCO originally to start development from.As an author of add-in modules and enhancements, IBM can distribute under MULTIPLE licenses...It can choose dual license if it wishes....OSS and AIX/SCO.
SCO must now show where their original license stipulates "..all your base..." Failing that, IBM can do whatever it wants to do with it's own creations.
for (i = 1; i < 5; i++) { foo(i); } /* one line */
/* three lines, same code */
for (i = 1; i < 5; i++) {
foo(i);
}
Toronto-area transit rider? Rate your ride.
Such a move wouldn't be very smart, even if it was technically possible. SCO could easily argue that "those evil linux people removed it because they knew it was infringing code." Actually, SCO should not be allowed to argue that. The rules of evidence prevent using the defendant's corrective action to prove liability. The idea is that you don't want to force the defendant to leave in a dangerous or infringing situation in just so his legal position is better.
In case you were wondering what kernel version 2.4.1-01 is and why the files/line numbers shown in the complaint are not there/all bogus: apply the RCU patch found here, bottom of page, to kernel 2.4.1.
Alex
Heisenberg may have been here
Furthermore, SCO has no copyrights to IBM's code (they only own copyright to their own code, that's why they can't force IBM to give it to them). Quoting copyright law: According to SCO: So perhaps it is possible that IBM violated the contract by not keeping any contributed source within the license scope, although did they not meet this condition by keeping the AIX derivative work to themselves? (The materials being the final derivative work that is AIX.) They are free to use their own copyrighted code wherever they please. Of course IANAL, so judge for yourself.
In fact, anyone worried about SCO's claims on Linux would merely be acting in "good faith" by removing allegedly infringing lines from the kernel. Courts assume that anyone acting to mitigate damages (whether real or imagined) is acting in good faith and scores bonus points.
Parties (including plaintiffs) that do not try to mitigate damages are generally held in disdain. Just remember: the judicial system is lazy and doesn't *really* want to hear your case. They want you to work it out. If you can't work it out, they are even too lazy to determine fault and usually just split the difference ('equity' law).
"I assumed blithely that there were no elves out there in the darkness"
Head on over to GrokLaw
They are converting all the documents to HTML and searchable text as we speak.
Save a Life. Donate Blood. Please.
Indeed, another person mentioned that Groklaw was citied in IBM's legal filings. You might also be interested in this:
OSRM has simultaneously retained me, part-time, to work on their indemnification project as their Director of Litigation Risk Research. Not only that but they are donating a certain portion of my time to Groklaw, which will free me from having to do so much nonrelated paralegal work and be free to really focus for the next year on this project. I am very excited about the project and I hope we'll have fun too. Groklaw will continue, meanwhile, as it is, and it remains noncommercial and my personal baby. Well, more accurately, ours, because Groklaw wouldn't be much without you.
Which is from this Groklaw article.
I should also mention that Groklaw, which was originally a completely separate site, has long been hosted by iBiblio. IBM has donated to them.
That fact, of which no one who knows anything is particularly surprised, is what Daniel Lyons of Forbes added to some random blog posts and turned into a conspiracy article. Barring them firing Mr. Lyons for it, this has sealed my oppinion that their "research" consists primarily of press releases with little or no actual independent research and minimal, if any, editorial oversight.
In other words, I wouldn't trust their advice for managing a child's lemonade stand, much less my finances.
I happen to have a copy of "80386 System Software Writer's Guide" by Intel on my desk (ala 1987). This book provides a framework for OS development on the 386 and alot of code to boot. If the entry.S code is derived from Intel code it would be in this book or a later edition. The idea is really not that far fetched. Writing protected mode entry/exit code is at best tedious and entirely unnecessary as intel not only provided code, but in most cases the optimal solutions to the problem as no one understood the nuances of protected mode better then them.
Religion is a gateway psychosis. -- Dave Foley
SCO can not claim POSIX because IEEE came up with it
First of all, IBM has taken great pains to insure that anyone on their Linux team has never had access to AIX or Sys5 code. It was setup as a clean room exercise.
While this may be true for some things (although, really, has IBM actually said this?), it's definitely not true for the RCU stuff, which very clearly says it was " based on original DYNIX/ptx code".
I think this probably won't matter, since IBM can definitely make a good case that RCU isn't derivative of SysV/"SCO" code even though it was implemented in Dynix -- but the path through which this got into Linux seems pretty clear.
Still, there's no (legal) harm in using clean room approach, and it might help in arguing that certain piece of code could not have been copied verbatim.
I like paying taxes. With them I buy civilization -- Oliver Wendell Holmes
This isn't actually what they are claiming to be infringing. Because they are claiming the infringement is 2.4.1-01, this is in reference to the RCU patch against 2.4.1. Available here http://lse.sourceforge.net/locking/rcu/patches/rcl ock-2.4.1-01.patch
/*
/*
diff -u --recursive --new-file 2.4.1/arch/i386/kernel/apic.c v2.4.1-rc/arch/i386/kernel/apic.c
--- 2.4.1/arch/i386/kernel/apic.c Wed Dec 6 02:13:48 2000
+++ v2.4.1-rc/arch/i386/kernel/apic.c Tue Feb 20 16:46:33 2001
@@ -22,6 +22,11 @@
#include <linux/interrupt.h>
#include <linux/mc146818rtc.h>
#include <linux/kernel_stat.h>
+#ifdef CONFIG_RCLOCK
+#include <linux/sched.h>
+#include <linux/rclock.h>
+#endif
+
#include <asm/smp.h>
#include <asm/mtrr.h>
@@ -654,6 +659,10 @@
{
int user = user_mode(regs);
int cpu = smp_processor_id();
+#ifdef CONFIG_RCLOCK
+ int cpunum = cpu_number_map(cpu);
+#endif
+
* The profiling function is SMP safe. (nothing can mess
@@ -663,6 +672,17 @@
*/
if (!user)
x86_do_profile(regs->eip);
+
+#ifdef CONFIG_RCLOCK
+ if (((RC_PLOCAL_rclockcurlist(cpunum) != NULL) &&
+ RC_GEN_LT(RC_PLOCAL_rclockgen(cpunum), rc_ctrlblk.curgen)) ||
+ (RC_PLOCAL_rclockcurlist(cpunum) == NULL &&
+ RC_PLOCAL_rclocknxtlist(cpunum) != NULL) ||
+ test_bit(cpunum, &rc_ctrlblk.needctxtmask) ||
+ ((jiffies - rc_ctrlblk.clock) > RCLOCK_STALL_WARN))
+ rc_chk_callbacks(user || (current == init_tasks[cpunum]));
+#endif
+
if (--prof_counter[cpu] <= 0) {
"SCO claims that the sysv license they inherited in their acquisition of novell's ip gives them right to all derived implementations, the way the GPL does."
Bzzzt! Wrong. Try again.
The GPL cannot, and does not claim to, give the author of an original work any rights over the original portions of a derived work.
In this case, the original work is SysV, the derived work is AIX, and the original portions of the derived work are JFS, EVMS, etc. If SysV were licensed under the GPL, IBM would be required to also license AIX under the GPL. However, nothing would prevent IBM from taking JFS and EVMS code, and putting it into another piece of software with GPL-incompatible license.