Linux: the GPL and Binary Modules

An anonymous reader writes "When first made available in September of 1991, the Linux kernel source code was released under a very restrictive non-GPL license requiring that the source code must always be available, and that no money could be made off of it. Several months later Linus changed the copyright to the GPL, or GNU General Public License, under which the kernel source code has remained ever since. Thanks to the GPL, any source code derived from the Linux kernel source code must also be freely released under the GPL. This has led many to question the legality of 'binary only' kernel modules, for which no source code is released. Linux creator Linus Torvalds talks about this issue in a recent thread on the lkml."

How viral IS the GPL?

[MROD]

OK, from the article it seems that merely writing a device driver which uses the kernel module interface automatically makes the code a derived work. Also, building programs which include the kernel header files automatically makes those programs GPL.

Now, what if someone wrote another standard driver interface, separate from the kernel interface, wrote a device driver which implemented that and then wrote a GPL'd interface wrapper which translated the Linux module interface to that of the new standard?

Obviously, the wrapper interface code is now a derived work. However, does it also mean that because the new driver which uses a code interface which the GPL'd wrapper implements now is tainted by the GPL?

Also, does the driver become a derived work if the person who writes it initially does so to get some hardware working on his Linux box, rather than his other box which runs ObsureOS which also implements this standard device driver interface but the person hasn't installed the hardware on that machine yet?

lines have to be drawn

[ciaran_o_riordan]

it lowers the entry barrier to companys wishing to contribute

I see it as encouraging companies *not* to contribute. Why give people Free code when you don't have to?

A binary file is not a contribution, it's just a marketing tactic exploiting our free platform. Since the Linux hackers have written an entire kernel, I don't think it's unreasonable for them to ask for module source code in return. Otherwise the module vendor is a parasite.

SCO Derivative works theory & Linux modules

[putaro]

The SCO case will have some far reaching effects if a sufficiently bone-headed judge rules in certain ways. One of the cornerstones of SCO's "case" is their theory on derivative works: notably, JFS. JFS is in the same category of kernel module as AFS which Linus references. SCO claims that JFS is a derivative work of Unix and therefore falls under IBM's contract obligations and SCO's copyright. Were SCO's theory to be accepted, it would be theoretically possible to try to force AFS to be GPL'd under the same theory.

An even more interesting stretch of the theorem would depend on how this "derivativeness" would be defined. Why is JFS a derivative work? If it's because it has substantial similarities to other Unix file systems (tree structured directories, permissions) there's an interesting case against MS for NTFS and DOS FAT, as these both have tree-structured directories and MS has been a Unix licensee. Now, wouldn't that be fun. Unfortunately the only entity that could bring that case would be our good friends Darl and SCO at this time.

Re:Pragmatism

[BESTouff]

Nope. Having binary modules only stops developers from trying to make their own, so you end up with proprietary, non-debuggable and non-portable (across kernel versions or across architectures) drivers. There are for example winmodem drivers you can only use on a 2.2 kernel, or the famous nvidia drivers which work only on i386. Even if this helps the casual gamer (which would be waaay better running Windows anyway), this is in fact a regression from the free software perpective.

Imagine a future where you install your core Linux kernel, then download a ton of different binary modules from different websites, have to hunt in the forums to mix-and-match the right versions, and end up having bugs nobody won't fix ? Think about it, that's what you want when you allow "pragmatism".

Fair Use

[Anonymous Coward]

So, I think there's lots of things to quibble about here, and appended is part of the law that might prove relevent. I'll try to make a case for a driver company attempting to create a non-GPL driver that uses snippets of GPL'd code in a 'fair use' way.

The key I think is if you can convince a judge that what they are doing is furthering 'research'. But the rest of the tests obtain:

1) Binary Linux drivers are generally release with a non-commercial nature - people don't charge for the software (although the opposite case, that you have to buy the hardware, could be argued to contradict this) - specifically, note that the word "including" modifies the two called out styles of use (commercial and non-profit eduacation) - thus other things might very well cause this section to obtain.
2) The copyrighted work is humungus and designed to be used in explicitly this manner
3) The portion of the whole is miniscule - it could be characterized as a 'quote' from an original source
4) The effect on the market value of the copyrighted work can be argued (successfully, I think) to be _positive_.

