Letters to the editor

...and if SCO is right...? My suggestion:

Fellow Readers,
 
        I'm not a lawyer so take the following with a grain of salt. I do know
a little bit about the law and I seem to recall a process called
discovery. IBM should find out exactly what pieces of code SCO claims
ownership of. It would then be a simple matter to sort through the LKML
and find out who submitted the patch. Then most likely that person
never had access to the code in question. Failing that, it shouldn't be
too difficult for the hacker in question to give an explanation of the
code's origin. Specifically what itch he was trying to scratch with
it. It would be even better if the author could find some of the
original patches. You know the ones that are so alpha you'd be
embarrassed to have them to be seen in public.
 
        There is also the unfortunate possibility that the code in question is
indeed hijacked. If that is the case then a kernel cleansing needs to
happen as soon as possible. The possibility of SCO changing the license
on the code in question is not really a possibility. They *CAN'T*
change the license while they are fighting this court case; it would
invalidate the case and it would be dismissed. And Linux can't wait for
the completion of a court case to proceed.
 
        IBM needs to ask for an injunction or something to force SCO to reveal
whether they are claiming the code in its entirety or a substantial part
thereof. If they are only claiming that portions of the code have been
hijacked then they should not be allowed to slow or stop the Linux
juggernaut. They should be forced to reveal the parts of the kernel
that they are making a claim on so that they can be quickly excised from
the kernel on the grounds that any delay will cause irreparable harm to
itself and all of the other companies with Linux strategies.
 
        I think that the lawyers involved will be surprised by exactly how fast
the community is going to fix this problem once it is fully out in the
light. The only really bad possibility is if they can prove that a
major subsystem has been infringed; like the 'elf' file type. Most
likely it will end up being a few corner cases though. I do have one
question though: when we change the error "Printer on fire" to "Printer
exploded" do we have to notify The Department of Homeland Security of a
terrorist event every time the error is returned?
 
Just my Thoughts
Tres
 
--
Tres Melton <class5@pacbell.net>

Comments (1 posted)

Re: SCO the "owner" of the UNIX operating system

Dear LWN
 
Regarding SCO's positioning on UNIX, The Open Group would like to make
it clear that SCO holds the rights only to the operating system source
code originally licensed by AT&T and does not own the UNIX trademark
itself or definition of what a UNIX system is.
 
Reference to the SCO web site show that they own certain
intellectual property and they correctly attribute the trademark.
SCO has never owned "UNIX".
 
In 1994 Novell (who had acquired the UNIX systems business of AT&T/USL)
decided to get out of that business. Rather than sell the business as a
single entity, Novell transferred the rights to the UNIX trademark and the
specification (that subsequently became the Single UNIX Specification)
to The Open Group (at the time X/Open Company). Simultaneously, it
sold the UNIX source code and the product implementation (UNIXWARE)
to SCO. The Open Group also owns the trademark UNIXWARE, transferred to
them from SCO more recently.
 
As the owner of the UNIX trademark, The Open Group has separated the
UNIX trademark from any actual code stream itself, thus allowing multiple
implementations. Since the introduction of the Single UNIX Specification,
there has been a single, open, consensus specification that defines the
requirements for a conformant UNIX system.
 
There is also a mark, or brand, that is used to identify those products
that have been certified as conforming to the Single UNIX Specification,
initially UNIX 93, followed subsequently by UNIX 95, UNIX 98 and now
UNIX 03. Both the specification and the UNIX trademark are managed and held
in trust for the industry by The Open Group. SCO, along with all other
vendors of UNIX systems (regardless of whether they are members of The
Open Group or not), distribute a UNIX system that has been certified
through the X/Open and The Open Group certification process.
 
The Open Group is committed to working with the community to further the
development of standards conformant systems by evolving and maintaining
the Single UNIX Specification and participation in the Linux Standard Base.
 
For further discussion on SCO's IP Claim please also see:
<http://mozillaquest.com/Linux03/ScoSource-02_Story01.html>
<http://mozillaquest.com/Linux03/ScoSource-02_Story04.html>
 
For the Austin Group see:
<http://www.opengroup.org/austin/>
 
For LSB certification and testing information see:
<http://www.opengroup.org/lsb/cert/>
<http://www.opengroup.org/testing/lsb-test/>
 
For the UNIX System Web site see:
<http://www.unix.org/>
 
-----
Andrew Josey
Director of Certification
The Open Group

Comments (none posted)

Letter to the editor: Legally Defining Access

Defining Computer Access
------------------------
 
>
> * "Access" should be interpreted broadly. "...I
> propose that a user accesses a computer any time the
> user sends a command to that computer that the
> computer executes. In effect, I would define access as
> any successful interaction with the computer." Pinging
> the computer, or reaching a login screen, would be
> sufficient.
>
> * The definition of "unauthorized" should be much more
> narrow. "I propose that courts limit access 'without
> authorization' to accesses that circumvent
> restrictions by code. Breaches of regulation by
> contract should as a matter of law be held to be
> insufficient grounds for access to be considered
> 'without authorization.'"
>
 
The broad definition of computer access is correct. The
narrow definition of authorized access needs some work
though. What is "circumventing" exactly? If a piece of
code, due to a human error in the programmer's thinking,
allows access by some means other "typical access", then
can we really say that a circumvention has happened? The
intent of the code is exactly how the code executes on
that CPU.
 
As a parallel, if a company finds a loophole in a
contract, then that company can exploit the loophole and
be immune to a law suite. If a hacker finds a loophole in
a piece of code, then similarly, he should be allowed to
use that loophole without having to think about how the
programmer may have intended that code to behave.
 
Put otherwise, a "restriction by code" cannot be defined
in any meaningful way. It implies that code execution does
not implement the algorithm that the code defines!! What
the code does and does not restrict is open to
interpretation only by the CPU of the machine. The CPU is
impartial, therefore we can assume that if a person did
"hack" a machine then that the code did intend it!!!
 
You can only really define access by the human processes
needed to set up an access. For example, unauthorized
access could be defined to access through impersonating
someone elses creditials: i.e. stealing a login or access
key that was not intended to be used by you.
 
Under the definition of "...circmvent..." stealing a
password is allowed! :-)
 

Comments (9 posted)

Page editor: Jonathan Corbet