Slashdot Mirror

I don't see it as hypocrisy on their part. The FSF, contrary to many peoples' perceptions of them here on /. are more pragmatic than most people here give them credit for. In the case of Ogg Vorbis, the problem was the MP3 format is as deeply entrenched as the GIF format, and just as encumbered by patents. By using a more permissive license like The modified BSD-style license rather than the GPL, they would be encouraging proprietary software to use the Ogg Vorbis format, so that the patent-unencumbered Ogg Vorbis format could more quickly gain an edge over MP3 than were it GPLed.

The FSF and RMS have always understood that software patents are a graver threat to Free Software than proprietary software. If some proprietary software company like Microsoft decides not to support use of Ogg Vorbis because the code is GPL and thus cannot be taken proprietary, that would serve to further entrench the MP3 format, which is even more counterproductive to the cause of Free Software, as it is a format that cannot be used by Free Software. RMS justifies this strategy in another post.

It's not hypocrisy, but pragmatism that drives these decisions.

I have to correct myself a bit here. The Ogg Vorbis toolkit was originally licensed under the GPL, from what I remember, and they later shifted to a BSD-style license, which move was not begrudgingly accepted by RMS and the rest of the Free Software Foundation. They actively encouraged the move, IIRC, as Ogg Vorbis is a technologically superior format unencumbered by patents, unlike the dominant MP3 format, for which a legal codec would be impossible for Free Software (LAME and Bladeenc are legally a gray area, and that isn't a good thing). Think GIF vs. PNG. RMS and the FSF have always understood that software patents pose an even greater threat to the cause of Free Software than proprietary software does. The GPL is designed to protect against software from going proprietary, but is of no help at all when dealing with patents (for which there can be no effective legal defense, short of having your own cross-licensable patent pool or having software patents abolished totally, which the FSF and the LPF are actively working to do).

Care to give a link that shows that RMS and the Free Software Foundation did not fully endorse Xiph's decision to move the licensing from GPL to BSD-style? Another link I've found, again RMS's own words, shows more pragmatism than anything. For reference, here's the original link from which i got the first RMS quote.

You are right of course that yes, rare are the cases where another license would serve the cause of Free Software better than the GPL would, but these cases are not unknown. For another example, someone else points out that the FSF actually discourages people from GPLing components at the core of the X Window System. The FSF as a whole and even Stallman in particular are not as inflexible and unpragmatic as many here seem to think.

Thanks, AC. That's even better. Plain text = searchable and easy on the bandwidth. For those of you flying under the radar:

AC sez-
The full text of the agreement can also be found at lwn.

The full text of the agreement can also be found at lwn.

Evidence from SCO's own website:

from the license faq:
I have Linux servers deployed in my organization. What options do I have besides purchasing a SCO IP license?
There are 3 options for you to evaluate:
You have the option to do nothing, adopt a "wait and see" attitude, and hope that SCO is not serious about enforcing its intellectual property rights in the end user community.
You can replace all servers, desktop and embedded uses of Linux.
You can obtain a license from SCO to use SCO IP in binary form in Linux distributions

SCO is committed to protect and defend their intellectual property and believes that the most cost effective remedy is to purchase the necessary SCO UNIX IP license. However, the action you take should be based on the recommendation of your own legal counsel.

Let's see, you can either hope we don't sic Boies on you, interrupt your business, or pay us. Oh, and by the way, we are serious about suing you.

from the license itself:

2.1 Provided Company complies fully with this Grant of Rights and
Obligations, SCO will not consider such use of the SCO Product licensed
by Company under this Agreement to be in violation of SCO's intellectual
property ownership or rights.

This is the only thing they're offering in exchange for the license fee. The IP in quesion is disputed, which they state as factual.

Extortion and Fraud. It's a classic protection racket, plain and simple.

• Techweb: RealNetworks Takes Open-Source Player Seriously
  
• Linux Weekly News: RealNetworks launches Helix Player project
  
• Google News search for "RealNetworks" and "Linux"
  

• Company shall not reverse engineer or decompile, translate, create derivative works or modify any of the SCO Product.

With respect to people who got Linux from the SCO/Caldera site, this would be a pretty clear violation of the GPL.

Why doesn't SCO offer an IP License for Linux to the Linux distribution companies so that they can bundle SCO IP with their Linux distribution?
The SCO compliance program is an end-user program for the right to use SCO IP in binary format. The IP License for Linux does not grant distribution rights, nor does it grant any rights associated with source code. SCO doesn't offer a license to cure the infringement on the part of the Linux distributor because SCO's source license agreement directly conflicts with the GPL.

This link in LWN provides the text of SCO's "Linux license".

Enjoy.

One of the LWN posters raise a very interesting question:

> > SCO WARRANTS THAT IT IS EMPOWERED TO GRANT THE
> > RIGHTS GRANTED HEREIN.
>
> Does this mean that SCO is definitely claiming
> to own some rights over the a GNU/Linux system,
> and that anyone who buys this license can sue
> them when they turn out not to have any such
> "intellectual property"?

Very interesting, indeed.

Nothing against Gentoo, but let's give credit where credit it due. It's going to be a long time before Gentoo can be lumped in with the above distros.

Like the LWN Distribution list of Leading Distributions.

In the face of SCO's continuing FUD without providing any substance, Red Hat had no choice whatsoever in this matter. They either file suit to either force SCO to disclose the relevant information, or they go quietly into the night.

It's satisfying to see that their claims are basically the ones I said (2, 3 ) could be brought against SCO

It's really nice to make things like that proper hotlinks...

Just after brief reading http://lwn.net/images/ns/rh-complaint.pdf I have opinion - court may refuse to process this case. This is because most of complaint talks about "Linux" but in legal world only "Linux" itself or empowered person can sue SCO. In legal meaning "RedHat" is nobody but some third person from street and can't sue SCO for "Linux". If "RedHat" is hurt, this is OK but current claim speaks mostly about "Linux" and this is not OK. I am not native Engish speaker nor lawyer, so I can be wrong either.
http://no.spam.ee/~tonu/

Obviously Red Hat has been paying attention to the arguments made on /. "SCO itself, however, has been publicly distributing the LINUX operating system, including the LINUX code, for at least five years. Regcognizing the inconsistency between its claim of "trade secret" missapropriation and its public disclosures of the same allegedly secret information, in May 2003 SCO public stated it would no longer disribute LINUX. However, that statement too is false. SCO continues to offer LINUX source code for public downloading today- more than four months after SCO sued IBM for disclosing UNIX "trade secrets" that SCO coninues to disclose itself." http://lwn.net/images/ns/rh-complaint.pdf

The actual complaint, not linked from the story, can be found here.

You failed to mention that the paper also demonstrates that ext3 does not scale with the number of processors. I bet the bottleneck is the (single?) journal file.

The bottleneck is that ext3 uses the big kernel lock instead of fine-grained locking.

With this book, if your devices aren't anything too obscure (i.e. it fits in a traditional class of device) it will be easy. It is a fairly straight forward book.

(You may also want to look at the porting to the 2.6 kernel series that has been written over at Linux Weekly News As an aside, I'd really advocate subscribing there.)

When your device is a new class of device that linux isn't used to, it can be harder (e.g. when the phonejack cards came to linux, a new api for them had to be made).

Note, I've only limited experience, but this is what I've observed.

Such as when he wrote this:

From: Linus Torvalds

To: Daniel Phillips

Subject: Re: large page patch (fwd) (fwd)

Date: Sun, 11 Aug 2002 15:55:08 -0700 (PDT)

Cc: Alan Cox , , , David Mosberger , "David S. Miller" , , , ,

On Mon, 12 Aug 2002, Daniel Phillips wrote:
>
> It goes on in this vein. I suggest all vm hackers have a close look at
> this. Yes, it's stupid, but we can't just ignore it.

Actually, we can, and I will.

I do not look up any patents on _principle_, because (a) it's a horrible
waste of time and (b) I don't want to know.

The fact is, technical people are better off not looking at patents. If
you don't know what they cover and where they are, you won't be knowingly
infringing on them. If somebody sues you, you change the algorithm or you
just hire a hit-man to whack the stupid git.

Linus

Linux wins again.
Seriously though there's even a Farsi version of Knoppix.

This might prove interesting.. I found it hard to know where in the discussion to tuck it, but here seems good since Linus touches on the part of "new features" and so on.

here at lwn

Actually yes, it "runs Linux." While it's nothing unique to 2.5, there is user-mode-linux. For 2.5, there is Kexec. It's interesting that at least one co-lo service is hosted on a UML configuration (see the isp-colo list).

Brings new light to "Yes, it runs Linux."

Someone asked me what I meant by "amortize" in my thoughts on Balancing the Swinging the Seesaw. Since I'm fond of metaphors, I dragged yet another one (home mortgages) into play.

Amortize: "To write off an expenditure for (office equipment, for example) by prorating over a certain period."

When I think about an application, there's a certain expenditure one must make with respect to design. I can do it quick and cheap now and incur most of the cost later when I'm confronted with issues of scalability, interop, and extensibility. Or I can spend a time at the start by modeling and designing for flexibility and extensibility, and consequently avoid compound interest in the future. Think of purchasing an old fixer-upper home: you can select from a couple of properties on the market. First, you want something with the a sound footing and an inexpensive price. Also, you'll probably need a mortgage. The smaller the down payment, the larger the total cost. So ideally, you want your down payment to be as large a portion of the total price as possible. But, your initial cash reserve is limited, so you commit to your down payment and then you can at least move in and start fixing the house and increasing its value. Same thing with applications! In the end you want to move in and improve where most needed, but you also want something with a sound architectural footing. That's a balancing act, though sometimes there's design principles and technologies that lessen (win/win) immediate and future costs. RDF has a great architectural footing those who don't like it are doomed to reinvent it poorly but an immediate/localized cost of comprehension. For example, in RSS 1.0 the order semantic of RDF sequences imposes a cost without much benefit. It's a sequence, but you don't know what sort of sequence: a mandatory RDF artifact for an optional feature doesn't make much sense to me.

Plus, in the great marketplace of ideas, no single design/technology is guaranteed to succeed. Spending too much time on any single technology at the start might be an unwise investment. (Torvalds' theory on design and project management is useful reading on this note.)

Worse, as you begin to try to standardize coding of your configure.in and Makefile.in files, it begins to dawn on you just how much more boilerplate could be automatically generated.

Ergo, automake.

However, by the time I started learning the syntax for automake and tried to figure out just exactly how libtool can magically make shared library construction and maintenance a cross-platform reality, I get tired of the whole damn business and think: there has got to be a better way.

I don't know that SCons is that better way, because the problem it has to solve is complicated.

Personally, I had high hopes that the software carpentry project would have chosen some of the XML features of Tan by David Ascher - specifically, having a way for the build to query the system for some information about the best place to find previously installed software.

Fancy autoconf m4 macros (clever, but ugly) can indeed check for existing installations of other packages and accepting user-specified overrides, but somehow it seems to me that having some databases (XML, but simple enough to edit by hand) to describe how you want the build to look for packages is better than specifying 8 options like --with-ssl-include-dir=/some/long/path, etc.

Finally, despite being a Python fan, I've always been skeptical about whether the SCons approach to replacing Bourne shell with the admittedly more powerful language was really a good idea, mainly because of the broader availability of sh.

But time has made less relevant those systems on which Python cannot be built, so perhaps my concerns are overstated.

Nevertheless, if you want to build Python, I notice that it uses autoconf:)

Maybe if Python had a module that could crank out Bourne shell like m4 does, but without the ugly m4 syntax?

Kexec is a patch that allows you to reboot a kernel from another kernel that is likely to be a part of later 2.5/2.6 kernels. It's maintained by Eric Biederman and can be downloaded here.

LWN has a brief article about kexec here

Care to enlighten us on what that work is? My guess is a server environment where a fully functioning, mass mass market ready OS isn't needed.

Dude, MS-Windows XP has proven to be a mass mass market OS for gaming; and simple word processing; and conveyer of various worms, viruses, and trojans. Although it's more stable than MS-Windows 2000, as a server OS it still requires rebooting, or it becomes unstable after just a few weeks.

I guess MS workers are just more interested in what they're doing then. How else do you explain Linux having been around fot 50% more time and not being even close to done?

This is silly. Saying Linux has been around for 50% more time is both misleading and incorrect. Claiming the current iteration of Linux is like the version 1.0 kernel is like saying MS-Windows XP is based on MS-Windows 3.0.

And you *still* haven't outlined the ways in which Linux is unfinished. What is your definition of "finished?" If you mean, "as in finished all the function goals defined in the road map and ready for the mass market," to which road map do you refer? And, how do you know Linux has not met it's road map by that definition?

BTW, there *is* a road map for Linux. Before every development branch, Linus announces his goals for the development kernel. Yes, he accepts other goals, as well; but they do not get incorporated unless they fit with his goals.

In fact, I would dare say Linux has clearer, better-defined goals than MS-Windows. For instance, what is the road map of Longhorn?

For a taste of the Linux 2.5 road map as seen at the outset, see this article at LWN.

I guess you must have been hired by them at one time then.

Nope. I've hated Microsoft's business tactics and shoddy software for years (since 1991, to be exact). Wouldn't work for them. But I know a lot of people who *do* work for them. I know that MS makes technical decisions based on marketing requirements; I know they curse the release schedule, because *they* don't like shipping broken products (which a couple of them have called both MS-Win2k and XP).

Care to enlighten us on what that work is? My guess is a server environment where a fully functioning, mass mass market ready OS isn't needed.

Simple. We are using X terminals that are about 9 years old. I'm installing some more computing capacity in the server room, because our users have outstripped the current set of servers.

How do I upgrade the computing power of 300 X Terminals? Add a single computer. Those X terminals can now run applications seamlessly and transperantly off the new server; the users don't even realize there *has* been an upgrade. (And, yes, this is a full GUI system. Don't let the term "terminal" throw you off.)

And it sure beats the hell out of upgrading and maintaining 300 PCs based on MS-Windows.

Sure, MS-Windows might be user-oriented. But Unix is *business* oriented, and has out-performed and out-gunned MS-Windows for 15 years now.

Now, here's where you'll say, "But MS-Windows is installed on more desktops, making it the best!" This is, in essence, the basis of your argument already (by calling MS-Windows "Mass Market"). But big deal? Budwieser is the best-selling beer. Christina Aguelera (sp) outsells Radiohead. The Ford Pinto was once the best-selling car.

What's this prove? That often, the best-selling article is guilded crap. For those of us who have experienced the beautifully-veneered shackles of MS-Windows after using operating systems that are both powerful and flexible, the mass-appeal of MS-Windows is exactly like drowning in Budwieser.

Linux Weekly News just released (today) an interesting interview with Gaël Duval, the creator of Mandrake Linux. He covers topics such as the Mandrake Club business model, Linux on the desktop and the SCO lawsuit, and others. It's on: http://lwn.net/Articles/38405/

Once it stopped appearing daily on all the news sites around, everything would calm down a bit, and the case would generally be seen as a private law suit about trade secrets between two companies having a long history of cross-licensing agreements, i.e. nothing that extraordinary.

But I see that at least some news sites seem to have started understanding this already:

We unsuccessfully tried to ignore the SCO v. IBM fracas, mostly because ...

and

We know just how you feel (lwn.net commenting on the above quote from Linux journal...)

Found it!

linux in 143KB

I knew someone else out there was sadistic as I am in trying to get linux down to almost nothing in size and still work :-)