One other thing: I am under the impression that you can't copyright tables of raw data (such as names and their numeric mappings), so with Linus, I'd argue the #defines and such don't count for these calculations. The comments can't be said to contribute to the (binary) final work, even if someone read them once. Linus noted, and I agree, the compilable code (macros, subs defined in .h files), is what matters, and not all of the compilable code even in the subset of files referenced are used to create the .obj.

I think I've made a (albeit shakey) case for 'Fair Use' in this way.

(ObSCO: I wouldn't be _at all_ surprised if SCO is going to attempt to argue that the overwhelming weight of the detrimental effect of #4 on SCOnix's value will outweigh the relatively trivial amount of infringement of #1, #2, #3 should IBM attempt to suggest fair-use of a couple of lines here and there)

------
Title 17, Chapter 1, Section 107
Notwithstanding the provisions of sections 106 and 106A, the fair use of a copyrighted work, including such use by reproduction in copies or phonorecords or by any other means specified by that section, for purposes such as criticism, comment, news reporting, teaching (including multiple copies for classroom use), scholarship, or research, is not an infringement of copyright. In determining whether the use made of a work in any particular case is a fair use the factors to be considered shall include --

(1) the purpose and character of the use, including whether such use is of a commercial nature or is for nonprofit educational purposes;

(2) the nature of the copyrighted work;

(3) the amount and substantiality of the portion used in relation to the copyrighted work as a whole; and

(4) the effect of the use upon the potential market for or value of the copyrighted work.

The fact that a work is unpublished shall not itself bar a finding of fair use if such finding is made upon consideration of all the above factors.

Re:What Linus is missing here...

[Anonymous Coward]

We're talking about binary modules. In this case, while the linking may be done by the user, the module is compiled before distribution. Consequently the object file may contain GPLd code by ways of inlining. At that point it clearly becomes derived work and cannot be distributed (except with source and GPL).

Even if it doesn't contain GPLd code there are things to look out for. The GPL defines what is considered derivative and what is not. According to the GPL, kernel modules clearly fall into the former category, even if they don't include GPLd code by inlining. If you are in a position in which you have to accept the Linux kernel license (IOW you distribute the kernel, which you aren't allowed to do without accepting its redistribution license), then you have to provide source to your modules. Only if you don't distribute the kernel you can ignore the GPL's definitions of "derivative" and fall back to standard law definitions which probably allow distribution of a binary module.

Re:Linux linkiing analogy

[kscd]

Derivative works in general are a grey area, but in your specific example I would have to say that you are in fact wrong. Not wrong according to the original U.S. copyright law, but definitely wrong according to what we have now. You say, "If I wrote a story that was derived from the LOTR...". That's it. You wrote a story derived, it's a deritave work. That simple. For example, let's say you would like to re-write Gone with the Wind from a slave's perspective. Completely different story (as you can imagine), but characters, plot, etc. derived from the original. If you did this, you would wind up in court, much like the person that did. [freedomforum.org]

if it happens that.......

[Anonymous Coward]

If it happens to be that that some modules ARE indeed being GPL'd, where does that put the company that made them? Case in point, Nvida seems to making a VERY obvious statement that it doesnt want the sourcecode to be given to the GPL? Would Nvida be allowed to refuse to release the source? And if not, what then? How would you go about such a thing?

Re:Pragmatism

[jusdisgi]

Whatever man, those modules aren't that bad.

1)I'm interested to see these bug reports due to the "nvidia black box"...you are aware that a good chunk of this thing (and all the kernel interface) is available in source, right?

2)And what's this about not having one compiled for your archetecture? Have you ever installed these? I did it this morning; I typed one command, a menu prompted me to accept a license, then looked for a version on nvidia's ftp site, didn't find one. So it compiled one for me. This was all every bit as easy as running a WISE installer in windows. That is, as long as you can read the instruction on the site where you downloaded the thing from that says "type 'sh nvidia-thingie'"

I have run a lot of video cards in a lot of Linux boxes. Some had open source drivers; most of these were good, a couple were not. Some had no drivers available, and I had to use a generic driver. Sometimes this worked, and sometimes it didn't. If I have my choice, I use an nvidia board...the drivers are easy to install, they're fast, you don't have to worry about getting the right module, and most of all they have a knack for just working immediately.

