LWN: Comments on "Kororaa and the GPL - Update 1"

The real solution

wilck — Tue, 06 Jun 2006 16:31:09 +0000

They're slower, but if that matters to you more than freedom, you're part of the wrong community.

In other words: Linux will appeal to noone except those who value Software Freedom more than anything else, aka "religious" Linux users.

I'd buy an Intel graphics solution any day (if I can find one) but what about my girl friend, my mom, my friends who want their computers to "just work" with all their features? Are they all part of the wrong community? What is the right community, after all?

Even open minded, critically thinking people are often hard to convince that the 4 freedoms of the GPL are worth sacrificing the convenience of prorietary software. It takes some positive personal experience to learn about the benefits of free software. Once that experience has been made, people start realizing that freedom actually is worth some inconvenience.

I have convinced some non-technical people to use Linux. But I doubt I would have been able to do so if I had been restricted to Debian main and contrib.

Without the ability to attract new users, especially young users and non-technical users, Linux won't survive the current hacker generation.

The real solution

drag — Fri, 26 May 2006 03:09:37 +0000

You need to choose your fights.

Decent Free video drivers on a decent video card is much more important for a Free Desktop then a a Free BIOS.

Also motherboards supporting bios replacements (generally Tyan type things) are pretty much unaffordable. The ability to use a Free BIOS replacement is technically only a boon for people doing things like clustering or need instant-boot-up. The video drivers are more important and Intel helps with them with documentation and such.

As far as open source drivers go, Intel is pretty decent.

Replying to myself...

xoddam — Fri, 26 May 2006 02:21:38 +0000

> (though I know other people have reservations)

There's also this:

"The only exception we make is for code which was written for other
operating systems and was then ported to Linux."

http://lkml.org/lkml/2005/2/4/53

This contradicts my thoughts about conventional interfaces like
spin_lock(), but explicitly endorses the NVIDIA driver, in direct
contradiction to Filip's argument (which I agreed with in broad strokes
but argued in the fine detail).

Enough armchair lawyering for me, as Greg K-H would say.

The Linux kernel is unambiguously licensed under GPL version 2.0.

xoddam — Fri, 26 May 2006 02:09:35 +0000

Okay, standard disclaimer: IANAL, and when I write IMO, that's *my* opinion and has very little correlation with what a court might find.

Do you really thing copyright law cares about the last letter of a file name (c vs h)?

Of course not, not a whit. The distinction I'm making is between source code which doesn't incorporate copyrightable implementations (interfaces are not copyrightable in themselves -- that would make Linux and glibc derivative works of the original AT&T Unix, as SCO claimed for a while) and object code which may or may not incorporate the implementations, depending on the implementations themselves and on what has been linked to what. Writing #include <stdio.h> does not incorporate the contents and implementation details of the stdio API into your program's source code. Does anyone care whether putchar() is a macro, an inline function or a call to a function defined elsewhere?