and they have a distro now!

Since no one came up with any better research i thought i would share this, which was the only substantial discussion i was able to find of RCU patent & copyright history:

http://lwn.net/Articles/36164/

Slashdot - stealing LWN stories for fun and profit since 1998

If I am not mistaken, barring the device discovery and control part, everything is already known, has a widely known standard, and is already interoperable. With the exception of DRM which is marked as "Proprietary/Vertical". Will that mean that Sony DRM stuff (which will work on a Montavista Linux Based platform will not be displayed on my Longhorn PC? That's crazy.

And what if this become a "standard" like Motif or CDE? (Yeah, a bloated, cumbersome standard, that Micrsoft will replace with something suited for her whims instead)

And free content will be able to circulate between one system and the other? Oh, yeah...

I can envision the chaos that will occur when I will be able to rip the movies from one of the n competing DRM technologies.

Everyone will be posting torrents on /, (slashcomma) with downloads to the "easy-do-it-all-crack-o-rama" program, and then will be out renting DRM "X" standard technology in order to spread the content between pcs, cellphones, and their taiwanese blueray players.

+ + + +
HTTP enabled phone. Why I suddenly foresee http://4g.goatse.cx (don't follow that link even if it doesn't work) for the future cellphones?

I have been looking around and there doesn't seem to be anything major from any of the big news sites showing overall support for SCO? Is this because NOBODY believes them?

Also found this which has some nice info about SCO's input the linux over the years (And searching on the person named in this document (jan@sco.com) a lot of this input from around the time IBM supposedly introduced this so-called IP into linux!)

oh well... hopfully someone will accidently drop a nuke on SCO in the near future..

Sorry, should have added a link rightaway, so here it is. I think Linus didn't enjoy the 2.4 series as much as development kernels, and maybe also understood that others could be better at the more boring side of evaluating bug fixes etc. (Hats off for that!) He might share the maintenance with Andrew Morton, or possibly completely hand it over by 2.6.0.

2.5 is the development branch, it doesnt need "maintaining".

Well, it's already mostly in maintenance status, i.e. waiting for bugfixes, more testers reporting and so on.

I'd love to see an E-10000 or a pSeries690 with a full spread of processors running Linux.

Your wish is granted:

1000-CPU Itanium HP Linux cluster

Linux on 32-way POWER4, 60GB RAM

Linux on pre-production POWER5

Linux on 24CPU E10000

Fast enough?

Ask Google and you can find similar numbers for 64-CPU ia64 machines from SGI and 100-CPU clusters from HP.

Stump up a few million bucks and HP, IBM, SGI et al will be beating down your door to sell you a big Linux machine.

I'd had to say I agree with the comments from "A look at Ximian Desktop 2" @ lwn.net. LWN look

While this type of lockin and setup is fine for the home user I don't see this fitting into the corporate environment at all. First off OO simply CANNOT import all word docs correctly. Basic text is does fine, but as soon as you add a bullet point or any other basic formatting OO chokes on it. Sure the person who recieves your editted file can do some tabbing and fix some messed up spacing but how unprofessional is that? I wouldn't return a MS word doc that I had editted in OO to anyone using Word. I'd make sure and tell them I only do .rtf. Contrary to the Ximian marketing and PR until OO can perfectly edit and decode MS Office docs its simply not ready for Enterprises that need to constantly exchange MS docs with other companies.

Another point which someone at lwn made as well was the lack of "corporate management tools" to go along with Ximian. This is something that I think KDE is starting to have and shipped with Windows 95 eight years ago. You can't just call something enterprise ready and then not measure up to the products that were released almost a decade ago. Looking at the local security policy tool in Windows XP shows just how featurless XD2 looks in comparison

So basically you have a word processor and office suite that can't reliably exchange docs with the most widely used Office suite and you have a desktop that has none of the management features that Enterprises need. Like I said this isn't what you need to play with the big boys.

Another thing I question is with the advent of Gnome 2.2 is there even a need for a Ximian desktop anymore? As someone who has used Red Hat 8 and up I just don't see the value in letting Ximian take over my already excellant desktop.

In the end I think Ximian is fine for home users and possibly small businesses who dont' need to exchange docs with the outside, but its not the Enterprise Windows Replacement just yet.

I continue to be a fulltime desktop linux user and strongly belive in its future, but when you compare reality with what XD2 offers XD2 really comes up lacking. Possibly its just one of those beginning milestones where we can say "see look how polished linux is", but beneath the surface there are still a ton of issues that need to be addressed before you can expect to just plonk a linux desktop in front of a someone and expect them to be able to function just as well as they did with Windows and MS office.

* Fulltime RH 8.0 and OpenOffice user who wishes MS Office formats weren't hidden.

You could try Here for a slightly more indepth review, or Here for a selection of screenshots.

Or, perish the thought, you could try Here

Interesting title of this thread. Perhaps SCO is the one who should be sued. I found this article on lwn.net. The most telling piece of this article is the following:

Opinder Bawa, Senior Vice President, Engineering and Global Services at The SCO Group, sold all his stock last week. As Vice President of Engineering, Opinder Bawa is in a better position than most to know who put what where.

Anyone who thinks this action is a coincidence, I have this nice bridge I want to sell you.

This is not proper behavior. I work for Sun Microsystems, and as stock-owning employees, we are constantly being warned about making inappropriate stock purchases or sales during times of certain legal or financial proceedings. I cannot believe that SCO management does not have the same cautions placed on them.

Following the link on NZHeretic's lwn article, I did googled Trillian and SCO, and came across this article from the Register, 20 July 2000 by Andrew Orlowski. The opening paragraph is interesting: "According to reports - well, one anyway - Caldera Systems and the Santa Cruz Operation are in discussions which could see the Linux company acquire SCO's OpenServer and UnixWare operating systems. SCO also owns the rights to the Unix trademark, and sits atop a pile of ye originale AT&T Unix code, some of which it's been judiciously leaking as open source over the past year." Anyone have any idea what AT&T Unix code the old SCO "judiciously" leaked as open source?

ftp://ftp.sco.com/pub/updates/OpenLinux/3.1.1/Serv er/CSSA-2003-020.0/SRPMS

Why are you running a release candidate on a production server?

Uh, because there were several vulnerabilities found in the 2.4.20 kernels which were only fixed in the -rc's? See this summary.

Just apply security patches and don't tinker with anything else.

Sometimes the kernel needs security patches too.

Unfortunately for Linux, Linus believes that certain POSIX standards are stupid and doesn't feel bound to stay compatible.

Whay are you dragging out a quote from 2000 about Linux not supporting POSIX threads? Linux 2.5 contains support for NPTL, a POSIX-compliant thread library, and has had this since 2002.

Unfortunately for Linux, Linus believes that certain POSIX standards are stupid and doesn't feel bound to stay compatible.

Whay are you dragging out a quote from 2000 about Linux not supporting POSIX threads? Linux 2.5 contains support for NPTL, a POSIX-compliant thread library, and has had this since 2002.

Apple's labeling of Darwin as "Unix" is neither:

misleads consumers.
creates confusion with other products

I have to disagree with you. Although I think Apple has a fabulous product, it clearly is not "Unix". Products that are "Unix" pretty much have one of two characteristics:

1. Built from a cut of the original Unix code base.
2. Pass the Single Unix Specification (1170) or a newer incarnation.

As far as I know, MacOS X qualifies under neither standard.

MacOS X is a great product, but it is clearly "Unix like" as opposed to A/UX, Apple's System V R2.2 Unix with BSD extensions, may it rest is peace.

Mislabeling MacOS X, or any other operating system, as Unix clearly confuses issues, such as how easy it will be to move applications from one platform to another, and the way the operating system behaves.

Commercial "Unix" has by and large been System V since the 80s. The BSD derivatives (like MacOS X) are at a disadvantage in meeting the current Single Unix Specification given the divergence between BSD and SysV. This issue goes back for quite a ways since the power over the licensing of the Unix code and the Unix name have followed the System V code, not BSD.

The current definition of Unix is in a sense both more strict and more flexible. Since a cut of the Unix source originating from AT&T is no longer necessary, more operating systems could qualify as "Unix", but the Single Unix Specification is fairly detailed so it wouldn't be trivial to pass the test. The Single Unix Specification has been a good thing since it is working to make the commercial System V unixes (AIX, HP/UX, Solaris, Digital Unix, etc.) more compatible.

As far as qualifying for the "Unix" label goes, Linux is considerably better off from a starting position if Linus wanted it to be "Unix". Unfortunately for Linux, Linus believes that certain POSIX standards are stupid and doesn't feel bound to stay compatible.

Although the standards for Unix are clearly defined and available, GNU, the Linux community, and the BSDs often feel no need to converge on the standard. To my mind a fair amount of the work of the Linux Standards Base is pointless. The Linux community could just adopt the 1170 specifications, but instead, like so many things, the Linux community is rolling its own instead of going with an established standard when one exists.

There is a trade-off between standards and massive innovation. Linux, *BSD, and MacOS are nothing if not innovative. But if the builders of these systems don't want to adhere existing standards then they shouldn't be whining when they are properly referred to as "Unix like" instead of Unix.

Frankly, if being called Unix is important to the "Unix like" communities, then they should consider doing what Sun does with Solaris. The behavior of a Sun in userland is highly variable depending upon your path. It can behave with: traditional Sun SystemV behavior, BSD behavior, GNU behavior, or POSIX/1170 behavior.

Frankly, I think it would be a hoot if Apple dusted off the source code for A/UX and layered appropriate parts of it on top of MacOS X.

New and improved MacOS X!! Now with improved POSIX & System V personalities!!

I had intended to wonder why anyone needed to convert a Windows XP Tablet machine to Linux when a Linux solution exists, but I guess it was merely an announcement to gauge interest.

SCOs own SEC filings prove Novell's calims.

First, you quoted out of context. Expanding the quote a bit:

This situation has thus always been a little unstable. It came up again in recent times when Christoph Hellwig posted a patch which explicitly made the Linux Security Module functionality available only to modules licensed under the GPL. People were, says Christoph, using the LSM hooks to change the behavior of system calls, and that went further than he thought was appropriate. In a separate posting, Christoph stated:

My argument is that I want this flag as a hint for authors of proprietary security modules that I'm going to sue them if they use hooks called from code I have copyright on. This includes such central parts as vfs_read/vfs_write. This is, of course, an explicit shot across the bow of anybody who distributes proprietary kernel modules. Linus, then, sent out his current view on binary-only modules:

There is NOTHING in the kernel license that allows modules to be non-GPL'd. The _only_ thing that allows for non-GPL modules is copyright law, and in particular the "derived work" issue. A vendor who distributes non-GPL modules is _not_ protected by the module interface per se, and should feel very confident that they can show in a court of law that the code is not derived.

Starting with Linus' note, he (and you) are correct): it isn't the kernel license per se. that allows non-GPL modules, but the fact that they are not "derived works" of the kernel. Linus has always maintained that modules are not part of the kernel, and therefore not subject to the GPL. He could have argued that they are part of the kernel, and the situation would be different (while copyright law would not allow this, given the non-derivative code shield, the kernel use license could have required agreeing to that fact by anyone who distributes the kernel with non-GPL modues -- the kernel license then would not be GPL, of course).

It becomes a point of semantics: is Linus' traditional position part of the kernel license or not? Some would say yes, others would say no. In any case, as author of the kernel (yes, I'll address other contributors later), he is free to selectively relax restrictions in a the license thereof to the benefit of licensees. This is the same reasoning that lets a late payment be "forgiven" at the discretion of a lender even though it may technically make a loan in default.