I wish those drivers were FOSS, but they aren't. I'm not too proud to run them.

Now...if I can just get the 3d on this ATI mobile radeon IGP320M going......

Kernel and module compability

[Anonymous Coward]

I hate binary-only kernel modules, and all kernel modules should be available as source.

I recently purchased an IDE Raid controller, and naturally I chose one where the box said "Yes! Works with Linux!".

Sounds great so far, doesn't it? Problem was that the drivers turned out to be precompiled binaries for the kernel shipped with the following distributions: SuSe 7.1-8.0 and RedHat 7.2-9.0.

I returned the controller and demanded my money back.

First of all, I ran Debian with a kernel not supported by the binary drivers.

Second, with these kernel-spesific drivers I would be unable to upgrade my kernel (what if an dangerous kernel exploit is found?)

Third, "Yes, works with Linux!" is a lie. What the label should say is "Yes, works with a couple of Linux kernels!"

Fuck the binary drivers. I don't see the point. It's not like they would loose money by giving away the source to the driver -- they'll sell the hardware anyways, won't they!?

Re:Linux driver model doesn't help

[StenD]

The fact that Linus states that there is no exception must worry a lot of companies out there who are producing binary drivers for Linux

No, because he immediately explains that it isn't an exception, it's a clarification:

There's a clarification that user-space programs that use the standard system call interfaces aren't considered derived works, but even that isn't an "exception" - it's just a statement of a border of what is clearly considered a "derived work". User programs are _clearly_ not derived works of the kernel, and as such whatever the kernel license is just doesn't matter.

And in fact, when it comes to modules, the GPL issue is exactly the same. The kernel _is_ GPL. No ifs, buts and maybe's about it. As a result, anything that is a derived work has to be GPL'd. It's that simple.

Now, the "derived work" issue in copyright law is the only thing that leads to any gray areas. There are areas that are not gray at all: user space is clearly not a derived work, while kernel patches clearly _are_ derived works.

But one gray area in particular is something like a driver that was originally written for another operating system (ie clearly not a derived work of Linux in origin). At exactly what point does it become a derived work of the kernel (and thus fall under the GPL)?

THAT is a gray area, and _that_ is the area where I personally believe that some modules may be considered to not be derived works simply because they weren't designed for Linux and don't depend on any special Linux behaviour.

And specifically talking about nVidia:

In contrast, these days it would be hard to argue that a new driver or filesystem was developed without any thought of Linux. I think the NVidia people can probably reasonably honestly say that the code they ported had _no_ Linux origin. But quite frankly, I'd be less inclined to believe that for some other projects out there.

And, to wrap it up:

No, the note at the top of the copying file is something totally different: it's basically a statement to the effect that the copyright holder recognizes that there are limits to a derived work, and spells out one such limit that he would never contest in court.

See? It's neither a license nor a contract, but it actually does have legal meaning: look up the legal meaning of "estoppel" (google "define:" is qutie good). Trust me, it's got _tons_ of legal precedent.

Re:Pragmatism

[Anonymous Coward]

With the nvidia drivers I get a good refresh rate (maximum for my monitor, yay), decent 2d performance, and great 3d performance (equal with windows).

This enables games to run with as fast or faster performance than windows. Games are the most benchmarked thing on computers, and it enables Linux to get its name in there and some more exposure.

Sure I would prefer open source drivers, but for me; the Nvidia drivers have caused me little grief, and I get to use all of the features of my (formerly) expensive video card.

Re:What Linus is missing here...

[geirhe]

I really can't see how linus can claim copyright to the distribution of any source which happens to run with the linux kernel - but does not contain any part of it.

He doesn't. He is claiming copyright for the interfaces you have to use to make a kernel module. You are free to do whatever you wish to the bits you have written yourself - you have the copyright on that.

However, including the *.h files needed to make your code a derived module makes use of something someone else have written. You are not allowed to make copies of that code without the consent of the copyright holder.

The other copyright holder is willing to give you the right to make copies of his code and distribute the result. The terms may, however, be dictated by him. He owns the copyright to the code you need, after all. The terms you are being offered are based on the concept that if you want to link to the linux kernel and distribute the result, you have to let everyone else do what you just did to the code you wrote.

You are, of course, free to try to negotiate a better deal. Be my guest.

