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
Linux File System Structure
Tuesday, July 04 2006 @ 05:10 PM EDT

In the previous article on STREAMS, LiS, and Caldera's Netware for Linux, I mentioned the book, "Special Edition - Using Caldera OpenLinux," written by several Caldera employees in 1999. As it happens, the same book has a section on "The Linux File System Structure." As you will recall, SCO's expert, Dr. Thomas Cargill, has opined that "Linux is a substantial copy of UNIX System V Release 4 ("SVr4") because it appropriated the essential structure of UNIX by incorporating (1) many of the "system calls" in SVr4; (2) the SVr4 file system; (3) the ELF format; and (4) the Streams communication module. (Id. at 3-4.)." On that basis, SCO is claiming copyright infringement.

I think STREAMS was pretty much knocked off the list by the evidence we found for that article. What about the structure of file systems? Was Caldera aware back in 1999 that the Linux file system resembled Unix?

Here's what the book says on that point:

The Linux File System Structure The Linux file system is very similar to the standard UNIX file system layout, but of course there are some differences. The key to understanding the Linux file system is to first understand the underlying structure.... The Linux directory structure, which is very similar to UNIX or DOS, is designed as a tree hierarchy....

Linux File System Standard (FHS)

The OpenLinux file system hierarchy is based on, for the most part, the File System Hierarchy Standard (FHS). In the Fall of 1993, an effort began to restructure the file and directory layout of Linux. This project began as the File System Standards, or FSSTND, project. After several iterations as the FSSTND project, the scope was widened to include issues that were general to other UNIX-like operating systems. In view of this expanded focus, the project was renamed the File System Hierarchy Standard (FHS).

Many people have contributed to this effort, but the primary person behind it is Daniel Quinlan. As of this writing, the most current version of the FHS documentation was version 2.0, dated October 26, 1997. It can be obtained from ftp://tsx-11.mit.edu/pub/linux/docs/linux-standards/fsstnd. Dan also currently serves as the chairman of the steering committee for the Linux Standard Base group to develop and promote a set of standards that increase the compatibility between Linux distributions.

So Caldera knew at least in 1999 that the two file systems' structures were similar, and it worked to make OpenLinux precisely Unix-like. (FHS.) Of course, the entire world knew, as IBM points out in its Reply Memorandum in Support of Motion to Confine SCO's Claims to, and Strike Allegations in Excess of, the Final Disclosures, (footnote 4) what Linux's file system was like from its inception:

...SCO claims that the Linux file system infringes SCO’s alleged copyrights. Through Mr. Cargill, SCO complains that the Linux file system has characteristics similar to the file-system of UNIX System V, such as hierarchical files, a single tree of directories and no imposed structure. These have been features of Linux since its inception, much like wheels, doors and brakes have long been features of a car.

Whatever Linux does, it does it in broad daylight. Caldera not only could have gone to look on the Internet, it distributed its own distribution of Linux. It knew precisely that Linux has file-system features similar to those of UNIX System V. Caldera not only didn't sue or protest, it supported LSB strongly, and as you can see in this article from 2002, Caldera OpenLinux 3.1.1 was LSB certified. Here's SCO's press release about it, then calling itself Caldera International, Inc. I think seeking LSB certification would qualify as a mistake, from the standpoint of now wanting to sue over file system structure. The time to sue was back in 1999, when the Caldera employees noted the similarity between Unix and Linux, or earlier when Linux was being developed in the open air on the Internet. Instead, Caldera joined the Linux Standard Base (LSB) Project, which was "an attempt to define the common core of components that can be expected to be found in any 'Linux' system," as this joint announcement, signed by Caldera's then-CEO Ransom Love among many others, expressed it in 1998:

The signers of this proposal are most of the leading commercial Linux distributions, board members of Linux International, and key personnel like Linus Torvalds, the creator of Linux. We propose a set of goals and the organization for this project, and invite all other Linux distributions to join us in planning the project and carrying it out.

The "base system" is the set of programs, libraries and files that are essential to every Linux system. These objects and their related file formats play a supporting role for every application. Examples of this include (but are probably not limited to) the C library, the format and placement of system files, and other necessary interfaces. Linux distributions traditionally do not distinguish themselves on these interfaces, they distinguish themselves in other categories, such as the applications on their system, quality and ease of installation, and quality and ease of systems administration as well as support for users. Linux distributions should maintain the base system collectively, as the kernel is maintained, rather than individually.