I do think there is a difference between using an interface and incorporating it. You only make derivative works by actually incorporating the parent work into your own -- not by referencing its published interface. The source of your program does not derive in any way from libc or the standard headers. On the other hand the ELF executable may or may not derive from the contents of the headers, depending on implementation, and if you link statically with libc.a then your executable is also a derived work of libc (dynamic linking would produce a derived work in-core, but I have been told -- IANAL -- that a running process image is not considered to be a copy for legal purposes; certainly you don't distribute it). No-one minds that you do this because the LGPL explicitly permits it, but the distinction and the implementation details become relevant when you begin to make derived works using GPL'd interfaces. Source code which uses an interface is not a derived work of the header file which declares the interface. Object code may be, depending on the details of the implementation.

Do you really think GPL symbols are anything but a debug convenience?

Yes. "The stated purpose of that marking is to prevent non-GPLd code from using those symbols." Nothing to do with debugging. It's a technique for enforcement of the licence -- a kind of DRM. (joke)

In your opinion:
If a shim pulls in inlines or macros that could not easily have been reverse engineered from a header, is it derived or not?

The source of the shim is not derived from the header. The object code may be. Supposing the code generated by the inlines and macros is sufficiently nontrivial to be copyrightable, that derivation becomes a copyright issue.

If that shim is statically linked to a binary blob, is the resulting module derived from the shim, or not?

Yes of course the linked module is derived from the shim. If there's a disagreement here it is as to whether the actual shim in question (for NVIDIA display driver) uses any disputable inlines or macros. AFAIK it doesn't use any symbols marked GPL-only, which is the 'do not cross this line' marker used by the kernel developers. So it comes down to whether locking primitives and access functions for kernel data structures -- which all modules have to use -- are sufficiently nontrivial.

So a question for the audience (and the lawyers): If a module uses spin_lock() and list_for_each_safe(), does that make its object code a derived work of spinlock.h and list.h? Linus has explicitly endorsed the distribution of such modules without complete source code (though I know other people have reservations), and it is my understanding that the NVIDIA driver fits that description.

As far as I have understood, the objection to kororaa is not about considering a single .ko to be a derived work of the kernel headers, but rather that the kernel as a whole, when distributed on a CD as a bzImage file and some .kos, one of which is non-free, which are to be linked with the kernel on boot.

I am open to correction on either of these points. It would be very helpful if anyone comes up with a pointer to clear information as to whether the kernel developers' objection is to the distribution of the .ko alone, or only together with the kernel to which it is to be linked at runtime.

The Linux kernel is unambiguously licensed under GPL version 2.0.

filipjoelsson — Thu, 25 May 2006 21:38:13 +0000

Some things you are writing are a bit unclear to me:
Do you really thing copyright law cares about the last letter of a file name (c vs h)?
Do you really think GPL symbols are anything but a debug convenience?
In your opinion:
If a shim pulls in inlines or macros that could not easily have been reverse enginerd from a header, is it derived or not?
If that shim is statically linked to a binary blob, is the resulting module derived from the shim, or not?

My opinion is very clear, the .ko files are derived from headers that are made available under the GPL. If the ABI of modules was stable enough, ati and nvidia would address the ABI directly - and there would be no need for a shim. Since the need is there, the shim is derived from the headers, and the .ko is also so. QED.

picking a nit

hummassa — Thu, 25 May 2006 19:07:35 +0000

1. 'derived work' is decided by copyright law, not the GPL. So that's up to a judge to decide and until there is precedence then it's a mostly gray area.
Nevertheless, there exists at least one method already established (by (USofAn) caselaw) to decide what is and what is not a derivative work (abstraction, filtration and comparison).

The Linux kernel is unambiguously licensed under GPL version 2.0.

xoddam — Thu, 25 May 2006 02:22:41 +0000

Hmmm. The whole subject of whether using macros & inline functions from
a work constitutes incorporating portions of it is a big grey area. FWIW
my opinion is that a .c file which uses APIs is not a derivative work (at
least not for that reason) -- whether it's only a symbol declaration (and
function prototype), or a macro or inline function, is an implementation
detail. The .o file built from the .c and .h files *obviously*
incorporates parts of both works though -- though as you say, fair use
rules might apply in jurisdictions lucky enough to have such a doctrine.

I do not think the "GPL only" APIs change the gist of this discussion at
all: they imply an added condition to the licence for the kernel that
these APIs not be used by non-GPL modules, but that exception, like the
rest of the conditions in the licence, only comes into play where the act
of copying and distributing does.