Re:Pragmatism

[October_30th]

Meanwhile linux didn't get any better from it

Yes it did. I get proper OpenGL acceleration on my Linux box now.

not-quite-obscure-nividia-just-didnt-bother-compil ing-their-driver-for-it

You know, if the installer cannot find pre-compiled drivers for your card, it will compile them for you. How's that for service?

most importantly you don't know what the driver is doing on your system

Yeah, right. Have you ever read through the code of your LAN card driver, too? How about the USB controller and SCSI-card? Most important of all, how many driver exploits have you heard of either in Windows or Linux?

Unfair moderation

[Anonymous Coward]

Yes, I'm replying to my own down-modded post. I feel that the Flamebait moderation is uncalled-for and believe that the moderator has simply missed the point of my post.

It is a morally incorrect stance to demand that 'because I did all this work that you are benefitting from, you must pay me back in kind', as the original poster to whom I was responding to said (in a sort of way). He correctly makes the point that this is a community and that it is in everyone's best interest (cumulatively) for everyone to play by the rules, so to speak, and release source code into the open. However, to demand that someone open their source code is to usurp that person's Freedom and that is where the moral error arises.

When a person derives a work from GPL'd code, there is a legal understanding that the derived code must be placed under the GPL as well. This is designed into the GPL because the derived work benefits from having existing source code to be based off of and as 'payment' for this use the deriving programmer gives up his rights to copyright the derived code. It is a raw deal to some, heaven to others, but all parties come into the deal knowing what is required of them.

OTOH, a person who simply writes a driver that is linked at runtime to the kernel is under no such obligation to do so. This is precisely because the code is not based off the GPL'd kernel code but rather designed to a specification which the kernel implements. The use of kernel headers and libs would arguably be considered Fair Use of the GPL-copyrighted work. It would be nice for the developer to include the source under the GPL, but he is in no way required to do so by law. He does not benefit from the GPL'd code in any way except in the sense that the GPL code exists and he is finding a way to serve a need in users of that code.

But another point that I was making in my original response was that closed source binaries in no way hinder the uptake of an OS. Windows, being the premier closed source whipping boy, does no worse because Windows drivers are closed. It is arguable that it does better because binaries can be standardized at the source rather than having many incompatible user-altered binaries floating around. Support becomes a matter of fixing a problem once and floating a new binary rather than applying a patch to the source code and hoping that everyone who's using the source can merge the changes correctly.

Linux is not hurt by closed source drivers. The Free Software Movement may be set back because drivers for advanced hardware may not be available in any form except binary, but Linux itself will soldier on regardless. In fact, the more drivers that are available for Linux (open or not), the more likely it is that a user will be able to use the operating system without an incompatible hardware problem.

Re:Pragmatism

[MS_is_the_best]

Yes it did. I get proper OpenGL acceleration on my Linux box now.

That is true and an advantage. Unfortunately the drawbacks are perhaps larger (depends on your opinion). An open driver with the same performance would be better (but perhaps impossible).

You know, if the installer cannot find pre-compiled drivers for your card, it will compile them for you. How's that for service?

Nope, only the interface around the binary core is compiled, not the driver itself.

Yeah, right. Have you ever read through the code of your LAN card driver, too? How about the USB controller and SCSI-card? Most important of all, how many driver exploits have you heard of either in Windows or Linux?

Yes, I have. Lots of others have done this too. Being able to look up the source in case of network troubles is really a great help. The debug mode of the driver is very helpful, the source even better.

Re:It's really simple

[ajs318]

You put two programmes on the same CD => they are not necessarily anything to do with one another. As long as you have permission from the copyright holders of both, that's fine.

You write a programme that interacts intimately with another other than via the established interfaces for user space => they definitely have something to do with one another. Your programme may well be a derviative work. If it makes use of any information obtained from another programme {e.g. a .h file in an obscure -devel package} then it is quite clearly a derived work.

Wouldn't life be so much simpler if the law just said that you have to disclose your source code, no exceptions?

kernel-api-headers package?

[Akai]

I'm no C expert, but I imagine there is a to get a list of available functions from the kernel, some query or another. One that is available, at least as root, from userland. Something like how the System.map file is generated from a kernel compile.

