Posted on 06/11/2003 10:08:38 AM PDT by shadowman99
Edited on 04/13/2004 2:58:58 AM PDT by Jim Robinson. [history]
Some members of the open-source community are claiming that the SCO Group may have violated the terms of the GNU GPL (General Public License) by incorporating source code from the Linux kernel into the Linux Kernel Personality feature found in SCO Unix without giving the changes back to the community or displaying copyright notices attributing the code to Linux.
(Excerpt) Read more at eweek.com ...
I have a feeling SCO doesn't know where their code comes from. BSD people, you should be trying to see the source is question as well.
The LKP provides a Linux kernel interface to Open UNIX 8. The LKP is not an emulator; rather, Linux kernel functions are mapped into equivalent Open UNIX 8 kernel functions. The LKP runtime environment, from an application point-of-view, is the same as as a Caldera OpenLinux runtime environment -- Linux applications do not ``know'' that they are running on a Open UNIX 8 kernel. The LKP includes standard Linux libraries, runtime components and user commands.
The main differences between native Linux and the LKP are in the kernel and data structures themselves, which are based on Open UNIX 8 for the LKP.
The System Call Interface
Normally, native Open UNIX 8 processes enter the kernel through a mechanism known to Intel CPUs as a ``call gate''. Linux binaries, however, use a different mechanism known as an ``int80'' software interrupt. This difference provides the means by which Open UNIX 8 distinguishes between UNIX and Linux processes.
Native Open UNIX 8 processes do not issue int80 interrupts. If the LKP is not installed, the Open UNIX 8 kernel terminates any process that makes an int80 call.
If the LKP is installed, the Open UNIX 8 kernel traps int80 interrupts, understanding them to be Linux process requests for kernel functions. When a process executes an int80 instruction, the Open UNIX 8 kernel marks it as a Linux process and moves it into a Linux working environment. In effect, the kernel switches personality from Open UNIX 8 to Linux for that process.
For each int80 software interrupt it receives, the LKP layer of the Open UNIX 8 kernel identifies the type of call, and retrieves its arguments. Depending on the system call type, the LKP layer then does one of the following:
When the call is complete, the Open UNIX 8 kernel sends the results back to the caller process
This is how many operating system emulators or run-time environments work. In fact, SCO used to release compatibility libraries for Linux, that did the exact opposite of the LKP kit, they let you run SCO binaries under Linux. SCO binaries were told to use the compatibility libraries, and in turn they would trap system calls from the running program and interpret them into Linux-style system calls. Linux would return a result to the emulation layer, and in turn the result would be handed back to the running program in the right format. These libraries were proprietary software written and owned by SCO, here is a blurb from SCO's page for the SCO System V for Linux:
SCO is committed to help grow your business. This commitment includes helping customers to just try out or actually deploy new technologies at the lowest cost and with minimal resources. For everyone who has been thinking about deploying Linux solutions but wants to protect their investment in legacy SCO UNIX applications, SCO has the answer. It's SCO System V for Linux Release 1: SCO UNIX Runtime Libraries.
This new SCO product is a license to use SCO UNIX shared libraries on Linux. The combination of SCO libraries plus the Linux ABI allows most SCO UNIX binary applications to run on Linux.
SCO has suspended this product as well.
The crux of the matter is whether Linux code somehow got into SCO or vice versa. Now, I haven't see the SCO code in question, but like everybody I have an opinion.
SCO is free to redistribute Linux without modifications. This means that the run-time binaries that Linux needs can be included in their LKP kit. The SCO software part of the equastion is the run-time library which intercepts Linux system calls and translates them into SCO system calls, and as above gets the results from UNIX and re-translates them back into Linux calls.
From reading the article, it seems to me that there is some question as to how the translation layer was written:
During that project we often came across sections of code that looked very similar, in fact we wondered why even variable names were identical.
There is nothing wrong with using the same names for the system calls, but I would be suspicious if the same varible names appeared in the SCO source as in the Linux source. This seems to imply a certian laziness on the part of SCO when it came to the system calls that we similar enough to not require much translation.
SCO's response?
That is a false notion. SCO also never used any of the Linux kernel code in the LKP and thus has not violated the GPL. We have also never contributed Unix source code to the Linux kernel
Interesting, because contributing code to the Linux kernel is exactly what they are accusing IBM of doing.
Maybe these are the 80 lines that turned out to be the same? :)
Assuming you can read, kindly note that the complaint was that incorporating linux source without attributing it violated the GNU license.
I was just responding in kind to a personal attack. Thanks for your concern.
Disclaimer: Opinions posted on Free Republic are those of the individual posters and do not necessarily represent the opinion of Free Republic or its management. All materials posted herein are protected by copyright law and the exemption for fair use of copyrighted works.