The Linux Standard Base project will provide a vendor-neutral standard, backed by source code, upon which to build Linux distributions, much as the Linux kernel project provides a single kernel that is shared by all distributions. This standard base will be distributed as a reference platform from which Linux distributions may be derived and which application producers may use for testing, but it will _never_ be targeted to be an end-user solution in itself, as that is the role of the Linux distributions that incorporate the standard.

The application of the standard will be that any program that runs successfully on the reference platform can be expected to run on all Linux systems. If they don't, the distribution creator must either fix a problem with their own distribution, or convince us that there's a bug in the sample distribution which violates the standards. This is not intended to prohibit distributions from making their own extensions to the base system, or even to use different source code from what is supplied in the reference platform - it's only meant to provide a common set of features that will be known to exist on every Linux system which ISVs can depend on. Participation in the base standard will assure the distributions of compatibility with each other for the set of applications that depend only on the files and libraries in the reference platform. As time passes, the standard will expand to include most of the files and libraries upon which a commercial application might depend.

The Linux Standard Base System will be 100% compliant with the Open Source Definition. This assures all distributions that they can derive from it without concern over licensing problems for themselves or their users. Development will be carried out in the public, with anonymous access to the CVS archive and the developer mailing lists. The core group will be a mix of high-quality developers from the Linux community and the staff of commercial distributions, with an organization similar to the tremendously successful Linux kernel development team. Attention will be paid to standards such as POSIX and the FHS (the successor to the Linux Filesystem Standard). However, the project goes far beyond the utility of these standards, because rather than produce only paper documents, it will provide a complete implementation of the standard, ready to be integrated into Linux distributions or used as a reference platform for application developers. This will provide the Linux distributions with improved time-to-market, lower cost, and much less duplication of effort than a paper standard which is defined to fully take into account side effects, undocumented issues, etc....

We, the undersigned, endorse this proposal, and ask that other distributions and ISVs also join us to help further define this proposal and then to help implement it:

Linus Torvalds, Creator of Linux

Jon A. Hall, Executive Director, Linux International

Bruce Perens, Director Linux International, proposed Project Leader

Ransom H. Love, Director Linux International, General Manager, OpenLinux Division, Caldera, Inc.

Roland Dyroff, Director Linux International, S.u.S.E. Linux....

As you can see, both Caldera and SuSE joined with Linus in working on this project. And in Caldera's old documentation for OpenLinux, in Chapter 2, The Linux Development Environment, it told the world this (actually, it still is, because the document is still available on its website to this day:

LSB, the Linux Standard Base, is a pending standard aimed at enhancing application portability across Linux systems; this is discussed more later in this chapter. At the time of publication, the LSB standard has not been officially released so no operating system can legitimately claim conformance to it, but many changes have been made to OpenLinux 3.1 to match dictums that seem highly likely to be in the final LSB standard.

Most software that you develop needs to be packaged and productized for installation on production systems, and Chapter 8 gives an overview of the facilities used for this. Any software you release should include documentation. OpenLinux includes several documentation frameworks you can use, all of which are extensible. Chapter 8 also includes information about how to add your documentation to the appropriate framework....

2.4. Linux Standards Base (LSB)

The Linux Standards Base (LSB) is an industry-wide initiative to define an application standard for all Linux distributions. Major components of the LSB include the Linux kernel, GNU software, and XFree86. When LSB is completed, an application that is built and packaged to conform to LSB can be installed and run on any LSB-compliant system.

LSB is done under the auspices of the Free Standards Group (www.freestandards.org), who has also produced the Linux Development Platform Specification (LDPS) as an interim standard that can enhance application portability that is being developed now, before LSB is completed.

For more information and to access preliminary versions of the LSB test suites, go to the www.linuxbase.org web page.

2.4.1. LSB Modifications in OpenLinux 3.1

Modifications have been made in OpenLinux 3.1 to conform to what we expect the final LSB specification to define. Caldera does not claim LSB conformance for OpenLinux 3.1 in any way, but we expect that these changes will smooth the transition to LSB-conformant releases.

In 2000, Caldera also joined, along with IBM, SUSE, Red Hat, oldSCO, and the Open Group, the Free Standards Group. What was that? This press release explains:

Free Standards Group

Linux Standard for Software Development Moves Closer to Reality; Linux Standard Base and Linux Internationalization Initiative Incorporate, Gain Support from All Segments of Industry

Business Editors/High-Tech Writers

SANTA CLARA, Calif.--(BUSINESS WIRE)--May 8, 2000--The Linux Standard Base (LSB) and Linux Internationalization Initiative (LI18NUX) announced today that they have incorporated under the name Free Standards Group. The newly formed Free Standards Group was organized to accelerate the use and acceptance of open source technologies through the application, development and promotion of interoperability standards for open source development.

The Free Standards Group has received endorsements from a growing number of industry corporations as well as from public interest groups such as the Debian Project. These milestones move the group significantly closer to its goal of creating a single Linux standard.

The Free Standards Group will draw upon its LSB and LI18NUX roots to ensure that the Linux operating system does not fall victim to fragmentation, breaking into multiple versions, each of which is supported by only selected applications. To prevent that, the Free Standards Group's members are promoting a specification, which, when implemented, will mean that any LSB-compliant application will run successfully on any LSB-compliant Linux distributions. While sensitive to the idea that Linux development should not be stifled, the group is working to define a common subset of Linux that will work for everyone, regardless of distribution.

With its incorporation and its commitment from key players in the industry, the Free Standards Group will be able to place additional resources behind the LSB and LI18NUX.

"The Free Standards Group's efforts will be an important component of the continued success of open source," said Linus Torvalds, Linux creator. "Standards such as the LSB and Li18nux help bring different companies and groups together to solve common problems and will help to advance Linux in a good way."

Daniel Quinlan, chair of the standards group, commented, "Our progress over the last few months has been significant. Key companies and organizations are lining up behind us and the resources and funding we need to achieve our goals are coming in place. We have everything we need to move forward quickly in increasing compatibility among Linux and other open source distributions and in helping to support software vendors and developers to port and write software for open source such as Linux."

Members of the Free Standards Group's list of supporters include:

Atipa Linux Solutions
Caldera Systems
Corel Corporation
The Debian Project
Delix Computer
Enhanced Software Technologies, Inc.
IBM
Linuxcare
Linux for Power PC
Linuxmall.com
Linux Professional Institute
Metro Link
Open Group
Red Hat, Inc.
SAP AG
SCO
SGI
Software in the Public Interest, Inc.
Sun Microsystems
SuSE Linux AG
TurboLinux
VA Linux Systems

About the Free Standards Group

The Free Standards Group is a nonprofit corporation organized to accelerate the use and acceptance of open source technologies through the application, development and promotion of interoperability standards. It encompasses the Linux Standard Base (www.linuxbase.org) and the Linux Internationalization Initiative (www.li18nux.org.)

The Linux Standard Base was formed in 1998 to develop and promote a set of standards that will increase compatibility among Linux distributions and enable software applications to run on any compliant Linux system.

The Linux Internationalization Initiative is focused on software and application portability and interoperability in the International context.

To learn more about the Free Standards Group, please visit our web site at http://www.freestandards.org.

Quotes from Supporters of the Free Standards Group

"First, a philosophical question. Is there freedom in restriction? In this case, yes. By supporting the Free Standards Group, Linux distributors are free to add unique value to Linux without breaking applications. We free developers to reach a broader audience. And most important, customers are free to purchase Linux solutions that fit their needs without fear that their applications will have compatibility problems." Ransom Love, President and CEO, Caldera Systems ...

Now The SCO Group wishes to turn around and sue members of this very group for following the very standards Caldera helped to establish and encouraged developers to adopt. I think you can figure out for youselves how likely it is that such a strategy will fly in any courtroom. If you were on the jury, what would you be thinking? That's exactly what any judge or jury will be thinking also.

Further, if you look on page 21 of the Caldera OpenLinux book, you find this:

This is what makes Linux such a wonderful operating system. It is open, it is available to everyone, and nobody can steal it or make it proprietary.

Developers and vendors and end users no doubt relied upon Caldera's representations that Linux was not only free to use, it was safe to do so.

While you are at Caldera's documentation site, you might like to check out Caldera's page on UnixWare's standards conformance (or Google's cache, because it is faster.) What do we see on the list, among other things? ABI, ELF, and COFF. SCO Group just can't win for losing. Doesn't anybody there know about Caldera? It's like SCO had a lobotomy or a stroke or something and has lost its longterm corporate memory.


  