If this facility exists, would a dump of the function calls in the kernel, with apropriate calling information (data types, number of parameters, etc) converted info a new set of .h files (which don't contain any inline'd code, just function defs), would the resulting .h files be considered GPL? After all if I use a GPL word processor, my documents are not GPL'd, right?

In ethical belief, I side with the GPL-only crowd, in the rome-wasn't-built-in-a-day argument, binary drivers wins for me.

If I were NVidia, which seems to be both the most loved and most hate bin only driver, I would see if it was possible to move all protected/proprietary code to the X11/GLX driver. X11 has full (or near full) access to the system a t a low level, and it's BSD licensed so no toes are stepped on.

Re:Kernel and module compability

[Anonymous Coward]

I would gladly code the driver myself, if I only had the spesifications of the card. Reverse engineering the whole shit is ofcourse an option, although a time-consuming one.

What's your point anyway? Should I nod thankfully and not complain? I *paid* for the damn hardware, so I expect it to work the way I want it to.

Re:Kernel and module compability

[Anonymous Coward]

And imagine this scenario

your raid driver requires kernel 2.2.18
your sound card driver requires kernel 2.4.19
your network adapter driver requires kernel 2.2.21

the drivers has to be open sourced.

Depends

[famazza]

It depends rather the module uses or not other GPLed files, either source or headers.

It's as simple as MS claims to be. GPL infects everything it touches. If you use any header or any source code from Linux kernel (or whatever GPLed code) it MUST be released under GPL.

But this is theory. We must avoid problems with this kind of GPL violation in order to keep major non-free drivers avaiable. (oh no, if Stallman sees me talking like this... :o) At this moment popularity is also very interesting.

Let's not become like SCO.

No closed source means...

[Anonymous Coward]

No software for linux.

No software for linux. Linux = dead without software.

You cannot have it both ways. Free and commercial support.

This isn't limited to the kernel.

[Moderation abuser]

There are a load of GCC headers and other GPL'd library headers which are compiled into any code you build. The library itself may be LGPL'd but the code, data astructure definitions in the headers are included into the resulting binary, so if this problem is as you state, it is a GPL issue rather than a Linux kernel issue.

If this is the case then *any* binaries produced by GCC or which even look at headers or data structures included with any GPL'd or LGPL'd library must also be [L]GPL'd.

So the GPL in fact hurts Linux...

[Otis_INF]

You don't have to agree with me, but I can only conclude that the restrictive GPL with its vague derived work clause is hurting Linux: a company won't put trade secrets into a binary driver to run the risk of losing these trade secrets because of a lawsuit based on the GPL which states that the binary only driver has to be opened up because it violates the GPL.

OR get a proper system into place like in Windows, for kernel modules so the modules are not 'derived works' (calling kernel modules derived works is pretty stupid IMHO, but that aside) OR live by the fact that not a lot of hardware vendors will offer drivers for their hardware. (which then results in the 'home brewn' drivers which are not always up to par).

Reading all the comments here I simply can't understand why so many people are so hardheaded. Don't you see / understand that to make Linux an OS with great support for a LOT of hardware, you have to convince hardware vendors their drivers will not be part of a GPL-case? Apparently not.

keep an eye on step two

[ciaran_o_riordan]

> I'd rather run a 95% Free Software operating
> system, than a 95% closed operating system

All software should come with permission to study, share, modify, and redistribute. If 95% of the software you use comes with these freedoms, that's a great, but we mustn't lose sight of the final goal. We've come so far, we have soooo many pieces of software that people said we'd never have. If hardware companies would just give us specs, we could write our own drivers, and y'know I bet we'd write better drivers than they do! ;-)

Re:Pragmatism

[Tim C]

More than that, last I heard NVidia was under NDA from one or more third parties concerning some of the code in their drivers. They simply can't release it, as it essentially isn't theirs to release.

Actual case of a module affected: PWC/PWCX

[Nemosoft Unv.]

So far, most posts in here have been about binary only drivers provided directly by hardware vendors. My case is somewhat different, yet if I read everything correctly, I could still be affected by all this.

I am the author of the Linux Philips webcam driver [demon.nl], which supports a lot of Philips and Logitecht webcams, and a few others. This driver has been in development for nearly 4 years, has been formally introduced into kernel 2.4.5 and has been in continual support by yours truely ever since the first public release, some 3 years ago. Now here's the catch:

Part of the driver (PWC) is Open Source, even in the kernel under the GPL. With it, you have a functional webcam driver, but there are some limitations; you can't get the full resolution and not as high as framerate as is possible. For that, you need a binary only plugin, called PWCX. It contains decompression routines that allow you to use the cam at its full performance. These decompression routines fall under an NDA and are thus not public. Judging by the number of mails and webvisitors [nedstatbasic.net] I think this driver has been quite a success. And now this may no longer be possible.

The point is, that by the strict interpretation held by Linus et al. I can no longer make this PWCX driver, thereby depriving a lot of users of a useful bit of hardware. Or at least make it quite a bit less enjoyable. I might as well remove the PWC driver altogether form the kernel then, hmm?

First off, I feel sorry for the thousands of Linux users that use my driver (PWC and/or PWCX) and may no longer be able to do so. Second, I'm getting pissed off beyond measure by this Open Source fundamentalism because it is my driver that may be turned into a worhtless piece of code.

It is my ass here that's on the line; I signed the NDA with Philips and if I goof up and accidently post the decompressor code or fail to protect it properly, I will be the one standing in court, not Linus. Second, I went through all the trouble of getting in contact with Philips, trying to convince them to help the Linux community and indeed they have, and I commend them on that. But they have their reasons to shield some parts from prying eyes (read: competition) and I can't blame them. So that's why there's and NDA and it's even fairly relaxed. Without the NDA there wouldn't even have been a driver.

BTW, Philips spent exactly 2 webcams and a couple of manhours on getting the paperwork done in order to get their product supported in Linux for 3 years across 3 major kernel versions, including online helpdesk. I think that's damn cheap. I cannot count the hours I spent on programming and debugging and tracing intractable bugs, not to mention the time spent in helping users by e-mail. I've also spent many an hour to get this PWCX module crosscompiled to various hardware platforms in order to extend it's Linux usage as much as possible. Now that may appearantly all have been a big waste of time. Thank you very much!

No, it is time to realize for anybody who thinks that the GPL is the Holy Grail of computing that this is not going to work. You cannot force anyone to oblige by a volountary license (because that's what the GPL is: nothing more, nothing less). As I wroting in my piece on tainting the kernel [demon.nl], if you make it any harder for (hardware) vendors to support their product in Linux, they'll drop it like a brick because they don't have to. This way Linux will never gain any real acceptance.

Finally, it's also not very wise to piss off people like me, who are doing their best, and made some small yet clearly apreciated contribution to Linux. I would also rather have a complete Open Source solution, but I'm realistic enough to know that is not possible in this Universe. So I think I've struck quite a good comprise. But if I am being told now: "well, that isn't good enough", I might just throw in the towel in the ring altogether.

- Nemosoft

Re:Actual case of a module affected: PWC/PWCX

[soccerisgod]

As I see it, you link your GPLed work to some proprietary work. There's hardly any base for calling this a violation of the GPL. If normal binary-only drivers are in a grayzone, than your zone must be #FEFEFE. I wouldn't worry about legal implications here too much.

Besides, I think this discussion is mostly aimed at manufacturers - which indeed have a choice wether or not to include everything as source code. On the other side, anyone who disses you for doing what you do is clearly a moron. I'm sure the great majority of users appreciates your ongoing effords - most likely even the evangelists. Otherwise your driver wouldn't have made it into the kernel :)

Re:Pragmatism

[nathanh]

The main problem I still see is that you need to draw a line somewhere and allow closed source drivers or else you impose a limit on what Linux user can do. That is the ultimate consequence of what you're saying. Nvidia cards are mainstream and someone is bound to create an open source driver for them if nvidia refuses to. But if you use hardware that isn't mainstream and are incapable of developing your own driver, are closed source drivers still a bad idea? Or should people who can't write their own drivers stick to Windows? I am just curious, how far do you want to take this?

It's up to the individual to make their own decision. If someone wants to use closed-source binary-only drivers then I won't stop them. It is their freedom that they are throwing away.

How far do I personally take this? Where do I draw the line? For the record, if I have hardware and there is no open-source driver then I simply don't use the hardware. Or I sell it. Or I write the driver. I have stuck to these principles ever since switching to Linux.