What Christoph Hellwig has done, since kernel modules do not have to be GPL, is license HIS module to forbid binding by other non-GPL modules. Given Linus' position, I see this as perfectly acceptable.

However, as others have contributed to the kernel (and not just modules), perhaps their interpretation of Linus' lax enforcement of his license isn't all that pleasing to them: some might not want to see non-GPL kernel modules using their code at all.

While I would think that their creation of a derived work would fall under the terms of the license that covers derived works, the issue is whether this license is just the GPL, or the GPL with Linus' informal note that modules are not derived works and therefore not covered by the GPL. While I am not a lawyer, I'd think that Linus' interpretation of derived work forms part of the complete license, including the text of the GPL. Thus, those who produce derived works of the kernel must redistribute them under terms of the original license: GPL with Linus's definition of derived work. Copyright law may or may not agree but it is the license that matters because it confers greater rights than copyright law alone. Again, IANAL, so take this with a big grain of salt.

But, then, this is a change to the GPL, and the license on the use of the text of the GPL (overriding the copyright on the text of the

The general buzz is that SCO's grasping at straws because they expected IBM to buy them out. Hence, SCO turns around and starts making trouble in the hopes to force IBM to buy them out.

News.com LWN's article, which references a News.com article, seems to point to this as well. They go a step further poking that IBM will buy out SCO, then toss them in the dumpster.

We all know the fact is that SCO's business has all but vanished. Their business model now is chasing after patent royalties. From my recent experience with patent hungry Gemstar and their failed buyout of DIVA which resulted in Gemstar being fined $40mil, the patent-chasing business model is doomed to failure and only results in animosity towards the patent chaser.

SCO is just making noise to (1) get in the headlines, and (2) drive up their value before getting bought out.

Well these USENET posts do indicate some connection here, as does this post by Linus himself.

These documents look historical to me. The Minix and early Linux communities were mixed, and I think it is unlikely they concerned themselves with keeping the code bases separate.

...patents, and the fact they don't own any (Novell and Tarantella do I believe).

FWIW- A rep from Tarantella has come forward and said that they own no UNIX IP of any sort. But damned if I can find a link to it now. Help anyone?

That little bitty circle-R there seems to imply a copyright.

Well, in fairness, the circle-R is for registered trademark and needs to be included regardless of who owns that trademark. SCO has been better lately of attributing the UNIX trademark to The Open Group, but not before getting smacked for lack of attribution.

Additionally, some developers of kernel loadable module code, such as for device drivers, believe that by packaging their code as a loadable module it need not be released under the GPL.

Hmm? I thought that this type of construct was specifically allowed. There are many companies who release proprietary code as loadable kernel modules - video drivers, for example. A quick Google shows that binary-only lkm's are permissible, though apparently there is some effort being made to clearly define what "permissible" means in this case.