Linux File System Structure | 271 comments | Create New Account
Comments belong to whoever posts them. Please notify us of inappropriate comments.
Corrections here
Authored by: MathFox on Tuesday, July 04 2006 @ 05:29 PM EDT
So that Pamela can find them in a single swoop.

---
If an axiomatic system can be proven to be consistent and complete from within
itself, then it is inconsistent.

[ Reply to This | # ]

Off Topic
Authored by: MathFox on Tuesday, July 04 2006 @ 05:33 PM EDT
Other Open Source and Legal issues are welcome in this thread. If you refer to
an external article, please make a link and give a summary. Hint: links work
best when the comment is in HTML mode.

---
If an axiomatic system can be proven to be consistent and complete from within
itself, then it is inconsistent.

[ Reply to This | # ]

Linux File System Structure
Authored by: Anonymous on Tuesday, July 04 2006 @ 05:43 PM EDT
IBM-717 fotnote 4:

"For example, SCO claims that the Linux file system infringes SCO’s alleged
copyrights. Through Mr. Cargill, SCO complains that the Linux file system has
characteristics similar to the file-system of UNIX System V, such as
hierarchical files, a single tree of directories and no imposed structure. These
have been features of Linux since its inception, much like wheels, doors and
brakes have long been features of a car."

I suppose "a single tree of directories" means that it doesn't have
A:>, C:> etc. like Windows. Looks like a strange copright claim to me
:-)

[ Reply to This | # ]

Legal question
Authored by: Jude on Tuesday, July 04 2006 @ 06:08 PM EDT
I'm thinking back to the apparently pointless complexity of the OldSCO/Caldera
merger/spinoff/whateveritwas. Is there some way that NewSCO can use this to
claim to have shed the part of Caldera that entered into the agreements
discussed in PJ's article?

[ Reply to This | # ]

Ambiguous?
Authored by: rsmith on Tuesday, July 04 2006 @ 06:15 PM EDT

The term "SVr4 file system" can have two meanings:

1) the software used for storing files on disk, see e.g. the definition on Wikipedia. SVr4 uses UFS aka FFS.

2) the layout of the directory trees and their contents, as it is interpreted in this article.

From the context, it's not clear to me what which one is referenced in this case. There is an empty "a" tag without a "href" around the word "opinied" in the article, so I'm not sure which story is supposed to be referenced here.

Both possibilities are weak, IMHO.

As argued, the specific layout of the directory tree is certainly an evolved standard, and not something that SCO and it's alleged predecessors in interest created by themselves.

The filesystem that SVr4 uses (FFS) evolved at Berkeley from the original unix FS. The 4.4BSD-Lite release of 1994 was freely redistributable [source: The design and implementation of the FreeBSD Operating System by McKusick and Neville-Neil]. Most of this code comes from Berkeley, if any original unix FS code remains. SCO will have a hard time getting a complaint of copyright infringement to stick.

---
Intellectual Property is an oxymoron.

[ Reply to This | # ]

Linux File System Structure
Authored by: BsAtHome on Tuesday, July 04 2006 @ 06:26 PM EDT
That "single directory structure" thingy bothers me. Every Unix and lookalike has exactly that same structure. Look at *BSD, Minix, ... Everybody has the same basic structure where /, /{bin,lib,tmp,usr,dev,mnt,etc,var}/... is present and all have the same function. Even most utilities and under the hood divisions have similar layout. This has been a general part of unix almost since its inception. Nobody can now complain anymore because everybody in the whole world, including Caldera/SCO, copied it.

The whole expert report smells more and more to be FUD and nothing more.

---
SCOop of the day

[ Reply to This | # ]

pj, you figured out why Caldera Openlinux failed!
Authored by: kawabago on Tuesday, July 04 2006 @ 06:28 PM EDT
Nobody at Caldera knew what it was, so even they couldn't get it working!

[ Reply to This | # ]

Multics
Authored by: Anonymous on Tuesday, July 04 2006 @ 07:01 PM EDT

As I understand the issues most of the ideas about the Unix file system came
from Multics and MIT's CTSS. In fact this is acknowledged in the 1978 Bell
System Tech Journal in an article by Ritchie:

"In many ways, UNIX is a very conservative system. Only a handful of ideas
are genuinely new. In fact, a good case can be made that it is in essence a
modern implementation of M.I.T.'s CTSS system."

"This particularly simple way of viewing files was suggested by the Multics
I/O system."

Such things as the inode structure, the directory file and even the file system
'single tree' come from Multics.


At the end of the article there is a section:

"""XI. RECOMMENDATIONS

The following points are earnestly recommended to designers of operating
systems:

(1) There is really no excuse for not providing a hierarchically arranged file
syatem. ..."""

[ Reply to This | # ]

Lobotomy or a stroke?
Authored by: Anonymous on Tuesday, July 04 2006 @ 07:38 PM EDT
No. I think just lack of judgement on Darl McBride and other SCO execs. SCO
used to be a decent little company with a good product line -- just needed
better management at the top.

They were approached by Microsoft with this brilliant idea now they are
travelling downhill in a car with no brakes. SCO could have said no and simply
revamped its business model. This whole thing will stop when either when the
judge rules on it or when Microsoft rolls out "Vista" and other new
products at the beginning of the year (PIPE ferries and other under-the-table
payments dry up).

There's just no case in this case. Except for the sealed disclosures which the
public doesn't know yet, all of the other Linux arguments lack any merit
whatsoever since they freely distributed Linux and all related code at will.

For SCO to survive as a going concern at this point they should attempt to
settle with IBM, Red Hat, Novell, et al. Moving forward with these suits will
be certain death for them. Wonder if SCO stockholders could demand this? They
couldn't all be falling for the "company line" on this disaster.

This is no longer a lottery with a $5 billion jackpot! As if it ever was.



[ Reply to This | # ]

Linux File System Structure
Authored by: chris_bloke on Tuesday, July 04 2006 @ 08:27 PM EDT
Caldera were aware of, and soliciting involvement in, FHS and LSB issues with 32/64-bit coexistance on IA-64 (Itanic) in 2001.

[ Reply to This | # ]

Linux File System Structure
Authored by: chris_bloke on Tuesday, July 04 2006 @ 08:35 PM EDT

Caldera Germany were also actively involved in the LSB and FHS standard process, to the extent of writing proposals for Chapter 16 of the FHS and being involved in LSB conference calls on their proposals for LSB library and linker locations.

[ Reply to This | # ]

The Shell Game
Authored by: joef on Tuesday, July 04 2006 @ 08:45 PM EDT
Said PJ: "Doesn't anybody there know about Caldera? It's like SCO had a
lobotomy or a stroke or something and has lost its longterm corporate
memory." The shell game of various incarnations of Caldera were cleverly
designed to confuse outsiders as to who is the real SCO, "the successor in
interest" to AT&T. They have succeeded so well that those on the
inside of this deal are true believers of their own myth. Or at least they
profess to so believe. If questioned, they ask, "who's this
Caldera?"

Methinks we outsiders at Groklaw are a bit more enlightened.

[ Reply to This | # ]

BSD has a similar structure
Authored by: Anonymous on Tuesday, July 04 2006 @ 08:48 PM EDT

BSD has a similar structure too. So the AT&T/BSD settlement is relevant and probably removes most of SCO's claim.

Excluding pollution from BSD, SCO are only left with /proc as a clear case of SysV filesystem layout adopted by Linux. And USL were well aware of that: Dennis Richie commented that Linux's text-based /proc was a more in the UNIX spirit than SysV's own binary-based /proc.

--gdt

[ Reply to This | # ]

Linux File System Structure - NOT introduced by IBM
Authored by: Anonymous on Tuesday, July 04 2006 @ 09:12 PM EDT
I think everyone is missing the point here.

My understanding is that IBM has contributed material
to Linux only within the last 6-7 years.

The file structure was implemented very early in the
Linux development.

IBM's Lawyers will have a 4 point test for the Judges
to refer to when concidering their decision on IBM Linux
activities.

[ Reply to This | # ]

Hierarchical files existed even in Multics in 1960s!
Authored by: Anonymous on Wednesday, July 05 2006 @ 12:37 AM EDT
Multics Features
A General-Purpose File System

[ Reply to This | # ]

FHS probably not relevant
Authored by: elcorton on Wednesday, July 05 2006 @ 01:29 AM EDT

While it's true that SCO is estopped from claiming infringement in Linux based on structural similarity to SVR4, I don't think the term "file system" as used by Cargill refers to the hierarchy of files in FHS. That wouldn't be part of Linux proper. Rather, I think Cargill is talking about similarities in the kernel code that implements file I/O; things like ext2 and ext3, which are perform the same function as UFS in UNIX (and BSD.) SCO could not have developed, distributed, and supported both Linux and UNIX from 2001 to 2003 without being aware of those similiarities. But the argument that FHS is a published standard is beside the point.

[ Reply to This | # ]

bottom line: needs to be more specific
Authored by: xtifr on Wednesday, July 05 2006 @ 01:37 AM EDT

The ultimate problem is that the claim, "appropriated [...] the SVr4 file system," is much too vague! Does it refer to the general structure? Inodes, links and mount-points? (Too broad a claim, many other systems use the same or similar structure.) Does it refer to some specific feature or features used by the SVr4 filesystem, but not found in (say) BSD? And if so, what? Or does it refer to the common layout of names and directories? (Executables in /bin and /usr/bin, libraries in /lib and /usr/lib, configuration and misc. files in /etc, and so on.) Again, very common to many systems--I used use a similar structure under MS-DOS with the MKS Toolkit!

Much like the nearly-200 claims that were thrown out recently, it's going to be impossible for IBM (or us) to defend against charges of "appropriating [...] the SVr4 file system" without knowing what, exactly, SCO & Cargill have in mind here. We could list hundreds of features of the SVr4 file system that are found in other systems, and clearly part of open standards and even the public domain, and still have SCO turn around and say, "no, that's not what we meant, so you must be admitting that our claims are true". Unless the judge, as with the previous claims, throws this nonsense out, there's no way to defend against it. ELF and STREAMS are, at least, something fairly specific. "The SVr4 file system" is not.

The most obvious defense is, like STREAMS, the fact that Linux doesn't use the SVr4 file system!1 In fact, unlike STREAMS, I don't think there have ever been any versions of Linux that ever used the SVr4 file system. But whether that simple fact is enough to defend against...whatever it is that Cargill thinks he's claiming, is impossible to say.

1 At least, I was never able to get Linux to read any of my Solaris partitions on my old Sparcstation, and I spent a fair amount of time trying. And I believe that older versions of Solaris (like the one I've got) simply use the SVr4 file system by default.

---
Do not meddle in the affairs of Wizards, for it makes them soggy and hard to light.

[ Reply to This | # ]

  • UFS works fine - Authored by: Anonymous on Saturday, July 08 2006 @ 07:43 PM EDT
Linux: (authorized) derivative works or an independant creating
Authored by: Anonymous on Wednesday, July 05 2006 @ 01:50 AM EDT
The STREAMS and this article are interesting, but they only address half of the
problem:

Dr. Thomas Cargill has opined that "Linux is a substantial copy of UNIX
System V Release 4 ("SVr4")".

The articles have shown that - even if this was true - it wouldn't matter,
because any copying was authorized.

But it would be a second class victory: Every other open source project would be
threatened by a similar lawsuit, e.g. Adobe could claim that GIMP is derived
from Photoshop, because it implements the same file formats and supports similar
filters.

I hope the courts finds that the findings from Dr. Cargill are not sufficient to
establish the status of "derived works". I'd love to see the rebuttal
expert testemonies, they hopefully address that point.

[ Reply to This | # ]

Linux File System Structure
Authored by: Anonymous on Wednesday, July 05 2006 @ 03:10 AM EDT
Like all the other claims made by SCOG is utterly and completely irrelevent in
my opinion.

What is happening here, which has backfired since day one, is an attack on the
FOSS *process*. This theory was well laid out in Halloween I.

For those unfamiliar with the Halloween series <a
href="http://www.catb.org/~esr/halloween/">here</a> ya go.

krp

[ Reply to This | # ]

Linux File System Structure
Authored by: kjhambrick on Wednesday, July 05 2006 @ 03:33 AM EDT
Seems like most (if not all) attributes of the UNIX filesystem were defined way back in the mid-1960s for the MULTICS system: A General-Purpose File System For Secondary Storage

-- kjh (reposted as HTML Formatted)

[ Reply to This | # ]

Linux File I/O subsystem and filesystems
Authored by: cybervegan on Wednesday, July 05 2006 @ 05:51 AM EDT
I also (like many others have noted) get the impression that SCOG are also
referring to the mechanics of creating and managing files in a hierarchical
structure via system calls (such as creat(), mkdir(), etc.) and the
"methods and concepts" involved in storing this information on a
physical medium - i.e. the "filesystem", e.g. ext2, jfs, etc.

It may be useful to compare the similarities of Linux and Unix at these levels,
with other operating systems which had a hierarchical filesystem prior to the
existence of Linux - such as MSDOS 2 onwards, OS/2, Novell Netware 2 and above,
and MacOS with it's HFS. The Amiga should also make an appearance; there are no
doubt others I don't know about.

In any Hierarchical File System, there is a limited set of basic functions that
manage the contents of the tree, thus any HFS system will implement these as a
*minimum* - therefore these concepts as a base, must be unprotectable, because
they are necessary to the functioning of such a system.

-cybervegan

---
Software source code is a bit like underwear - you only want to show it off in
public if it's clean and tidy. Refusal could be due to embarrassment or shame...

[ Reply to This | # ]

Linux File System Structure
Authored by: Alan(UK) on Wednesday, July 05 2006 @ 06:11 AM EDT
IANAL

To claim copyright infringement, SCO must:

1) Show that a hierarchical file structure was not an obvious way of arranging
files - I do not think that they could prove it was not the most obvious way.

2) Given that the ideal filing system will hide all the dirty details of the
physical mechanism, tracks, sectors, fragmentation, from the user - show that
one single tree structure is not obvious - and given that you want to hide the
drives themselves, I would think that it is the most obvious.

3) Show that the Linux File System Structure was actually copied from UNIX -
unless 1 & 2 above are proved, I would think that it is meaningless to talk
of copying unless the actual code was copied.

4) Show that the UNIX File System Structure had not been formally been made
available for public use, or if not formally, then informally by failing to
point out that it formed the basis of all modern filing systems over several
decades.

4) Show that the UNIX File System Structure was actually developed for UNIX and
not copied from elsewhere.

5) Show that methods and concepts are copyrightable.

6) Show that valid copyrights exist for the UNIX File System Structure.

7) Show that SCO owns those copyrights.

[ Reply to This | # ]

Linux File System Structure
Authored by: Anonymous on Wednesday, July 05 2006 @ 06:15 AM EDT
"Linux is a substantial copy of UNIX System V Release 4 ("SVr4")
"

The similarities mentioned are so tiny part of the kernel or operating systemen,
that it 'substantial' is nonsense.

Beside if the sco can claim any right ont these items and if the similarities
are illegal copied.

[ Reply to This | # ]

Discovery Question
Authored by: ExcludedMiddle on Wednesday, July 05 2006 @ 12:17 PM EDT
Now that discovery is over, let's just say that PJ finds something that IBM
lawyers missed that invalidates some claim that SCO makes. Let's also
hypothesize that it wasn't included in as evidence by IBM during this discovery
period. Is it inadmissible?

[ Reply to This | # ]

If only we knew.
Authored by: rsteinmetz70112 on Wednesday, July 05 2006 @ 02:36 PM EDT
IF only we knew what SCOG has put into their sealed documents. When I started
this comment there were 239 comments, many of them relating to the development
of Unix and it predecessors, with some medical digressions thrown in.

The experience and knowledge gathered here truly a sounding.

Unfortunately we only see shadows and impressions of what SCOG has actually
claimed. The claim to the Unix SYS Vr4 file system is like that. We can't say
for certain exactly what their claim includes.

---
Rsteinmetz - IANAL therefore my opinions are illegal.

"I could be wrong now, but I don't think so."
Randy Newman - The Title Theme from Monk

[ Reply to This | # ]

Linux File System Structure
Authored by: wwells on Wednesday, July 05 2006 @ 08:29 PM EDT
This whole thing about Linux having similarities to the SVr4 file system is a
bit of a red herring. The ext2 file system was released in the early 90's and
was a very good implementation of a traditional Unix style file system. It took
the orginal ext file system and added many of the features of the Berkley FFS
file system.

Even if SCO could somehow contrive a violation (methods or copyright), this
happened in the early 90's, not during the time period covered by this case!

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