For example, I bought an nvidia TNT2 several years ago. I was fooled by nvidia's claims that they were going to support Linux. They told the truth - they did support Linux - and the mistake was mine because I incorrectly assumed nvidia was going to release open source drivers. But I still felt cheated. I joined the Utah GLX project to write drivers for the TNT2 and I think the result was successful enough. I later sold the card and bought something that was properly supported by open source XFree86 drivers.

I don't have a problem with "imposing limits" on Linux users. I remember using Linux when there were no supported video cards at all (before X386 was ported). You had text mode, and that was it. Linux grew beyond those days without requiring binary-only drivers. We wrote open-source drivers as required and Linux grew from basically nothing on the strength of open source. Why do we need to change the winning recipe now? What has changed so that we suddenly need binary-only closed-source drivers, or Linux will fail? I don't see it. Open source got us this far. It'll take us the whole way. It may take slightly longer, or limit our choices of hardware, but so what? I see no reason to change strategy now. I see no reason to compromise the ideals to fulfil a crass gratification.

GPL v3 will need to address this

[linuxbikr]

The problem with kernel modules is as Linus has stated: they fall into a grey area of the GPL.

Under a strict GPL interpretation, modules can be considered "derived works" because they link dynamically into a GPL environment (the kernel). The modules depends on kernel headers to compile and use internal kernel data structures exposed through module interfaces that are technically under the GPL. Thus, if you interpret the GPL as written, then yes, all modules would be required to be released under the GPL.

Clearly such a situation is not acceptable to hardware manufacturers and Linus recognized this. Hence his "binary only is allowed for modules" rule. It is the kernel developers themselves that are changing the module environment to try and enforce the strict constructionist view of the GPL.

RMS recognized this issue and developled the LGPL. The intent behind the LGPL was to allow for the development of GPL'd code that could be incorporated into binary-only products without tainting those products provided the binary product announced was linking to LGPL code and made it available on request (or distributed it with the product). As long as a clear separation exists between the proprietary product and the LGPL'd code (in other words, the proprietary code links to the LGPL'd work. If it copied LGPL'd code into its code base, then it would become tainted), the two models can co-exist.

RMS doesn't like the LGPL. It is a compromise license designed to fit the realities of the world rather than what he wishes it could be.

In my opinion, maybe the simplest solution is to relicense future versions of the Linux kernel under the LGPL. The distribution and modification requirements for the kernel proper would still be in force as with the GPL and make it compatible with binary-only modules explicitly since this very issue of linkage and mixing is exactly what the LGPL was designed to address. For the record, I prefer the LGPL over the GPL for practical, real-world open source development. It provides the best of both worlds when approached correctly.

If the LGPL cannot fit, then clarification is required for the definition of derived works as encompassed by copyright law and how the GPL perceives it. v3 of the license should maybe incorporate a better, clearer definition of dynamic linking when no source is exchanged between two programs.

I agree with Linus. Binary-only modules should be acceptable under the GPL since they do not incorporate GPL'd works directly except through runtime linkage.

Re:Pessimists are mind-killers

[jlar]

Of course, in real life not all are born equal. What I was trying to convey was that, in my opinion, society should work towards giving, e.g. disabled people, equal opportunity (though I do realise that it is a goal that cannot be reached in full).

Equal opportunity does not mean that everybody will be able to become astronauts. But it does mean that most people will have greater opportunity to shape their lives according to their wishes than in other societies.

And sure society is influencing how you live your life. But we also have a choice for ourselves. In my 'dream society' this choice is maximised.

With all due respect.....The pauper principle.

[Anonymous Coward]

Simple. They want all the benefits of OSS without all the pain of principles. Remember if having principles was easy, the world wouldn't be in the state it's in. But actions do speak louder than words.

How about user-land apps...

[yeremein]

...that include Linux kernel header files?

Linus commented in the LKML thread that "YOU CAN NOT USE THE KERNEL HEADER FILES TO CREATE NON-GPL'D BINARIES" (emphasis in original).

I've written a userland program for my company that #includes a single kernel header file (linux/nbd.h, the network block device).

It's mostly of academic interest, since my company has no plans to ship this program, but does #include'ing that GPL'd header file mean that the program must now be GPL licensed?

I didn't think so, since I'm not getting any actual GPL'd code in my own program (just #defines for ioctl() numbers, and a couple of struct definitions), but Linus's comment seems to say otherwise.

