|
|
| Looking Deeper at the LKP -- Did SCO Copy Linux Code to Open UNIX? |
 |
|
Wednesday, September 24 2003 @ 12:36 AM EDT
|
One unanswered question in the SCO vs. Linux conflict is the allegation that SCO directly copied Linux kernel source code into the Linux Kernel Personality feature of Open UNIX. eWeek first raised the question in an article printed in June, "Did SCO Violate the GPL?". The article is still available here.
In the article, an anonymous source "close to SCO" who spoke on condition of anonymity said that "parts of the Linux kernel code were copied into the Unix System V source tree by former or current SCO employees."
Blake Stowell was quoted as denying it: "SCO also never used any of the Linux kernel code in the LKP and thus has not violated the GPL."
First, code might be in other places than the LKP itself, but leaving that aside, let's see what some newly discovered evidence, found by Groklaw reader lightsail, indicates as to who told the truth. He directs us to a regional SCO website, SCO Benelux, the regional office for Belgium, The Netherlands and Luxembourg, where you will find a Caldera Powerpoint slideshow by a senior Caldera engineer entitled,"Linux Kernel Personality Internals -- Making a UNIX Kernel Prozac-Ready."
SCO management may be reaching for the Prozac when they see these slides have been discovered. You won't find them on the main SCO website. There are some particularly interesting slides. Slide number 30, for example, says this:
"Open UNIX can run Linux applications and binaries without recompilation, and without marking the binaries in any way
"All it takes is around 40,000 lines of code to build:
- A kernel module for handling system calls
- Three totally new Open UNIX filesystems
- A new system daemon
- And the infrastructure necessary to install all of these, and the whole of Linux, onto Open UNIX" [emphasis added]
Install the whole of Linux onto Open UNIX, you say?
The presentation includes several other interesting points:
1. Slide 6 shows UNIX source code. Excuse me. Isn't that supposed to be such a deep, holy trade secret they can't show any of it even to allow Linus to remove any allegedly infringing code? Yet, there it seems to be in its birthday suit, for all the world to see. This slide is also interesting because is shows a side-by-side comparison of UNIX and Linux source code. So, developers of LKP were using Linux source when developing LKP. Did they copy? Or simply view code as needed?
2. To help us find the answer, consider Slide 11, which states “copy this file to UNIX” when discussing the file: /lib/ld-linux.so.2. Doesn't that make it appear the LKP developers were copying file directly from Linux to UNIX? Otherwise, what does that sentence mean?
3. Slide 12: “To work, this needs a full Linux distribution in /linux”. The kernel is part of a full distribution. Does LKP contain a full Linux distribution in the /linux folder of Open Unix, as the slide says it "needs" to?
Here's hoping IBM asks to see the source code of LKP and Open UNIX as part of the discovery process, to get to the bottom of this question. It has been reported in the news that SCO has recently altered the LKP code, so it would be important to gain access to it prior to the changes, as well as to its current version.
So, take a look at the slides, especially you Linux kernel coders, and tell us what it looks like to you. I am a researcher, not a programmer, and lightsail says he isn't a kernel coder, so he asks for your input:
"On the face of this, it seems that SCO was quite willing to 're-use' any Linux source code needed to create LKP.
It is my hopes that this information may be a help to some writer of Linux kernel source code, who can cement down the code copied into LKP and answer the question: Did SCO copy Linux into UNIX?"
Thanks, lightsail. If this isn't a smoking gun you found, and by itself it isn't, it is the next best thing, a string to begin to pull.
|
|
|
|
| Authored by: Anonymous on Wednesday, September 24 2003 @ 01:03 AM EDT |
HP to indemnify Linux customers ... and not planning to pay SCO
http://biz.yahoo.com/ap/030923/na_fin_us_linux_threat_hp_2.html[ Reply to This | # ]
|
| |
| Authored by: Alex on Wednesday, September 24 2003 @ 01:04 AM EDT |
Don't forget the ComputerWorld interview with ex-SCO ceo Doug Michels:
Q: But you see Linux providing modules for SCO?
A: As far as I'm concerned, it's free R&D. A lot of developers who have
always preferred Unix are developing on Linux. The last thing in the world I
want is some cool app and have my customer go, "Oh, God, if I only had
Linux, I could get that app."
SCO's point of view hasn't evolved much from those days. I suspect they still
see Linux as "free R&D"
Alex[ Reply to This | # ]
|
- Wrong SCO! - Authored by: Anonymous on Wednesday, September 24 2003 @ 09:23 AM EDT
- Wrong SCO! - Authored by: Alex on Wednesday, September 24 2003 @ 10:04 AM EDT
| |
| Authored by: Newsome on Wednesday, September 24 2003 @ 01:26 AM EDT |
My favorite slide:
Slide 29 -
Currently, LKP uses a File Update
Daemon, fud
...
Fud is the solution of last resort!
HAHAAAA!
That's a good one.
Seriously, though. As someone who has done a fair
bit of coding, I'd have to say that something as complex as what they're
describing would be difficult to do without being sorely tempted to make life
easier by copying stuff from a system that works.
It is possible that those
40,000 lines of code are completely unique. Just recommending that customers
install Linux onto their OpenUnix system doesn't mean that they're breaking the
GPL. The GPL covers distribution, not use (or suggested use).
Even if they
did distribute Linux along with their OpenUnix systems, that wouldn't
necessarily be a violation either. It depends on how integrated the code
actually was. Just including the programs next to each other would be subject
to this paragraph of the GPL
(from the end of Term 2):
In addition, mere aggregation of another work
not based on the Program with the Program (or with a work based on the Program)
on a volume of a storage or distribution medium does not bring the other work
under the scope of this License.
All that said, I would really like to
see a code audit of what they've put into the LKP. I have my doubts that
they're clean. Even more doubts with this newly-found information. I'm
assuming everyone here is "recording" this stuff for posterity... ---
Frank
Sorenson [ Reply to This | # ]
|
| |
| Authored by: Anonymous on Wednesday, September 24 2003 @ 01:52 AM EDT |
| This looks exactly like the technique that the free BSD operating systems
(FreeBSD, NetBSD, OpenBSD) use to allow Linux binaries to run on them.
These
systems emulate the system call interface (which in nontechnical terms is the
gateway between user-level programs and libraries, and the kernel itself that
runs in privileged mode), but use an actual copy of the Linux shared libraries
and utilities (often called the Linux "userland") to provide the rest of the
GNU/Linux environment. No copy of the Linux kernel is needed.
But note that
SCO still either needs to provide GPL:ed code for the userland (with the ensuing
responsibility to distribute the GPL:ed sources), or provide some convenient
method for the use for installing it from an existing Linux distribution.
To
implement the system call interface, SCO has to look closely at how Linux works.
This however is not necessarily a copyright infringement, it is more like
reverse engineering, which is usually considered legal for interoperatibility
purposes.
I don't want to defend SCO, but I feel it is very important to
understand that a system like LKP can be implemented legally. If not, most free
emulator projects (e.g. Wine) would be in deep trouble as well!
[ Reply to This | # ]
|
| |
| Authored by: raph on Wednesday, September 24 2003 @ 02:21 AM EDT |
I looked over the presentation (using OpenOffice, which worked just fine :), and
don't believe there's much in the way of new evidence here. In particular, the
"full Linux distribution" seems to refer primarily to shared
libraries, shell utilities, and so on. The vast majority of applications do not
depend on kernel sources or binaries being present in the filesystem. The
obvious exception to this would be utilities for things like loading kernel
modules, but presumably those are not emulated by something like the LKP.
You can certainly interpret the words "full Linux distribution" as
prima facie evidence of copying. Darl and friends have certainly twisted our
words worse than that. I'd wait until real evidence comes to light, though.
And come to light it will. I think they'll have to cough up code during
discovery, if IBM asks for it. In the meantime, I would be quite certain they
have the resources to disassemble the SCO code and find snatches of copied code
if they're present. If nothing else, that will help them ask exactly the right
questions in discovery!
Thanks again for an amazing job, PJ.[ Reply to This | # ]
|
- Not a smoking gun - Authored by: mec on Wednesday, September 24 2003 @ 03:51 AM EDT
- Not magic? - Authored by: Anonymous on Wednesday, September 24 2003 @ 03:38 PM EDT
- Not magic? - Authored by: mec on Wednesday, September 24 2003 @ 06:24 PM EDT
| |
| Authored by: Anonymous on Wednesday, September 24 2003 @ 02:41 AM EDT |
In my view, I don't believe any wholesale copying of the Linux kernel has
necessarily happened in order to create the LKP. Let me explain.
The purpose of the LKP is to create a 'kernel interface' that looks enough
like Linux so that applications that are expecting to run under Linux will
function correctly.
To do this requires creating a 'psuedo kernel' that has the same interface as
the Linux Kernel, but translates all the 'system calls' into the necessary
system calls for the underlying OS (in this case Open*coughcough*UNIX). This is
exactly what the iBCS module under Linux does, creates a 'UNIX lookalike'
kernel so that SCO binaries can run under Linux.
Now, since the job of the LKP is to 'translate' system calls from one type to
another, it is HIGHLY unlikely that any code inside the Linux is going to be
useful. However...
It is VERY useful to examine the Linux code to determine the EXACT semantics of
the system call interfaces. Often documentation about how an interface works is
incomplete or outright wrong. Especially with Linux, code and interfaces change
at a pace more rapid than documentation can keep up. So, if I was writing the
LKP myself, I would certainly want the Linux source code around. I'll note that
simply using the Linux code as a 'documentation reference' is not a copyright
violation. (It might be a patent violation, but no patents are involved, here...
unless you include IBM, but let's not, for sake of discussion.)
BUt... it's unlikely that the actual CODE would be useful to my job. Because,
the OPERATION of each of the system calls is already implemented in UNIX, all I
need to do is translate a Linux call into one or more UNIX calls, and there's
certainly no code inside Linux that does that.
There is an exception to this.
If a particular Linux system call is exceptionally complex, and does a number of
things, which include calling 'simpler' system calls, it may be easier to just
lift the 'complex' code from Linux into UNIX and then do the translation for
the 'simpler' calls.
For example. Lets say system call 'A' does a whole bunch of work, but uses
system calls B, C, and D to 'finish the job'. Rather than implementing
translation layers for A through D, the LKP writers may have decided to lift the
Linux code for A, plonk that into LKP, and just write the translation layers for
B, C and D.
(As an aside: the more system calls you implement like this, the more your LKP
looks like a wholesale copy of Linux)
If any of THAT is going on, then that is certainly a violation of the GPL and/or
Copyright. I think this is possible, but not necessarily 'probable'.[ Reply to This | # ]
|
| |
| Authored by: Anonymous on Wednesday, September 24 2003 @ 02:41 AM EDT |
| Most of this actually seems to be confusion about what exactly is called 'Linux'
in those slides. I'm assuming they are actually talking about the combination of
kernel and userspace (system) applications. This is probably why Stallmann
insists on calling the combination of the two GNU/Linux (GNU project tools
running on a Linux kernel).
The GNU tools run on many proprietary systems,
I've personally used things like the gcc compiler on Solaris, Irix and Windows
NT/2000/XP (cygwin environment). No GPL issues as long as source is
provided.
The current contention is mostly around the kernel, so the places
that copying might have occured are,
- A kernel module for handling
system calls
- Three totally new Open UNIX filesystems [sic]
And my
guess is that those 3 new file systems are commonly used Linux file systems, one
of them is most likely ext2 which was most definitely developed for Linux and
definitely not copied from existing SysV or BSD file system. (internal design is
in many ways very different, good for many flamewars over the years)
And that's where I would be
looking. This is a place where the wheel was invented first in Linux (against
all 'common practice') and several years later brought into the LKP. Why spend
the effort reverse engineering the on-disk formats and doing a clean-room
implementation with all the potential for file corrupting bugs when already
debugged and proven reliable code is right there. Block/inode allocation
routines, the techniques used to avoid fragmentation, etc.
Also because ext2
is asynchronous there probably are some not always obvious constraints about how
some fundamental operations have to be ordered to be able to get a valid image
with the filesystem checker after an unclean shutdown (power failure, kernel
crash). f.i. how to clear out files that are being deleted and such. But I'm
sure Ted T'so would know more about that. [ Reply to This | # ]
|
| |
| Authored by: romana on Wednesday, September 24 2003 @ 03:03 AM EDT |
pj - the erin brokovich of open source? will julia play you, too, in the
assured, must watch geek top5 movie pj?:) keep up the good work! [ Reply to This | # ]
|
- Erin Brockovich - Authored by: Anonymous on Wednesday, September 24 2003 @ 03:17 AM EDT
| |
| Authored by: Anonymous on Wednesday, September 24 2003 @ 03:05 AM EDT |
|
And the infrastructure necessary to install all of these, and the whole of
Linux, onto Open UNIX" [emphasis added]
Install the whole of Linux onto
Open UNIX, you say? I think that's a GPL no no, unless you were desirous of
releasing the LKP under the GPL.
Nah, I think this is a red herring. I
think there's some confusion in the slides about "Linux the kernel" vs "Linux
the distribution". We should be calling the whole userspace "GNU"; that would
be libraries and binaries, etc. So the slide should read "copy the whole of GNU,
onto Open UNIX". That's perfectly acceptable under the license. For example,
Solaris ships with lots of GNU stuff (eg, bash) but that's all permitted by the
GPL.
3. Slide 12: “To work, this needs a full Linux distribution in
/linux”. The kernel is part of a full distribution. Does LKP contain a full
Linux distribution in the /linux folder of Open Unix, as the slide says it
"needs" to?
Sure, but it's allowed under the license.
which
states “copy this file to UNIX” when discussing the file: /lib/ld-linux.so.2.
Doesn't that make it appear the LKP developers were copying file directly from
Linux to UNIX? Otherwise, what does that sentence mean?
Which is also
allowed under the license.
Basically these are direct copies. The GPL
permits direct copies. You just have to provide source code when asked. Also
there's no kernel code (the *real* Linux) in any of the examples here.
This
doesn't mean that LKP hasn't ripped off Linux kernel code. Just that the slides
don't prove it either way.
More interesting are the slides later which talk
about lxprocfs and lxdevfs. Now those things are potential ripoff candidates
from the Linux kernel. Very suspicious.
nathanh [ Reply to This | # ]
|
| |
| Authored by: raph on Wednesday, September 24 2003 @ 03:34 AM EDT |
| There's a little more info about the
LKP on the Caldera website. The content is similar to the PPT presentation
linked in the article, but more detailed.
Depending on the system call
type, the LKP layer then does one of the following:
* ...
* It handles
the complete call itself. Ptrace is an example of a Linux system call that has
no close Open UNIX 8 equivalent.
* ...
If I were looking for
copied code, I might start with the implementation of ptrace. Another place to
look is suggested by this paragraph:
The LKP /linux/proc implements,
mostly in read-only mode, a subset of the files that Linux offers in its /proc
(procfs). That is, /linux/proc contains only a partial implementation of a Linux
/proc.
Again, this would probably be a good place to look for copied
code. It would certainly seem that they "implement" the Linux interface here in
essentially the same manner that Linux implements the Unix interface.
So
smoking guns, but a suggestion of where to look for one. [ Reply to This | # ]
|
| |
| Authored by: AG on Wednesday, September 24 2003 @ 03:40 AM EDT |
| Looking at the slides and the described architecture, the vast majority of the
code is not stuff you can copy from the linux kernel or other GPL software (all
the glue drivers & filesystems & daemons). However, if you do this sort of
emulation layer, you usually have a good look at the emulated target. A while
back I ported a minix emulation layer on some obscure realtime OS (both open
source, don't worry :-)). Usually what you do is to start out with the header
files of the emulated OS. You copy a struct here and a union there and put it in
your own code. Sure, you change formating, you rename things to fit your style,
but sometimes you are simply sloppy. I am not even sure this would really be
considered "copying" in the real world. However, SCO really has been an ass
about "code copying" and they showed 6-liners and claim thats worth $3bn.
That could indeed come back and bite them. If some programmer accidentally left
in some similar struct definition or maybe some useful macro, SCO is screwed.
You all remember the BSD case. Face it, shops like SCO hire rock bottom
engineers fresh from college. Sure, they have some old guys who help with the
design, but the majority of the hackers are cheap code monkeys from some foreign
country on a H1-B VISA (no offense, used to be in this position myself). Add
enormous time pressure (SCO was already falling apart back then) to get the
product done, and you have a good chance IBM's lawyers will dig up
something. Again, doesn't have to be much. A couple lines here, a couple
of lines there. If they are "obfuscated" (different names, different comments),
even worse! Those lying bastards did it intentionally! Hey, that's their own
argument. This is going to be so much fun. [ Reply to This | # ]
|
| |
| Authored by: Anonymous on Wednesday, September 24 2003 @ 05:03 AM EDT |
There is nothing in the presentation, which indicates that the Linux kernel
profile uses Linux kernel code.
The code showed is userspace code not UNIX kernel or Linux kernel code.
Please don't publish conclusions unless you are really sure about it.[ Reply to This | # ]
|
| |
| Authored by: Wesley_Parish on Wednesday, September 24 2003 @ 05:55 AM EDT |
| It's interesting to see how different the Unix and the GNU
C libraries
actually are - "write", Slide 6. So RMS'
insistence on making GNU completely
different to Unix,
did happen. And Slide 8 goes and says that the write
example is the simplest case! Then you get the
other Slides stating that
UNIX and Linux don't agree
much over device major and minor numbers ... - and
SCO's insistence that Linux needed to copy stuff over
from Unix to be able to
compete in the ferocious
enterprise world, looks decidedly flimsy and
threadbare
- rather like facing an Antarctic blizzard in a T-shirt and
shorts and bare feet. Not the way the Emperor Penguin
does winter! In
short, I don't see that
there's much proof of SCO's copying Linux into Unix in
this series of slides, but there's a lot of stuff that kicks
sand in SCO's
management's face over the question of
code copying from Unix into Linux.
Slides 26 and 27,
giving the algorithms used by Unix and Linux, merely dig
it in deeper. ---
finagement: The Vampire's veins and Pacific
torturers stretching back through his own season. Well, cutting like a child on
one of these states of view, I duck [ Reply to This | # ]
|
| |
| Authored by: Anonymous on Wednesday, September 24 2003 @ 06:05 AM EDT |
<quote>
Currently, LKP uses a File Update Daemon, FUD
...
FUD is the solution of last resort!
</quote>
[ Reply to This | # ]
|
| |
| Authored by: kbwojo on Wednesday, September 24 2003 @ 06:31 AM EDT |
Now that we have made the rounds in the news we have announced ourselves to the
world. There are some who may come here and disagree with what we have to offer
and I think that is fine if done with dignity and if any replies are done with
dignity. There are some people though that will not have that dignity and others
that will try to do nothing more than to disrupt this site and we should try to
keep this in mind if or when we respond to such a person. When someone is rude,
you might try responding with politeness to see if it's just somebody in a bad
mood. However, if the person persists in being rude, the only way to deal with
this is to not to respond to them. Lets keep this site a place for information,
not a battle ground of words.[ Reply to This | # ]
|
| |
| Authored by: robvarga on Wednesday, September 24 2003 @ 08:59 AM EDT |
After looking through the slides, my opinion is the following:
1. The filesystems mentioned here has nothing to do with filesystems as a way of
storing things, rather it is a way of presenting and modifying configuration
settings and runtime variables, like for example /proc in Linux.
2. The Linux kernel itself is not in LKP. That alone is however what is not
there. The GNU Glibc must be there, compiled for the actual processor
architecture so that the machine code of the compiled version would actually
run. I actually don't know the exact hardware architecture of machines OpenUNIX
ships with, if they are quite normal x86 machines, the GLibc may not need to be
recompiled.
3. The Kernel functionality is provided to GLibc and other libraries through
constructs like software interrupts and gates. These are provided by hardware.
This information is in Linux. The LKP code part handles these interrupts. LKP
code must also be able to invoke Linux programs from UNIX code, and send signals
to them (information flow from UNIX to Linux via LKP). This is mandatory
functionality of the LKP.
3.1 The information on which specific interrupt maps to which specific function
is defined in the Linux kernel.
This information MAY ONLY USED AS INFORMATION AND NOT AS CODE.
3.2 To achieve this functionality legally, THEY MUST HAVE A CLEAN-ROOM
REIMPLEMENTATION BY THEMSELVES, OR IMPLEMENTATION BY SOMEONE ELSE WHICH THEY CAN
LEGALLY USE, eg. something published under BSD License (and for that they have
to KEEP the original copyright notices in source).
This is an area which can be investigated.
3.3 However, if instead of this, they used the dispatching code for this from
the Linux kernel (which is always the most up-to-date, since new features are
ever introduced), they MUST PROVIDE THE SOURCES FOR THIS COMPONENT AND EVERY
COMPONENT WHICH IT IS LINKED TO IT (USES THIS COMPONENT TO LINK TO).
3.4 The biggest argument in the development of the Linux kernel has always been
this: what is linked together with something and what is not? Tipically if
something is a product which uses a library or other code without which it
cannot operate, but which can operate without the product,
the other code (which operates without the product) is not necessary to be
published under GPL. However, if the two are linked together in the same
software, and that binary is incapable to operate according to the specification
without the product being there, than the software IS LINKED TO the product, and
therefore its sources must be published under the GPL.
3.5 Because of 3, I think it can be safely assumed that the Linux kernel
personality is not capable to operate without the code that acts as an interface
between the LKP and the Linux libraries, because the code level information
flow, eg. sending signals could not be provided from UNIX to LINUX. That means,
that according to 3.4 this code (i.e. the whole LKP) IS LINKED TOGETHER AND FORM
A SINGLE PRODUCT with the component interface between the LKP and the Linux
libraries and binaries.
Therefore if this is implemented the way described in case 3.3 (the dispatch
functionality is lifted from Linux, or derived from GPL code in the Linux
kernel), then, I think, the whole LKP IS VIOLATING THE GPL licence, since it
itself is not published under the GPL, even though it links against lifted GPL
code, or contains code derived from GPL code, hence making it a derivative of
GPL code which must be distributed at least under the GPL (the newly added parts
may be distributed under an other license as well, besides the GPL, but the GPL
distribution is mandatory) if ever distributed.
4. They should have a complete Linux distribution in place for Linux programs to
be usable on one of the OpenUnix storage filesystems. This can be achieved two
ways:
4.1 Provide a bootstrap archive of a working Linux distribution lacking the
kernel, which contain all programs necessary to install all necessary additional
stuff. This is essentially a core distribution. They MUST BE ABLE TO LEGALLY
DISTRIBUTE this bootstrap archive which is binary redistribution of the core of
a Linux distribution. This is probably the core archive of the OpenLinux, and
probably contains only GPL or BSD licensed programs. This archive files IS A
BINARY PRODUCT.
4.1.1 If this archive contains ANY code which is distributed under the GPL, they
have to provide this archive UNDER THE GPL. That means that this archive CAN BE
REDISTRIBUTED UNDER THE GPL. That also means that the sources to this archive
must be provided.
The sources in this case means ALL STUFF NECESSARY TO CREATE THAT ARCHIVE FILE.
That means that all files in the archive must be provided in binary form. That
also means redistribution for each of those files. That means sources for any
GPL-ed files in the archive must be provided.
That also means that any scripts used to build that archive is to be provided
(under the GPL). I don't know whether they provide these scripts.
4.2 The other possibility is that the LKP is capable of using an existing
installed Linux from a separate partition. In this case a bootstrap archive is
not provided. However there is two requirements to this:
4.2.1. A Linux distribution must be installed to this partition. That means
drivers to handle the hardware in this machine must be provided to the Linux
kernel in the Linux distribution to be installed.
4.2.2 The LKP personality MUST BE ABLE TO ACCESS THE STORAGE FILESYSTEM THE
LINUX SYSTEM IS INSTALLED ON. I think, ALL FILESYSTEMS WHICH LINUX IS CAPABLE TO
INSTALL UPON ARE GPL-ED. And they are a moving target. EITHER LKP contains a
clean room reimplementation or a BSD-licensed implementation of code accessing
the filesystem which the Linux system is installed on, and from here the same
stuff as in 3.
5. Since there are a couple of programs, which expect a certain specific flavor
and version of the Linux kernel, e.g. Rational Clearcase server requires a
specific Red Hat kernel (Linux kernel with Red Hat patches), it does not work
with stock kernels, if they don't use the Linux kernel binaries provided by
other distributors.
That also means, that THEY CANNOT PROVIDE FULL COMPATIBILITY TO EACH AND EVERY
LINUX PROGRAM with their own code only, if we can find two programs for which it
is impossible to compile a kernel on which both will run. That's because LKP
mimics the behaviour of one specific compiled Linux kernel, and those hypotetic
two programs cannot work with one common kernel configuration.
That means, that they EITHER FALSELY ADVERTISE FULL LINUX COMPATIBILITY (THIS IS
THE PROBABLE CASE), OR THEY MUST BE USING EXISTING KERNEL BINARIES (contrary is
suggested by the slides).
This is my opinion on the slides.
Regards,
Robert Varga
[ Reply to This | # ]
|
| |
| Authored by: Anonymous on Wednesday, September 24 2003 @ 09:31 AM EDT |
Don't forget this article from Steven Vaughan-Nichols
http://www.practical-tech.com/business/b06122003.htm
--------------------------------------
I've known for about a week now-known, not assumed, not
puzzled it out, known-that SCO had mixed Linux code into Unix. I
know it because a source I trusted who was in a position to
know had told me that had been the case.
I haven't written it up as news though because the person
who's told me this doesn't want their name used and I haven't
been able to get anyone else who was at SCO in those days to
confirm or deny the story. [ Reply to This | # ]
|
| |
| Authored by: Anonymous on Wednesday, September 24 2003 @ 10:22 AM EDT |
Sorry sub req to read the WSJ but here a link I found on a network site
http://www.nwfusion.com/news/2003/0924reporhpto.html
|:|
[ Reply to This | # ]
|
| |
| Authored by: Anonymous on Wednesday, September 24 2003 @ 10:40 AM EDT |
From: U know who...
THIS is further proof!
THAT - Innocent 3rd party users of LINUX (even today) -
bought or acquired their copies of LINUX all while SCO watched, said nothing,
and did nothing FOR YEARS!
The slides do show that SCO knew LINUX and UNIX inside and out FOR YEARS and
YEARS!
IF, SCO is an IP principle of LINUX (as they claim but have not proved) then,
via acquiescence, or otherwise, via their actual, apparent, or ostensible agents
that were distributing all LINUX code for years. SCO KNEW or should have KNOWN
better. AND if they didn't then their stockholders should be getting
representation RIGHT NOW.
FACT: SCO is still allowing LINUX to be distributed with just the Linux GPL
attached AND without any SCO license attached.
Innocent 3rd party customers have been using LINUX right along with SCO's full
approval and knowledge of the terms that it was being distributed under - the
Linux version of the GPL. For SCO to attempt to bill, invoice or harm these
users (after they have legally acquired their LINUX, and a Linux with perpetual
rights regarding support, upgrade, etc) ...is against the LAW! Good Faith
still has value![ Reply to This | # ]
|
| |
| Authored by: murphyatgenome on Wednesday, September 24 2003 @ 10:48 AM EDT |
For reasons that others have already mentioned, this is one of the
few groklaw posts that are embarrassing because of incorrectness
(about the implications of the GPL). Please change this article
ASAP; it makes Groklaw look bad: superficially this article suffers
from the same diseases that most mainstream "analysts'" articles
do: insufficient depth of understanding complicated by distorting
biases.[ Reply to This | # ]
|
| |
| Authored by: Lee on Wednesday, September 24 2003 @ 11:33 AM EDT |
| I don't know if anyone else caught this, but on Slide 29 there is a reference to
FUD - the LPK's File Update Daemon.
And there is a bullet point that says,
ironically:
Fud is the solution of last resort!
I don't know, it made
me laugh... [ Reply to This | # ]
|
| |
| Authored by: Anonymous on Wednesday, September 24 2003 @ 11:39 AM EDT |
Google +sco +udi +drivers
Check the LKP faq at www.sco.com
Digging around you can find that the porting recommendation is to add UDI
interfaces to existing driver module sources.
Viola: UnixWare(TM Open Group) and Solaris (TM SUN) drivers.[ Reply to This | # ]
|
| |
| Authored by: jre on Wednesday, September 24 2003 @ 12:05 PM EDT |
PJ - Regarding your comment:
"Here's hoping IBM asks to see the source
code of LKP and Open UNIX as part of the discovery process, to get to the bottom
of this question."
This seems obvious, and it must have come up before,
but I don't recall seeing the answer: In discovery, can (for example) IBM demand
to see a source package which compiles to binaries identical to those
distributed, e.g. with the same md5sums?[ Reply to This | # ]
|
| |
| Authored by: ZeusLegion on Wednesday, September 24 2003 @ 12:19 PM EDT |
http://ir.sco.com/ReleaseDetail.cfm?ReleaseID=118689
I wonder if HP was the third potential Licensee seeing as they supported
SCOForum and have been in bed with the criminal mafia group known as SCO.
---
Z[ Reply to This | # ]
|
| |
| Authored by: snakekiller on Wednesday, September 24 2003 @ 12:50 PM EDT |
| This has appeared on the Utah court papers re sco vs ibm [ Reply to This | # ]
|
| |
| Authored by: Anonymous on Wednesday, September 24 2003 @ 02:44 PM EDT |
Normally I love the groklaw analyses but I have to agree with other posters that
this one is misinformed.
Having a copy of the linux userland libraries (ld-linux.so, glibc, etc) to link
linux binaries against would be perfectly legal (and inevidible if you're going
to run dynamically-linked programs) The only way you'd get in GPL trouble is
if you modified the libraries and didn't distribute your changes (and it's
unlikely that the LKP did that)
The only place where there is a chance that GPL problems happened is if SCO used
pieces of the GPL'ed linux kernel to implement their LKP kernel modifications.
I really don't think that this is a large possibility, however - this layer
would mostly just be a "shim" rearranging arguments from linux
syscalls into the unixware equivelants (for reference see Linux's SunOS and
Solaris emulation layers; similar things exist in the *BSD's including a rather
extensive linux-emulation layer) Any code similarity that pops up would likely
be small sections which are similar just because they're implementing a common,
public API.
That isn't to say that it's IMPOSSIBLE that SCO copied extensive pieces of
GPLed code into their kernel but I don't see anything that makes it look
likely. Also remember that the LKP work was mostly done by "old
SCO" (i.e. Santa Cruz Operation, not SCO Group a/k/a Caldera) Santa Cruz
Operation was a decent company - I have no reason to suspect that they were
blatently disregarding the GPL. They certainly had understanding of the GPL;
they even contributed code to GNU products like GCC.
IANAL, but IAAKE (I am a kernel engineer)[ Reply to This | # ]
|
| |
| Authored by: Anonymous on Wednesday, September 24 2003 @ 04:49 PM EDT |
This string illustrates the danger of litigation. Some experts will say one
thing and others will say the opposite. The decision will then be made by the
jury off the nearby streets.
Remember you guys are looking at slides. The evidence will be the actual code.
Experts will opine and then have to demonstrate on the computer what they say.
webster[ Reply to This | # ]
|
| |
| Authored by: Anonymous on Wednesday, September 24 2003 @ 05:40 PM EDT |
Surely they weren't suggesting that a SCO user was supposed to copy a Linux
shared object library onto a SCO UNIX system. After all, isn't that the first
stink that SCO raised a couple of years ago? That users were switching from SCO
to Linux and copying SCO libraries onto their newly installed Linux system so
that their old SCO UNIX software would run?
If they are suggesting
that, well the hypocracy is nothing short of breathtaking!
And if this new
means of running Linux software under SCO UNIX requires a full LInux
distribution in order to work, just how is this different from something like,
say, Wine? This ain't much of an ``Innovation'' if all this is a Wine-like
clone.
And just how does this run Linux code that 1000X faster that was
asserted in some articles just a few weeks ago? (Not that that claim didn't peg
most everyone's bogon detector.)
(`Innovation' is a registered trademark of
Microsoft.)
[ Reply to This | # ]
|
| |
| Authored by: shaun on Wednesday, September 24 2003 @ 05:41 PM EDT |
OT but powerful
Reliance on Microsoft Called Risk to U.S. Security
http://story.news.yahoo.com/news?tmpl=story&cid=581&ncid=581&e=1&
;u=/nm/20030924/tc_nm/tech_security_microsoft_dc
It's things like this that tell me there is a god.
--Shaun[ Reply to This | # ]
|
| |
| Authored by: lightsail on Thursday, September 25 2003 @ 11:57 AM EDT |
Please accept my gratitude for the thoughtful and thorough analysis of this
submission. The article was submitted so that the details that it contained
could be reviewed by others that have much more intimate knowledge of the
internals of Linux and UNIX that I have. I certainly have a much better
perspective on the situation as a result. The overall perception of the comments
is that no proof of any violation of the GPL is shown in the presentation, but
that the possibility exists that Linux kernel code may have been used to
recreate some Linux functionality within LKP.
The complex legal area of derivative works could be redefined by the cases
between SCO and IBM or Red Hat. SCO claims control over independently developed
works based on the inclusion with a licensed UNIX. Some have pointed to that LKP
cannot function without GPL software being linked to the modified UNIX kernel.
The structuring of GPL and UNIX licensed within a single functioning operating
system may have created a derivative work based on incompatible licenses. Does
LKP require linked GPL licensed source code to be compiled as part of the
binaries that are LKP? Is GPL code intrinsically embedded within the LKP? If the
LKP cannot work without the GPL Licensed code must it also be released under GPL
license also?
lightsail
[ Reply to This | # ]
|
| |
| Authored by: Scott_Lazar on Thursday, September 25 2003 @ 11:57 PM EDT |
An interview with Ransom Love on E-Week:
http://www.eweek.com/article2/0,4149,1300367,00.asp
---
LINUX - Visibly superior![ Reply to This | # ]
|
|
|
|
|