But neither question is actually relevant to the NVIDIA and ATI display
driver modules. Those drivers do not use Linux kernel APIs directly, but
only via a 'shim', which is (a) GPL licenced, at least in letter (though
the final .ko which is insmodded can't technically be considered GPL),
and (b) doesn't use GPL-only kernel APIs anyway.

The GPL violation Kororaa is alleged to have made is nothing to do with
including bits of kernel headers into shim objects which are then linked
to binary-only non-free modules.

The question is whether providing a GPL'd kernel binary and a non-free
module together on the same bootable medium with the clear intention of
linking them together as soon as the system is booted (thus producing a
non-free and nondistributable kernel 'in core') is equivalent to
*distributing* a non-free kernel binary, which would *clearly* violate
the GPL.

I do feel I'm repeating myself... does anyone actually disagree?

The real solution

k8to — Wed, 24 May 2006 19:43:19 +0000

As for the G550, which I use, there are some issues.

It's incapable of driving a not terribly atypical 1600x1200 monitor via
DVI (I guess this is a lack of dual link issue?), which wasn't a big deal
when it was released, but isn't so great now.

Without the MGA_HAL proprietary driver module -- which is not compatible
with modern X.org -- the results for some DVI behavior and some multihead
behavior, especially when switching resolutions is a bit.. touchy. It's
quite possible to wander off into corrupt display territory. It's gotten
a _little_ better with X.Org 6.9 (Debian testing doesn't thread the
bleeding edge), but the driver is relatively ignored.

The DVI problems aren't the worst problem because the analog signal
generated by matrox cards is top notch. It's almost as crisp over D-SUB
as DVI, but it's annoying to watch my monitor "sync" up and sometimes
even get the display settings totally wrong, when on DVI it is instant
and always correct.

The DRI driver works, but the implementation is aging in terms of
flexibility (texture sizes, etc), let alone performance. Some programs
will not execute, while others are simply low performant.

I see no evidence of people working on EXA/Composite and such for the
Matrox cards.

On the plus side, the cards are fanless with a modest heatsink, and not
too pricey. Just be sure not to get the 650, which is a completely
unrelated chipset, more or less a stripped down parhelia series card,
which have linux drivers but they're closed, and poor.

The Linux kernel macros

pflugstad — Wed, 24 May 2006 16:29:47 +0000

Heh - have you seen the min/max macros the kernel uses? Here's the debate (the first 1/2 a dozen entries or so):

<http://www.google.com/search?q=min+max+macro+site%3Alwn.n...>

And the current form (as of 2.6.16.18), which do type checking:

<http://lxr.linux.no/source/include/linux/kernel.h>

Also, I think a lot of the time, the kernel uses inline functions, and they are frequenly non-trivial. I think a lot of the scheduling and locking (spinlocks, sems, etc) functions are actually inline functions. Basically, a LOT of functionality is incorporated in in kernel headers.

So it get really hard to interact with the kernel without including kernel headers and using these inline functions - and from there, you get to a derived work pretty quickly.

Pete

The Linux kernel is unambiguously licensed under GPL version 2.0.

kakareka — Wed, 24 May 2006 14:47:01 +0000

Macros will only get included in a binary if actually used. Just including your header (ie, #include in the source) doesn't mean the binary contains your code and couldn't be considered derivative. Also, most macros are probably too simplistic to be copyrightable (eg, min and max macros).

John

ATI motherboards

man_ls — Wed, 24 May 2006 14:34:25 +0000

I expect that the ATI stuff is even worse.

Yes, ATI motherboards are horrible. I bought an AOpen XC cube with an ATI motherboard, as it was the only silent barebones which supported amd64 processors at the time, and it has taken me a full year to be able to use a Debian derivative on it (Ubuntu Dapper beta 2). Problems with the chipset, sound, network, graphics card...

The real solution

eru — Wed, 24 May 2006 14:01:42 +0000

There's a certain irony to the fact that in order to use a gpl graphics driver you are forced into buying a board/processor from half of the famed 'wintel' cartel.

Yes, and in some other matters Intel seems to be part of the problem, as seen here:

The most uncooperative company is Intel, which has started a sham "open source" BIOS project. The software consists of all the unimportant parts of of a BIOS, without the hard parts. It won't run, and doesn't bring us any closer to a BIOS that does run. It is just a distraction. By contrast, AMD has been cooperating by releasing major chunks of their BIOS source code and making their technical experts available.

(Quote from from http://www.fsf.org/campaigns/free-bios.html). So who should I boycot?

Wouldn't it be lovely if there were a hardware company that just concentrated on making the best hardware possible and helping developers to write the best possible drivers for it, not just the big companies...

The Linux kernel is unambiguously licensed under GPL version 2.0.

Wol — Wed, 24 May 2006 10:50:16 +0000

I think the idea of the "GPL only" stuff is that a binary module (which pretty much has to include at least header files) is placed on notice that the inclusion of header files will be considered a copyright violation!

Let's say I write a nifty .h file with loads of macros. Any binary that includes my .h file is a derivative. In the normal course of events the contents of a .h file are considered "fair use" or "scenes a faire" or whatever - the consequences of which is that copyright is not violated.

The "GPL only" flag is a big red warning that use of this particular .h will NOT be considered fair use ...

Cheers,
Wol

The real solution

drag — Wed, 24 May 2006 08:20:23 +0000

What I put together just recently.

motherboard:
http://www.newegg.com/Product/Product.asp?Item=N82E168131...
cpu:
http://www.newegg.com/Product/Product.asp?Item=N82E168191...

Then I used a huge Scythe tower-style heatsink to keep that cpu cool without making noise. And as a bonus it supports the VT extensions for when I want to muck around with Xen on it.

I realy wanted to get a AMD machine, but the fact that Via motherboards are getting old and Via hasn't released much new lately their stuff is getting dated. All that is realy aviable is ATI or Nvidia motherboards and I realy realy realy have NO desire to own another nvidia motherboard (which I quickly sold to a windows-using friend as soon as I got it), and I expect that the ATI stuff is even worse. I'd realy like to have a nice Tyan motherboard (which have excelent linux support) but it's outside what I can afford for a personal computer.

So that was a huge turn off for me.

So I think for a budget workstation this intel stuff is great. Everything worked out of the box with Debian Unstable. Debian stable installer didn't have drivers for the network stuff.

Sound worked. Network worked. Video works. Sata works (with SMART support with unstable kernel!) No binary-only drivers. No screwing around. Even sensors worked great with only having to run the sensors detect script. No sign of flakiness.

I don't like a lot what Intel does. Their firmware licensing for the wifi stuff is irritating to be sure, for example.

Intel-based motherboards just realy have a very high compatability with Linux, from my experiance. I am quite happy about it despite the second-class cpu. (which itself, being dual core, is so responsive and fast as to be almost too much for a Linux desktop)

Get around a 10msec latency with jack my Audiophile 24/96 audio card with the stock kernel and no xruns. I haven't tried a low-latency kernel yet, but I can't imagine.

The real solution

Arker — Wed, 24 May 2006 06:49:53 +0000

Keep in mind that, although Matrox is no longer actively being good, their support in the past has resulted in quality free drivers available for several of their chipsets, up to the G550 which is a pretty capable card.

On a side note, every time I've attempted to enter a reply on the kororaa blog it eats the comment:

Whoops! Comment not saved. I ran into a problem while saving your comment. Server Reported:

Anyone else?

The real solution

h2 — Wed, 24 May 2006 06:35:22 +0000

There's a certain irony to the fact that in order to use a gpl graphics driver you are forced into buying a board/processor from half of the famed 'wintel' cartel. Not to mention that amds are just ahead of the game at this point.

It would be great to see the intel chips be put on a card though, pci-e, if it was reasonably cheap I'd happily dump my nvidia and go full free gpl, anyone who underestimates the danger of using proprietary drivers to view your monitor with everything else gpl'ed or free software is making a mistake.

I've been following the debate on this around the web this week especially, and it makes no sense, how can you think that using gpl stuff like linux is great and then at the same time support binary only drivers like nvidia/ati?

Unfortunately there's not a lot that can be done at this point short of buying intel boards and cpus, but I'm not willing to do that. Here's hoping that someone at intel decides to make a straight video/graphics card based on open drivers.

The real solution

eru — Wed, 24 May 2006 05:54:41 +0000

The FSF recommends the Intel GMA chipsets as the current 'not actively hostile to Free Software' 3D choice.

The main probem here is that you can get that only by buying a motherboard with the Intel chipset, so you are out of luck if you prefer some other processor than Intel. However, this issue may decide that, like my current aging home PC, the next one will also have an all-Intel kit inside...

Kororaa and the GPL - Update 1

k8to — Wed, 24 May 2006 05:19:20 +0000

And I do not disagree with you; the nature of derived works does
merit discussion in this case. What I disagreed with is that the
relevant kernel developers are "whining losers" who have not considered
the situation at all. Dismissing them summarily without any
argument is at best belittling, and at worst complete disinformation.

It is a small point.

well said..

Tashlan — Wed, 24 May 2006 02:13:23 +0000

Well said.

I'd also like to add; If you feel the GPL is too restrictive, use BSD instead.

The Linux kernel is unambiguously licensed under GPL version 2.0.

xoddam — Wed, 24 May 2006 02:01:27 +0000

I'm surprised Moglen would draw such a conclusion.

Hooks for non-GPL modules imply that you have permission to *use* non-GPL modules with your Linux kernel. But the GPL is not a 'shrink-wrap' contract. You don't need permission to use the software in any way you please. The GPL is a *copyright* licence only, and all it does is to permit *copying* the kernel providing that certain conditions are met. And the kernel is unequivocally licenced with version 2.0 of the GPL, without any special exceptions.

Running 'insmod' is not distributing GPL software. Providing CDs and ISOs for download is. The only question open for argument here is whether it violates the GPL to distribute proprietary modules alongside a GPL'd kernel with the sole intention of linking them together at runtime.

Is this equivalent to distributing a kernel binary pre-built from a combination of GPL and proprietary source, which would *obviously* violate the GPL?

Kororaa Doesn't Say What Kororaa Is

dwmw2 — Wed, 24 May 2006 01:32:04 +0000

They never bother to say what the %&^#(*&%^ "Kororaa" is! "What is Kororaa"? I still don't know.

That's easy enough to answer: Kororaa is a work based in part on the Linux kernel.

The real solution

swbrown — Wed, 24 May 2006 00:46:29 +0000

The real solution is to make a push for Free Software 3D drivers. Attempting to tear apart the GPL from the inside of the community, or illegally (and immorally) distributing proprietary drivers and basing a Free desktop around that isn't the right solution.

GNU/Linux didn't get to where it is now by compromising the philosophy every time it was tempting to do so. If you feel tempted, be part of the solution: either help create Free Software 3D drivers, or start doing Free Software 3D driver advocacy. Also, refuse to buy hardware there are no Free Software drivers for. The FSF recommends the Intel GMA chipsets as the current 'not actively hostile to Free Software' 3D choice. They're slower, but if that matters to you more than freedom, you're part of the wrong community.

Kororaa Doesn't Say What Kororaa Is, Yes it does

British — Wed, 24 May 2006 00:37:08 +0000

Kororaa is a distro based on Gentoo, they were the first to produce a live CD that let you see the power of xgl (have you heard of that?) The live CD did a very good job of showing the power of xgl and the 3D desktop introducing thousands of people to the next generation desktop and for that thousands of people are very happy with what Kororaa achieved.

Kororaa and the GPL - Update 1

proski — Tue, 23 May 2006 22:51:37 +0000

Let's see the quote from the actual letter:

"Now, what you're doing when you combine the binary-only modules and the kernel together into a distribution or LiveCD is _not_ "mere aggregation". That's clearly a coherent whole; a collective work and not just a bunch of stuff which happens to be sharing the same disk. [...] So while the binary-only modules _themselves_ are only 'questionable' on their own, the distribution of them _with_ a kernel is clearly a violation of the license of the kernel."

I don't see how someone's expertise in Linux development translates into expertise in distinguishing derived works from "mere aggregations". It's a matter of copyright law, and Linux is not written by lawyers.

Ultimately, copyright law is interpreted but courts rather than by copyright holders. Some free software we are enjoying today would not have existed if copyright holders were allowed to amend or re-interpret copyrights retroactively. Most prominent example is OpenSSH, which is based on the last free version of SSH.

Kororaa Doesn't Say What Kororaa Is

s_cargo — Tue, 23 May 2006 22:48:26 +0000

I don't know about a GPL violation, but the Kororaa website violates my sense of useful information content. When I saw this news article I had no clue what "Kororaa" was, so I went to the web site. The home page is really a "news" page, but they have a "What is Kororaa?" link, so I clicked it. On the "What is Kororaa?" page they talk about install scripts, large numbers of tweaks, admiration for Gentoo, what CPU's "Kororaa" runs on, and state that it is beta and "hacky". They never bother to say what the %&^#(*&%^ "Kororaa" is! "What is Kororaa"? I still don't know. Is it a distribution, a desktop, an installer, what? I don't care at this point. If the website is at all indicative of the clarity and relevance I can expect from their documentation, forget it. Not interested in looking further.

Possible solution for module license "issue"

khim — Tue, 23 May 2006 22:25:38 +0000

One possible solution would be to have a clean-room implementation of the Linux module build system and the kernel API headers.

Multy-year project. And will need CONSTANT support (since "linux module build system" changes daily). If you really care about this kind of stuff you'd better try to bring *BSD on desktop...

Kororaa and the GPL - Update 1

drag — Tue, 23 May 2006 22:13:29 +0000

BTW I missed two points I wanted to make..

1. 'derived work' is decided by copyright law, not the GPL. So that's up to a judge to decide and until there is precedence then it's a mostly gray area.

2. It would be nice if Kororaa people would work on help getting a stable XGL livecd using the Free software 3d drivers that we already have. (r200_dri, r300_dri, i915_dri, etc)

Kororaa and the GPL - Update 1

drag — Tue, 23 May 2006 21:59:40 +0000

What we need is free software drivers.

I use a rather wimpy Intel GMA 950 video chipset which is fairly well supported by free software drivers. (meaning reliable 2d and 3d acceleration) (GMA 900's are slightly better supported but slightly slower)

Also I am looking to purchase a used x600 card to try out the r300_dri.so drivers. (which if I understand it support ATI r300 series through r420 series cards, but don't take my word for it)

From a practical point of view; without Free software drivers Linux-on-the-Desktop efforts are entirely beholdent to Nvidia or ATI. Nvidia more especially.

Now both these companies, themselves, are completely dependant on LOtD's single major competitor: Microsoft. ATI stopped supporting (which was pretty limited stuff) X/DRI developers round about the same time that they won the contract for making the Xbox 360's video cards. Nvidia more then likely that cross patent licensing and maybe even code from Microsoft in it's binary drivers that you use to accelerate your Linux desktop.

Now say if Linux actually starts to become a real threat to Vista, which is still fairly unlikely. If Microsoft was able to leverage it's have-them-by-the-balls grip that it has over these two video card companies then it's pretty likely that Nvidia's or ATI's driver support is going to go to mediorce to worse.

Or something like somebody starts to reverse engineer Nvidia's drivers and this pisses them off to the point were Nvidia was to pull support for Linux ala bitkeeper.

Then that's pretty much it. The Free software desktop, that depends heavily on propriatory software to run well that then stops existing, will be drifting dead on the water.

Don't get me wrong.. I do beleive that Nvidia does care about it's Linux-using customers. There are a lot of high end workstation class cards that people pay a LOT of money for that will be used in Linux and Nvidia definately cares about that. As does ATI since they originally only released FireGL versions of their drivers. And I beleive that they care about the quality of drivers that people use on their desktops. It's just that I also beleive that nvidia/ati care much much more about their windows users. Around 99 to 1 times more.

And the situation is going to get worse as far a free desktop goes. The propriatory Nvidia drivers already do 2d acceleration using OpenGL or at least 3d portions of their video cards. The ATI r500 core doesn't even HAVE a radeon 2d core anymore. As I understand it it's just pure 3d. (correct me if I am wrong) I expect Nvidia to follow suite if they haven't already. I expect in 3 to 5 years from now 2d only acceleration won't even be a option on modern PCs anymore. All you'd have would be VESA compatability or 3d acceleration.

Also as far as the legality goes.. I do beleive shipping a binary nvidia.ko is illegal. I don't think that it's illegal for end users to patch their kernel or to use binary kernels themselves.. but distributers have troubles, technically. (but not in reality)

(if it's illegal for propriatory software to latch into GPL'd libraries (hence you have the LGPL license to work around that) then what is so different about a kernel module which hooks even more deeply? And although half of the code that makes up the module is not linux-derived (the binary blob), the other half is (the gpl'd shim). So doesn't combining derived code and nonderived code then distributing it cause problems under the GPL?)

As long as the Linux developers tolerate having non-GPL compatable kernel modules then people like Kororaa or Debian non-free has nothing to fear. It's the copyright owners of the kernel that ultimately decide these things and if they have a live and let die attitude in regards to these sort of things then anybody can ship anything they want. Anybody else bitching that don't hold copyright code that is hooked into by the nvidia.ko drivers can be safely ignored.

Kororaa and the GPL - Update 1

k8to — Tue, 23 May 2006 21:31:51 +0000

Wow, this is a very large assumption to make about the developers of the
linux kernel code who object to this kind of linking and distribution.
Surely the developers of the Linux kernel are the default authorities on
the topic, and therefore claims which deviate from theirs are those which
require justification.

Possible solution for module license "issue"

proski — Tue, 23 May 2006 20:38:08 +0000

One possible solution would be to have a clean-room implementation of the Linux module build system and the kernel API headers. Then ATi and and nVidia could use that build system for DRI modules without using the Linux kernel sources in any way. The modules would still load into the kernel, but it could be argued that they are "kernel-level executables".

Nobody claims that e.g. Norton Commander is a derivative of MS DOS, yet it loads into the same memory area as MS DOS (the lower 640k), it runs with the same permissions as MS DOS (real mode or VM86) and it used MS DOS calls.

Kororaa and the GPL - Update 1

gvy — Tue, 23 May 2006 19:02:32 +0000

Again... those losers who would just whine about some violations without backing their claims with at least some analysis are just that -- losers to be ignored. Sorry for them.

So Chris, if you happen to read this, just relax. They're not worth it.

Kororaa and the GPL - Update 1

einstein — Tue, 23 May 2006 18:48:09 +0000

I hope that this can be resolved to everyone's satisfaction in a timely manner. This demo has caused mac and windoze users jaws to drop in amazement at the coolness of the xgl GUI.

I can't help but think that the original intent of the gpl was not to harass people who put together cool linux demos like this.

IMHO of course

Kororaa and the GPL - Update 1

JoeBuck — Tue, 23 May 2006 17:47:58 +0000

Eben Moglen has said that it's not clear to him that the Linux kernel is really under the GPL. Under his interpretation, if I recall it correctly (and I apologize for putting words in his mouth) proprietary kernel modules violate the GPL, but he seems to think that the symbol labeling mechanism, which reserves some symbols for use by GPL modules and permits other symbols to be accessed by non-GPL modules, implies that there is a license of some sort for proprietary kernel modules, a kind of permission that goes beyond the GPL, but the problem is that this extra permission isn't really in writing anywhere.

Then you've got the problem that there are many copyright holders for the Linux kernel, and some of the copyright holders think there should be no proprietary kernel modules.