This is pathetic

[pclminion]

This is exactly why I'm choosing the BSD license for my code. If you want my code, by all means USE it. By all means CHANGE it. In binary form if you wish. All I ask is that you don't claim that you WROTE IT yourself.

More and more these days, I view the GPL as moralistic masturbation. It's pathetic and sad. There are plenty of other things in this world that are worth being moralistic about. I don't see how software development falls under the same heading as "helping the homeless" or "stopping persecution" or any of those things we really ought to give a shit about.

Sorry, but I just don't want to waste my energy on that crap. My primary objective with my code is for people to USE it. Not to sit around smoking cigars with the boys arguing over who has a "right" to it. Grow up and find something worth fighting for, for chrissake.

Re:Linux linkiing analogy

[Anonymous Coward]

I know everyone is going to cry Troll on this comment, but when read something from Linux that says anytime you include a kernel header, the resulting object file is now under the GPL, I keep thinking of the Microsoft comment about how the GPL is a virus. I mean, what if you include a GPL'd header without even knowing it? You could conceivably inlcude a header that has no copyright notice in it, which is really big, and never notice that ten files down the include rathole, there lies a GPL'd header. You're roasted at that point. I guess you could argue that the devloper(s) didn't go a good job at due diligence, but come on. I need strncmp, I include string.h. I don't go sifting through to see what other headers I'm grabbing along with it. Obviously this is more important when writing kernel space code, but I think you get the point.

With all the shit with SCO, GPL this and that, and what's free and what's not, I can only think that BSD would become more popular. I may switch my home machine from Linux to BSD just to be a dick. Most Linux newbies switched from windows just to be a dick

Re:It's really simple

[morgue-ann]

Anything .... which you statically-linked to GPL code, MUST BE GPL.

What about dynamically linking to code that's contained in a cramfs in the same ROM as the closed-source code?

This isn't an artificial example. I write digital camera firmware. We'd like to use the MAD mp3 decoder library [underbit.com] (GPL'd), so how 'bout we elf2flat it, stick it in a compressed ramdisk image in ROM, then use (a tweaked) NetBSD ld.elf_so to load it?

[note: we're planning to contact the MAD author & try to negotiate a license so we don't have to try the trick above]

On selective memory.

[mindstrm]

See, I've used linux since around version .95

I remember, clearly, reading the kernel license, which was the GPL with an added clause: that binary-only kernel modules were permitted, as long as they use an interface that already exists in linus' kernel tree. So you could write a new binary only network driver, or scsi driver, or video driver, but not some totally new kernel functionality, and wrap it up as a module.

Now, I realize that this clause seems to have never existed, and I must have mentally mixed up some mailing list posts with the actual license... I can't find it anywhere in the kernel archives.. but I swear Linus' older kernel license was not just the stock GPL... it had some exceptions.

Anyone else remember this, or am I off my rocker?

Re:Linux linkiing analogy

[dgatwood]

My favorite would be:

If you have an apple and I have an apple and we exchange apples then you and I will still each have one apple. But if you have an idea and I have an idea and we exchange these ideas, then each of us will have two ideas.

---George Bernard Shaw

Re:Linus doesn't get to define "derived work"

[jpallas]

Furthermore, RMS doesn't get to define "derived work", and Darl McBride doesn't get to define "derived work."

If I had Linux in mind when I wrote a haiku, is it a derived work?

The one definition

Of being a derived work
Is copyright law.

Re:GPL v3 will need to address this

[Anonymous Coward]

Clearly such a situation is not acceptable to hardware manufacturers and Linus recognized this. Hence his "binary only is allowed for modules" rule.

There is no such rule and never has been. Linus has commented on this many times including in the comments linked to from the story. Linux is licensed under the GPL. The GPL makes specific requirements with respect to derivative works. Linus is of the opinion that SOME binary modules may not be derivative of the kernel. He very sensibly recognises that ultimately that's a legal question on which he isn't qualified to give an absolute answer.

Re:Free? I don't think so.

[Trejkaz]

This is where a model like an extreme version of the 'random model' might come in handy. Release neither the source, nor the binaries, until the sum total of donations crosses a certain mark.

Of course it would have to be a bloody good product to achieve it.