Linus Denounces NDISWrapper, Denies It GPL Status

eldavojohn writes "On message boards, Linus Torvalds was explaining why NDISWrapper is not eligible to be released under the GPL even though the project claims to be. Linus remarked, "Ndiswrapper itself is *not* compatible with the GPL. Trying to claim that ndiswrapper somehow itself is GPL'd even though it then loads modules that aren't is stupid and pointless. Clearly it just re-exports those GPLONLY functions to code that is *not* GPL'd." This all sprung up with someone restricted NDISWrapper's access to GPL-only symbols thereby breaking the utility. Linus merely replied that "If it loads non-GPL modules, it shouldn't be able to use GPLONLY symbols." As you may know, NDISWrapper implements Windows kernel API and then loads Windows binaries for a number of devices and runs them natively to avoid the cost and complication of emulation."

You can't win this one, Linus

[arth1]

As long as there are no usable alternatives for many common chipsets, you won't win this one, Linus. People are then going to mod the kernel source so ndiswrapper appears kosher, and all you'll get is a +nd version for all major distributions, and fewer people using relatively clean source.

Re:You can't win this one, Linus

[corsec67]

I don't think that Linus is trying to say that people shouldn't be able to use NDISWrapper, just that if you use it, your kernel isn't a pure "gpl only" kernel.

IIRC, that matters to people trying to report a bug: if your kernel isn't GPLONLY, then you will have a much harder time trying to get anyone to do anything about a crash. I think that is correct, since with NDISWrapper you just loaded a big blob of who-knows-what into the kernel, which can't help stability.

Personally, I dislike wrappers like that, which I have to use for the flash plugin on my AMD64 computer. It allows companies to say "yeah, we support AMD64, just run our plugin in this wrapper", which fails quite often. Linux isn't only on i686, so why should we accept binary blobs of code for that processor?

Re:You can't win this one, Linus

[starm_]

also if your kernel is not pure gpl IT IS ILLIGAL FOR YOU TO DISTRIBUTE IT. You are allowed to _use_ it like that but not distribute it. There are good reasons for that. Consider the following scenario:

Intel develops new closed undocumented architecture with a 16 core cpu. Similarly to current network or video cards, you need a proprietary driver to enable the super accelerated multicoreness. In order to enable the use of the newer faster computers, Linux vendors do what they did with the other proprietary drivers, label these drivers as "not part of the kernel" put them in a wrapper and ship their version of Linux with the proprietary drivers which, for now, intel is giving away for free with the hardware. For a while everybody is happy and content. The new 16 cores chip becomes the new standard. There are even 32 core chips on the market and the 64 cores chips are soon to be released all of which rely on proprietary drivers.

Suddenly, we hear that a large company, Lintelsoft, started by ex MS executives, makes a deal with Intel, a very lucrative deal for Intel, to license the drivers. Intel then says they won't give away the drivers anymore but you are free to buy the brand new Lintel Linux distribution. This distribution, which sells for 699$ a piece is all GPL'd except for those drivers that have become so standard that you need them in order for computers to run at a reasonable speed.

Open source programmers scramble to write free replacement drivers that work on their Gnubian distribution but only manage to make drivers that can run the multi core cpu's at 1/20th the speed as Intel won't release documentation or specifications. Linux is rendered mostly useless except for the Lintel distro, (which is also available for free and with sourcecode as Lintelora excluding the proprietary driver sources of course) You can always plug in the Gnubian drivers in the free Lintelora project and get a working computer but it will only run at 1/20th the speed of the commercial 699$ a pop version and isn't powerful enough to run the new Mozilaurus browser smoothly.

In this scenario, Lintelsoft would have effectively stolen Linux from the open source community, making profit with their source code and breaking all versions that are free.

How can we let anyone close up an obviously derived work based on some wrappers?

Notice that, even today I sometimes need to pay to get a fully working Linux from certain vendors, like Mandriva. (if i don't pay, 3d acceleration wont work.) I expect that kind of twisting of the law by commercial vendors. It surprises me that even Ubuntu is including proprietary video drivers nowadays.

What's worst is that legally in order to maintain copyrights you need to make reasonable efforts at protecting those rights. Legally if the open source community waits until the binary drivers become problematic before acting. Proprietary vendors will be able to argue legitimately that closed source code has been allowed in the kernel by the open source community for a long time now: You are not legally allowed to suddenly change your mind about interpretations to suit current needs.

Re:You can't win this one, Linus

[corsec67]

I agree with you, but the problem is that several companies are already doing something quite similar, and it is called TiVoization [wikipedia.org]

Fon, TiVo, and a few other companies distribute devices that run a linux kernel. To be compliant with GPLv2 they distribute their changes to the linux kernel, but the problem is that the hardware only runs a kernel that has been signed by the hardware manufacturer. That means that you can compile a new kernel using their changes, but can't load it onto the device.

TCPA is something that Intel and Windows are trying to do that would do the same thing for general-purpose computers.

That was one of the things that GPLv3 was trying to combat, but Linus doesn't want to use that license for the kernel, so there isn't much to prevent people from doing that in the future.

Re:

[misleb]

As I understand it, Flash pretty much fails at 64bit on EVERY platform. Maybe not Macs (my knowledge of them is quite limited), but I definitely have memories of Windows Vista 64 having a hard time of it. Pretty much it's 32bit wrapper'd version or bust.

32bit vs. 64bit has always been nearly completely transparent to the user on Macs (remember the G5 is 64bit). So it is possible to design a system where the differences are hidden. But of course a lot of that transparency is due to Apple having control ove

Re:

[corsec67]

I was actually wrong with my original comment: the GPLONLY stuff is actually some functions that are only available to gpl modules, and this doesn't have anything to do with making the kernel tainted.

As for loading a non-gpl module, that makes your kernel "tainted", and generally kernel maintainers will not even accept a bug report for something that has to do with a "tainted kernel".

I didn't mean that the kernel maintainers would jump to fix the issue, but with a tainted kernel, like using the nvidia modul

Re:

[repvik]

Torvalds is claiming that NDISwrapper -- a loader like firmware-loading, or BIOS-updating drivers should be tainted as non-GPL because it loads some non-GPL material.

Tovalds deftly skipped over answering the issue of all the firmware-loading and updating drivers that are permitted to be called "GPL" even though the firmware they load is not.

There is a major difference here. NDISwrapper loads code that runs in kernel space. Firmware loading loads firmware to a device which runs it separately. A bug being cau

Re:You can't win this one, Linus

[betterunixthanunix]

Thank you. I am an open source advocate, but the driver for my network card is a half-assed approach that doesn't connect to any access points, or do much else that can be called "useful." ndiswrapper is a bandage that can be used until the kernel team and third party module developers can produce something usable. Trying to get rid of it will only restrict Linux adoption.

Re:

[Knuckles]

Nobody's trying to get rid of it, read the numerous other posts correcting that assumption. This is just about the kernel losing GPLONLY status if you load ndiswrapper, which is important for debugging purposes and other things.

Re:

[muuh-gnu]

> I am an open source advocate

Like in "Do as I say (use open source), but not as I do (use closed source drivers)"?

> but the driver for my network card

Get another card. Reward manufacturers supporting Open Source by supporting them.

> Trying to get rid of it will only restrict Linux adoption.

If you have to use closed source to just connect your Linux box to a network, then just fuck it and stay with Windows or buy a Mac. The whole point of GNU and Linux was to make a working _free_ system, not just

Which other card?

[tepples]

Get another card. Reward manufacturers supporting Open Source by supporting them.

Which card do you recommend in each format (classic PCI, PC Card, PCI Express, ExpressCard, chipset in desktop PC motherboard, chipset in laptop PC motherboard)? What new desktop and laptop computer models do you recommend that come with one of these cards?

If you have to use closed source to just connect your Linux box to a network, then just fuck it and stay with Windows or buy a Mac. The whole point of GNU and Linux was to make a working _free_ system, not just to get you out of paying for a closed source one.

Which notable personal computer to the general public uses coreboot [wikipedia.org] or some other free BIOS?

Re:

[Cheapy]

Wow, it's an open source fundamentalist! Let's ban closed-open source marriages since they aren't pure and the most Holy of Programmers has spoken out against it.

Re:

[WK2]

I'm not the OP, but until recently, I used ndiswrapper to make my wireless card work (and might go back. the OSS driver is buggy.)

>> I am an open source advocate

> Like in "Do as I say (use open source), but not as I do (use closed source drivers)"?

No, as in I advocate open source, but am not a hardcore zealot. I have to work in the real world, and prefer function over ideals.

>> but the driver for my network card

> Get another card. Reward manufacturers supporting Open Source by supporting t

Re:You can't win this one, Linus

[F452]

I was looking in to this recently and found lots of info at:

http://www.fsf.org/resources/hw/net/wireless/cards.html [fsf.org]

As posted elsewhere in this discussion.

[imtheguru]

http://linux.slashdot.org/comments.pl?sid=476560&cid=22656000
by F452 (97091) Alter Relationship on 14:11 Wednesday 05 March 2008

Cheers to F452 for this information.

Re:

[idontgno]

How do I run this "GPL" solution on my Sparc-based Linux system? The card is PCI but the binary that gets loaded runs on Intel-only. So it's compatible hardware, and software that claims to be GPL, but the system is a doorstop.

So, you're hosed. That has nothing to do with me. NDISWrapper works for me. You solve your own problem, in ways that don't try to deny me my workaround.

NDISwrapper is not a bandage, it is a Typhoid Mary allowing proprietary software to infect the kernel.

Oh, get over yourself. It's

Re:

[Intron]

I never said you couldn't use it, just that it is not GPL no matter how you dress it up. So it's fine if you want to install it and run it on your system, you just shouldn't be able to sell it or distribute it with NDISwrapper installed, because it isn't GPL.

If you allow NDISwrapper to be GPL, then any manufacturer can put a wrapper around proprietary code and stick it in the kernel. Graphics cards, modems, printer interfaces - a lot of hardware uses the processor to do some of the work and would like to

Re:

[nonsequitor]

My sentiments exactly. You can break ndiswrapper AFTER Linux fully supports every wireless chipset that Windows has drivers for. Until then, please learn to live in the real world. Or create a new symbol other than _GPLONLY that ndiswrapper can use instead. Breaking things that work for pedantic reasons is childish and punitive.

Re:You can't win this one, Linus

[A nonymous Coward]

Or do the right thing in the first place and don't falsely label ndiswrapper as GPLONLY.

Re:You can't win this one, Linus

[nonsequitor]

It was a hack to make things work from what I understand, and I could be wrong. I agree it should register as a tainted kernel. However whoever 'fixed' the Linux kernel and broke ndiswrapper should have provided a mechanism which will continue to allow ndiswrapper to work, and show that the kernel is tainted. Breaking things and starting fights between development teams is the wrong way to go about it. Maybe that exists and the ndiswrapper team isn't using it, if that's the case then the ndiswrapper developers should change the wrapper to identify itself properly.

Re:You can't win this one, Linus

[richlv]

it's quite important to understand the issue, i think.
it has been repeated in the thread several times already, but i'll try again (from my, outsider viewpoint, but i'd hope somewhat educated one :) ) - nobody is _breaking_ anything.

short interpretation by me :
kernel has a variable which denotes that it is gpl only - that is, the core and all loaded modules are gpled.
this shows to people trying to debug things that they can debug everything and there are no binary modules that break shit in unexplainable ways.
now, if a binary module is loaded, kernel notes in the variable that it is no more gpl only and breakages can be extremely hard to debug and impossible to fix. i guess you'll agree we don't want the kernel devs to waste time on such cases.

now, ndiswrapper itself poses as gpl, thus it does not taint the kernel, but it then loads modules inside itself...

so you get a tainted kernel that does not identify as one.

and that is the only behaviour which is going to change.

if i have misunderstood things miserably, correct me, thanks :)

Re:

[nonsequitor]

The ndiswrapper source is GPL, however it loads binary blobs which were independently developed. ndiswrapper should have access to the symbols, but it should have a mechanism for indicating the kernel is tainted after loading a binary blob.

Logically it follows that ndiswrapper is a derived work, BUT the binary blobs its loads are not. I don't see how this is at all productive and it IS quibbling over pedantics. Whether or not its their right to be pedantic and counter-productive does not negate the fact

Re:You can't win this one, Linus

[idontgno]

I think you should know that you're engaging in the same kind of ideological wordmongering you accuse the other side of.

Look, I'm a pragmatic open source user. I understand the ideology.I generally agree to it. But not because of its perceived social Rightness, but because it's a reliable source of Good Bits. Its ideology supports methodology which supports good stuff like working kernels.

Upthread, I chastised a Free Software hyperbolist for being unrealistic and ignoring the practical side. Now I'm going to do the same in the other direction here.

The taint flag is a disclaimer of warranty.

What it comes down to is:

If you use only this open source software, we the developers can troubleshoot it with you, because no matter where the bug lies, we can find it. But if you inject a piece of kernel code which is only known as a black box... all bets are off. At best, we might conceivably help you chase the problem down into this black box, at which point we can only shrug and walk away. But the very real worst-case scenario is that the closed-source module does things to unrelated parts of the kernel which simply cannot be traced because of their origin. The kernel is, after all, a single shared memory space running at a single common privilege level, so you're giving carte blanche to a piece of driver you can neither inspect or verify. And trying to debug that quagmire would be massively unproductive. Really, we'd rather not waste time which would be better spent working on the real open source code and solving problems we actually can solve. So, rather than make any promises in this situation, my NDISWrapping friend, we the kernel developers can only tell you "Y'all on your own, dog!"

(BTW, that's not a real quote from any kernel developer I know of. It's just intended to express one good functional reason for kernel taintedness.)

See, no hysteria, no missionary fervor, no revolutionary speeches or dialectical materialism or any of that. Just practical reasons based on a balance of costs and benefits.

Re:

[0racle]

Since Linus' only concern is if his source is clean, I doubt he has a problem with that. The only 'winning' or 'loosing' he has to do are if his stuff is clean or not, if he is in violation of the GPL or not.

Re:

[pembo13]

The summary doesn't imply that he's trying to get ndiswrapper out. This is how rumours start.

Re:

[WindSword]

Agree whole heartedly. If it weren't for NDIS, I wouldn't be typing this now. Pick another more deserving target, Linus.

Re:

[dubious_1]

Did you actually bother to read the entire thread? Linus is not anti-NDISwrapper. He is at worst ambivalent toward it. He is however unwilling to violate the will of the developer's who released their work under the GPL if they in fact feel that NDISwrapper is not legitimately a GPL module.
There is legitimate cause to believe that NDISwrapper cannot itself be licensed under the GPL if it links against non-GPL code. Since the GPLONLY flag defines symbols that are only exported to modules licensed under t

Re:

[Fallingcow]

I can load the NDISWrapper module without loading any proprietary code. It wouldn't do much, but I could load it.

If there are any GPL WinXP wireless drivers, I could use it to load those, and still be 100% GPL.

This is basically saying that GPL code that allows users to load non-GPL drivers is not allowed, even though, as I understand it, the end user is supposed to be able to do ANYTHING THEY WANT with GPL code or binaries, and restrictions only come in when distributing. I should be able to use a GPL wra

Re:You can't win this one, Linus

[contrapunctus]

I know I'm displaying my ignorance, but I can't find a reliable list somewhere that has models numbers of things that work. And even if I find the model numbers, there are different versions with different chipsets of the same model and there is no guarantee that the model you get has the chipset you want.

I bought 2 wireless cards this way and both needed wrappers and I went back to an ethernet cable and gave up on it.

I remember 10 years ago I was begging people to tell me which motherboard to get for a specific distro and no one would say (multiple sites and boards).

Don't insult me I know it's my fault but I know more that the average user does, and so if I had trouble I know they will.

Re:

[brunson]

There is an alternative to NDISWrapper, buying hardware produced by companies that support Linux. There are plenty of vendors that support development of open source linux drivers for their products, NDISWrapper rewards the ones that don't by expanding their market while they continue spending all their money developing Windows proprietary drivers.

Linus has already changed his mind

[baadger]

Quite frankly, my position on this has always been that the GPLv2 explicitly covers _derived_ works only, and that very obviously a Windows
driver isn't a derived work of the kernel. So as far as I'm concerned, ndiswrapper may be distasteful froma technical and support angle, but not against the license.

-- Linus, in this post [lkml.org]

Re:Linus has already changed his mind

[baadger]

Oh and if that wasn't clear enough...

IOW: I _personally_ don't think there are any license issues, but I do want to have the situation clear to people involved.

-- Linus, in the same post.

This is merely how Linus goes about discussion, do we really have to keep taking posts off of the LKML and blowing them all out of proportion?

No he didn't

[schwaang]

The mail you referenced as a change of heart expresses the exact same view as this one from 29 Feb and others in that series (if you read the TFKernalTrapA you would have seen it):

Excerpted from Linus mail of 29 Feb:

The thing is, I personally don't mind, and I think "derived code" is what
matters, but others disagree, and quite frankly, I'm not going to force
them - I have my _personal_ beliefs, but hey, others have theirs.

So you really need to talk to not me, but to the people who actually wrote
and maintain

Re:Linus has already changed his mind

[earnest murderer]

This is /. What do you think?

I think this argument sounds a lot like a teenager explaining that using a rubber makes it something other than sex.

Re:Linus has already changed his mind

[Chris Mattern]

No, Linus's position here is perfectly consistent. ndiswrapper itself can be covered by the GPL, but when you use ndiswrapper, your kernel is no longer GPLONLY, even though ndiswrapper is itself GPL, because ndiswrapper then loads and runs the Windows driver which is *not* GPL. The fact that ndiswrapper loads and runs non-GPL code doesn't make it non-GPL, but it certainly makes the kernel in which it is running not GPLONLY. If ndiswrapper loaded a GPL driver, the kernel would still be GPLONLY (which, in fact, it wouldn't be if ndiswrapper was not GPL). It's just that ndiswrapper's basic purpose means it'll never load a GPL driver.

Re:Linus has already changed his mind

[SirTalon42]

Linus isn't saying you can't use ndiswarapper. What'll happen, though, is when you report a bug they'll see your kernel has been tainted by a random binary blob they can't touch, and your bug report will be much less useful to them and it'll probably be marked as being much lower priority unless it can be confirmed that the binary blob isn't causing the problems (i.e. re-create the problem without the blob, either by not loading the module or from another machine without the module to begin with).

Again, no ones complaining that you're using it to load non-GPL code.

Re:

[pyite]

The problem with this approach is it lowers the amount of bug reporting you are getting simply for pedantic reasons.

It's not pedantic. It's avoiding a variable that could waste people's time. If the problem isn't the binary blob, remove it and recreate the bug. Problem solved. If you can only reproduce the bug when the blob is loaded... hmm... sounds like it's the blob.

Re:

[ray-auch]

...which doesn't change the fact that this Slashdot news item is poorly reported and inciting a massive flame fest,

Er, this is /. - isn't having flame fests on poorly reported news the entire point ?

Re:

[xivulon]

To clarify even further:

* Is ndiswrapper GPL? Yes
* Can ndiswrapper use GPLONLY code? Yes
* Can ndiswrapper "pass" GPLONLY code (export their symbols) to non-GPL modules? NO
* Can ndiswrapper "pass" GPL code without GPLONLY directive to non-GPL modules? YES

The third point is the one that was raised here and that needs to be addressed by either relaxing the GPLONLY directive or rewriting the code.

Look at OpenBSD for inspiration

[Anonymous Coward]

Before people flame Linus for whining, or trying to sabotage Linux users' ability to run drivers that they need, look at how OpenBSD handled this matter. They too rejected ndiswrapper, and ended up putting their energy towards reverse engineering wireless drivers instead. The results were positive, and in some cases the Linux folks ended up picking up their code too.

And, when you write an open driver, you can maintain it more effectively. You can check it for security problems. You can fix its bugs. With ndiswrapper, you are putting a completely unknown blob of code inside your kernel and trusting it. This is never a good idea when other alternatives exist!

So, use ndiswrapper if you feel that you absolutely must... But it shouldn't receive any official endorsement that would cause most users to be dependent on it. Kernel developers shouldn't think of the wireless driver issue as a "resolved" one. The ideal situation is to reverse engineer a free driver.

Re:

[xtracto]

Wireless cards have to be closed source to use US radio frequency spectrum. In many cases, merely the ability to change frequency or power via software will render these cards unuseable in a legal context.

Hello, that is some interesting information, would you care to elaborate (some links or other citations would be nice). I am authentically interested in your claim as I have never heard about such thing.

shim?

[PenguinX]

Isn't ndiswrapper just a shim, even if it's does very little translation? Businesses have been making proprietary to GPL shim's for ages, you know like Nvidia's driver. Why wouldn't the converse acceptable, or at least worthy of discussion?

-b

Re:shim?

[Omnifarious]

The nVidia driver is also not considered GPLONLY. Your kernel is considered 'tainted' if you use it. You will get no help or support from the kernel people if you have a kernel problem when your kernel is tainted.

Linus wants ndiswrapper to be in the same class. And he's right to. Maybe it's GPL, but it's whole purpose is to load stuff that isn't right into the kernel.

It can load GPL-licensed Windows drivers

[Drinking Bleach]

As ridiculous as it may sound, it's theoretically possible for a Windows driver to be licensed under the GPL. Thus, no legal troubles when loaded by ndiswrapper :)

Re:It can load GPL-licensed Windows drivers

[baadger]

Amusing observation.

I bet the number of GPL'd NDIS drivers for Windows can be counted on one toe. I myself started writing an NDIS 6 driver for a chipset that has no native Vista drivers (although the NDIS 5 XP driver works on Vista x86) but have recently lost interest, despite almost completing basic functionality, because I realised I will never be able to use it under Vista x64 due to the OS's draconian driver signing policy..which cannot be disabled.

Re:

[baadger]

No I am afraid that is not correct. The situation is a lot more complex as of Vista SP1:

http://thebackroomtech.wordpress.com/2007/11/05/howto-disabling-driver-signing-in-windows-vista-64-bit/ [wordpress.com]

None of the workarounds you describe will work with x64 editions of Vista SP1, or for "boot drivers" in x86. I do plan to continue develop of the driver, but I doubt I will ever be able to get it signed using anything but the test certificate from MS. Still, will find out during testing...

Re:It can load GPL-licensed Windows drivers

[srmq]

If a Windows driver was available under the GPL, it would certainly be ported in no time to GNU/Linux, defeating the need of ndiswrapper.

I'd have to disagree with his logic

[MarkusQ]

Trying to claim that ndiswrapper somehow itself is GPL'd even though it then loads modules that aren't is stupid and pointless.

There may be a valid argument for saying that ndiswrapper can't be GPL'd, but this isn't it. In what context would this sort of reasoning be considered sound?

• Trying to claim that a cows somehow itself is a mammal even though it then eats things that aren't is stupid and pointless.
• Trying to claim that 5 somehow itself is an integer even though it then can be multiplied by fractions that aren't is stupid and pointless.
• Trying to claim that Apache somehow itself is open source even though it then serves content files that aren't is stupid and pointless.

...and so on. The claim may be valid but this argument certainly can't be used to establish it.

--MarkusQ

Re:

[sconeu]

Trolltech, however, can grant exceptions to certain licenses, although I don't know which clause permits them to do so.

The fact that they own the copyright on the Qt code and can therefore license it however the hell they want permits them to do so.

So what about GPL virtualization?

[joshv]

So will GPL'd virtualization projects be similarly excluded? It seems to me they are the functional equivalent of NDISWrapper.

Summary completely mistaken

[tarm]

Summary is missing a HUGE portion of what actually happened. The discussion continued [gmane.org]. After the discussion, Linus applied a patch to ALLOW access to GPL_ONLY symbols (for those who care, it's git commit 9b37ccfc637be27d9a652fcedc35e6e782c3aa78).

It's fixed in 2.6.24-rc4

[Englabenny]

Look at the second entry from the top in the changelog:

http://kernel.org/pub/linux/kernel/v2.6/testing/ChangeLog-2.6.25-rc4 [kernel.org]

The battle is over, the discussion is at end and Linus has already signed off a change to restore Ndiswrapper functionality.

I'll side with Linus on this one

[laing]

If ndiswrapper loads proprietary binary-only drivers and provides an API translation between Windows & Linux, then when ndiswrapper itself gets loaded as a kernel module, the kernel's "taint" flag should be set. The purpose of the taint flag is clear and it is quite applicable in this case. I don't think that Linus is saying the ndiswrapper authors cannot release their code under the GPL, what he's saying is that the run-time environment is not "pure GPL".

for those who lack understanding...

[Edgewize]

The stance isn't as crazy as the context-free summary makes it out to be. Linus isn't talking about the license for the ndiswrapper code. He's talking about access to kernel functions which have been marked as "GPLONLY". These are functions which are intentionally not exported to non-GPL code. Linus is saying that allowing ndiswrapper to use them is equivalent to allowing calls from non-GPL windows binary drivers. Which is true.

The debate then is whether or not this should be considered a problem. The contributors who added many of the GPLONLY functions may have different opinions on the topic. Linus hints that the contributors for the USB functions would prefer a strict interpretation and deny ndiswrapper access to the GPLONLY kernel-level functions, because there is a perfectly good user-space API. But everyone involved agrees that ndiswrapper is will never live in user-space, because there's no programmer who would do it and it's a crazy idea anyway. Anyway you slice it, it's clear that ndiswrapper will get fixed one way or another, and nobody is accusing the ndiswrapper project of misusing the GPL.

In summmary, it's a tempest in a teapot: someone accidentally broke ndiswrapper, kernel API discussion ensues, Slashdot posts inflammatory summary, life goes on.

bullshit

[nguy]

The ndiswrapper developers can release their code under any license they like, including the GPL; Linus has nothing to say about that. Furthermore, as long as Linux is under the GPL, Linus has no say over what I link into my kernel. If I want to link code under non-GPL compatible licenses into my kernel, that's my good right, under the GPL.

Linus possibly has a say over whether distributors can simultaneously distribute the Linux kernel and ndiswrapper as pre-packaged binaries. But even there, I don't see a problem: ndiswrapper itself is under the GPL and complies with the GPL. The fact that it allows end users to link code under non-GPL compliant licenses into the kernel doesn't change that.

While I think it would be nice if we didn't have to use ndiswrapper, and while one can argue either way about the desirability of its existence, now that it exists, Linus needs to honor the letter of the GPL and not try to redefine the terms after the fact. If he wants to, he can always relicense his code under different licenses in the future.

Calm down, this is only about reporting bugs

[ink]

The only time GPLONLY is used is when submitting kernel crashes. Linus (and other developers) doesn't want to get backtraces for code that cannot be debugged, because it's in a Windows-only blob. You can still use ndiswrapper, just like you can use the Nvidia drivers -- the only caveat being that you cannot send a kernel hacker a dump.

Re:

[account_deleted]

Comment removed based on user account deletion

And in today's lesson...

[KillerBob]

we learn that in spite of his contributions to the open source community, Linus does not have the right to deny GPL status to anything. (yeah yeah, I know, it's a misleading headine... this *is* Slashdot after all) It's a software license. If the software developpers decide to release under the GPL or LGPL, then it's GPL software. Period. Whether or not the software is a shim for a binary blob that itself may or may not be proprietary, like NDISWrapper, is irrelevant. NDISWrapper, itself, is *not* closed source.

It's kinda like the Quake III engine. That's been released as open source, and there's an awful lot of games out there that make use of it. But it still relies on a binary blob that is itself rarely released as free. That doesn't make the engine itself any less free/open.

GPL Process separation and derivative works

[mlwmohawk]

At the core of this issue is the GPL definition of a derivative work.

Do not flame me for what I am about to write as it is my understanding of RMS' guidelines, if you have a problem with it, take it up with him.

To clarify what is and what is not a derivative work, the GPL and its supporting documents claim that a GPL work is not how self contained as it may seem i.e. shared libraries or loadable modules, but whether or not it inhabits the "process space" of the GPL work.

When a non-GPL module is loaded into the process space of a GPL application, it violates the GPL license of the application. This is why NDIS wrapper violates the GPL because its job is to load non-GPL code into the process space of the kernel, thus tainting it.

Do I agree? I'm not sure as I can see both sides of the argument. One side is that the module is self contained and isolated. The other side is that one of the purposes of the GPL is to protect the work of the people who contribute frm being unfairly used. It can be argued that the NIC card vendors who's drivers are enabled by NDISWrapper are unfairly enriched by the work of GPL developers in that their proprietary hardware is supported on a free platform without themselves being free.

It MIGHT be GPL.

[SharpFang]

A piece of software may not be GPL if it -relies- on non-GPL code. Not if it -optionally uses- it.

Say, I release a game which requires DirectX, links against the proprietary library, depends on it. It can't be GPL. But if I make the game run on both DirectX and SDL, it's enough to make it GPL. It's not crippled by lack of DirectX, it's just a user's choice, a preference to use it.

This way NDISWrapper just -could- be GPL if only someone writes GPL counterparts of the modules it uses. It would mean then, that it's a generic module wrapper which can load a variety of modules, GPL or not, and it's up to the user to feed it the restricted ones in place of the free ones. It may load any -generic- modules, but it should have no provisions towards any specific restricted modules without having an equivalent free part.

Good

[PingXao]

I've said it before and I'll keep on saying it: ndiswrapper is evil. The biggest obstacle right now to greater Linux usage, IMO, is the lack of wireless chipset drivers. ndiswrapper is a crutch, not a solution. Intel may have provided enough datasheets to enable writing wireless drivers for their chipsets, but Broadcomm is the 800 lb. gorilla in the room.

"Dude, just like load it with ndiswrapper and move on with working wifi!"

That attitude, I maintin, is actually harmful in the long run.

Does it even matter?

[nurb432]

With out it, many of us would be screwed for drivers.

Who really cares if its bla bla bla compliant?

Why we need NDISWrapper for Linux

[Orion Blastar]

First there is a lot of hardware that don't have Linux native drivers, mostly wireless network cards and Winmodems. NDISWrapper allows people to use Windows drivers under Linux for when there isn't a native Linux driver available for Linux.

That is the Achilles heel of Linux, lack of third party driver support. Heck that's the Achilles Heel of any Non-Windows operating system be it OS/2, BeOS, AmigaOS, even Mac OSX. One OS, ReactOS, is trying to implement Windows' WDM driver model in GPLed software so that ReactOS can use Windows drivers. I would like to see Linux have the ability to use Windows drivers via some GPLed software, so Linus can borrow that from ReactOS, or write it from scratch, or maybe the WINE team can make a Linux module that loads Windows drivers for Linux that uses the WINE libraries.

I have myself gone through several different wireless cards to get a Linux desktop working and eventually I gave up because I couldn't find a Linux native driver that wasn't flaky or lost the connection, and the only success I had was with NDISWrapper, but as soon as the Linux kernel is updated it breaks NDISWrapper forcing me to recompile the code and reinstall the Windows drivers.

In fact, I have a Linux desktop near my wireless router that uses a CAT5 cable to hook into it and then use VNC from a Windows desktop in another part of the house to log into the Linux system that way. It would be nice if I was able to get good wireless networking support from a Linux native driver without losing the connection or going flaky on me. But I suppose I'll always have a VMWare Virtual Machine to use as well if I wanted to run Linux from any part of my house and not just where the router is located.

explain how this violates gpl please

[hcmtnbiker]

Since ndiswrapper taints itself when it loads a proprietary NDIS module

Can someone explain to me how creating a computability layer for a proprietary model inherently violates GPL? Linus is trying to claim that loading the Windows Driver violates GPL. But I really fail to see how, ndiswrapper is a computability layer, and itself GPL'd, the windows driver is not loaded into the kernel like other modules it is sandboxed by ndiswrapper. It edges towards that gray area of the GPL, but itself doesn't violate it.

Thank god for GPL

[pclminion]

Thank God the kernel is GPL. I can go in there and remove all this stupid GPLONLY garbage.

Re:

[nuzak]

The difference is module and program. One is considered part of the kernel, the other isn't.

Linus was a bit brusque about it but I do see his point. Of course if all the kernel symbols needed to make wireless drivers work are GPLONLY, then well, Linux has a bigger problem, doesn't it.

Re:reductio time

[mabhatter654]

the difference is in how the kernel project uses the "GPL only" flag versus actual legality.

It's perfectly legal for NDIS to be GPL because all of the code they provide is open. That's the legal standard. That the USER loads non-GPL modules at runtime is a known loophole.

Lots of other projects use GPL for the same thing... Console emulators, word processing programs that read binary .docs, and so on. As NDIS doesn't DISTRIBUTE the program WITH the windows drivers (they don't own that code) it's perfectly fine for their "emulator" to be GPL same as an emulator for a Nintendo NES system.

Linus Uses the flag for people like Nvidia who it's NOT OK to use the GPL for their drivers because they own and distribute the binary code AND the wrapper in the same package. It's not legal for them to claim to be GPL. But in this case NDIS is only liable for the part they distribute and the user is responsible for how the program is used on the system. The license is fine it's just Linus is assuming that a "license flag" will cover all the programming options (so they can deny support) when that's not the case.

Re:

[Just Some Guy]

Trying to claim that Linux somehow itself is GPL'd even though it then loads programs that aren't is stupid and pointless. If it loads non-GPL programs, it shouldn't be able to use GPLONLY symbols.

Userspace programs don't link against the kernel. Additionally, from http://www.kernel.org/pub/linux/kernel/COPYING [kernel.org]:

NOTE! This copyright does *not* cover user programs that use kernel services by normal system calls - this is merely considered normal use of the kernel, and does *not* fall under the heading of "derived work". Also note that the GPL below is copyrighted by the Free Software Foundation, but the instance of code that it refers to (the linux kernel) is copyrighted by me and others wh

Re:

[jim.hansson]

this is funny, most of the time I get the impression that Linus is NOT a "GPL natzi", but at times like this you could mistake him for RMS.
but it is his tree so if he says it is not GPL compatible then it's not GPL compatible.
for the record, I have to agree with Linus on this one (but thats me and who am i).

Re:Linus making friends fast

[Achromatic1978]

but it is his tree so if he says it is not GPL compatible then it's not GPL compatible

HUH??

No, the wording of the license and its interpretation by legally qualified people determines whether or not something is GPL compatible, not the whims and say-so of a person, be it Linus, RMS, or whomsoever.

Re:Linus making friends fast

[MenTaLguY]

The demonstrated intent of the copyright holder does have some bearing on the interpretation of a license, however.

Try understanding the issue.

[gnutoo]

NDIS wrapper might itself be GPL but a kernel that uses it is not because the kernel is monolithic. Linus is actually giving everyone what they want.

What is this about GPLONLY symbols? [kernel.org].

EXPORT_SYMBOL_GPL was added ... To clarify the ambiguous legal ground on which non-GPL (particularly proprietary) modules lie. [and] ... To allow choice for developers who wish, for their own reasons, to contribute code which cannot be used by proprietary modules. Just as a developer has the right to distribute code under a proprietary licence, so too may a developer distribute code under an anti-proprietary licence (i.e. strict GPL).

Loading a non GPL kernel module makes the whole kernel non GPL and hard to debug because it's a monolithic program. Check out the Linuxant controversy [wikipedia.org] of 2001.

Linus won't keep you from making and loading non free modules but he's not going to be responsible when changes break your module. If others would cooperate, this would not be an issue. The NDIS wrapper people will have to reimplement functions written by GPL strict coders. That kind of sucks for them but they can do it. If Linus were to piss off the GPL strict coders, NDIS wrapper still would not work because those coders would quit contributing. A project as large as the kernel demands give and take. GPLONLY was a nice compromise.

NDIS wrapper has never been a great idea. It puts you at the mercy of Microsoft bugs and malice all for the benefit of a $30 network card. The kind of card that needs NDIS wrapper is usually worst of class and should be shunned. It's brain dead much like a winmodem and the "firmware" game is intentional. The card maker wants to be Windows only so don't buy it. Sooner or later hardware vendors will have to come around.

Re:Try understanding the issue.

[Ortega-Starfire]

NDIS wrapper has never been a great idea. It puts you at the mercy of Microsoft bugs and malice all for the benefit of a $30 network card.

Well, I for one think it is a great idea since the most popular card manufacturers could not be bothered for the longest time to make linux drivers (and a lot still don't.) You see, I could have bought an orinoco gold ABG card for $99 back in the day, or a $10 clearance walmart G card, and spend $98 on more RAM instead. Guess which one I chose (And for several years now, the card has been working just fine). Ndiswrapper got me online with gentoo (I know, I love pounding my head against a brick wall, its fun!) Without it, I'd still be using windows all the time.

Saying "Don't buy cards that don't support linux" is all well and good until you realize how much money you are dumping into hardware when a small free program can make it work just fine.

I think there is a term that covers this... Ah yes. "Not cost effective."

Re:

[MbM]

Well, I for one think it is a great idea since the most popular card manufacturers could not be bothered for the longest time to make linux drivers (and a lot still don't.)

Somewhat a flawed argument, since now that ndiswrapper exists there is no incentive to write a linux driver. I would have preferred ndiswrapper didn't exist, allowing linux developers to push for open drivers and specificiations.

Re:

[alan_dershowitz]

I couldn't use NetStumbler with my wifi card via NDISWrapper because apparently much of the wifi functionality is not controlled through the standard windows networking interface and so is not exportable via NDISWrapper. To do that I needed native drivers. If you want a fully functional card, you still want a native solution.

Re:Try understanding the issue.

[FishWithAHammer]

NDIS wrapper has never been a great idea. It puts you at the mercy of Microsoft bugs and malice all for the benefit of a $30 network card. The kind of card that needs NDIS wrapper is usually worst of class and should be shunned. It's brain dead much like a winmodem and the "firmware" game is intentional. The card maker wants to be Windows only so don't buy it. Sooner or later hardware vendors will have to come around.

That's a little hard on just about any laptop with an AMD processor. Intel boards have Centrino, which works under Linux without trouble. AMD-based laptops...not so much.

Re:

[andreyw]

NDIS is driver interface specification for network drivers [wikipedia.org]. NDIS follows the idea of port/miniport drivers - i.e. rigid and specific interfaces designed to prevent kernel implementation details from affecting drivers - for example, NT operating systems have set interfaces for SCSI HBA drivers, video drivers, network drivers. The overarching idea being writing drivers that are hardware dependent but are not too tied to the kernel.

NDIS is an interface. All network cards under windows need a network card drive

Re:

[gbjbaanb]

This is the guy who criticised people who pointed out Bitkeeper was, erm.. less than optimal in the 'play nice' category and who wanted to keep it 'for pragmatic, non-religious' reasons.

To quote the Register, [theregister.co.uk]

In a post on the Real World Technologies discussion board appropriately titled "Hypocrisy the worst of human traits", Torvalds takes advantage of Tridgell's vow of silence on the matter. For the first third of his response, Torvalds gently tries to persuade us that ethics doesn't belong in the software business, taking a strictly utilitarian view. Or, as he puts it,

"So I think open source tends to become technically better over time (but it does take time), but I don't think it's a moral imperative." he writes.

What a pity the people involved in Open Source give my boss another reason to distrust the community and all their projects.

Re:Linus making friends fast

[moranar]

I don't think Linus ever had any doubts about whether Bitkeeper was proprietary or not. He simply stated that it was the best tool for the job.

Here, he claims "well, go ahead and use it, but don't call it GPL code because it isn't. Oh, and if you use it, I'm not responsible".

Hope your boss can now breath more easily.

Re:

[A nonymous Coward]

What a pity the people involved in Open Source give my boss another reason to distrust the community and all their projects.

Yeh, too bad he got a start with the Microsoft people and all the honesty they bring to the table.

/sarcasm (included because you sound like someone who will miss it otherwise)

Re:Linus making friends fast

[nuzak]

Try the other way around. The NDISWrapper folks are trying to GPL something that Linus doesn't believe merits it. They're the ones trying to add the restrictions, and Linus isn't having it.

Re:

[m6ack]

People on this forum are not understanding what is being discussed. There are two issues -- licensing and Kernel tainting, and these actually are separate issues. Licensing: GPL only covers derived works. Making code that interfaces from a GPL'd software to a binary that is a windows derivative IS legal. Linus specifically made this point in his posts, and several times. Tainting: Tainting has two purposes... First, it tells the Kernel that a module is suspect. If someone reports a Kernel bug on a T

Re:Linus making friends fast

[somersault]

Isn't it rather obvious? What happens if someone tries to GPL code that needs non-free libraries - or worse, contains code that has been copied or reverse engineered from another program without the author's consent, or that uses an incompatible license?

Re:

[Crispy Critters]

"why do they have to pass a checklist of requirements to release their code freely?"

The problem is that it is not "their code". They claim that the "project implements Windows kernel API and NDIS (Network Driver Interface Specification) API within Linux kernel." That means it is a derivative work of the kernel. That means that they don't own all the code themselves, and that they have to follow the license of the other code they are using. And Linus's interpretation of the GPL and kernel modules is a

Re:

[dgatwood]

Agreed. This is precisely the reason why I regularly rail against the GPL as a license and think that all libraries should be under the LGPL. In effect, the kernel acts as a giant library. Any public interfaces to the kernel should be treated like a library and licensed appropriately, not under some idiotic license that doesn't allow linking non-GPLed code against it.

Indeed, this is doubly true for a plug-in API. There should not be restrictions for who can write code to a public specification, period

Re:Linus making friends fast

[nuzak]

> IMHO, the GPL is a BAD license precisely because it causes fights like this to break out with regularity.

I don't necessarily think it's a bad license, I just don't think it's a one-size-fits-all thing. When you bring together a group of intelligent, opinionated, and (in large part) socially awkward people, fights are going to break out. Now it's true that things like religion and licenses tend to act as amplifiers (thus why I don't buy the classic "people will kill each other anyway" argument about religion) but I think this is just a pretty isolated case of Linus having another tirade. Reportedly he's already backing off.

Re:Linus making friends fast

[Sancho]

I think that it's a horribly misunderstood license. While the concepts themselves are easy to understand, when you get into the nitty gritty details of interoperating with other software, things get sticky really quickly.

BSD is so much easier, but you run the risk of someone doing more with your code (and getting paid for it) than you did, without getting anything out of it. Personally, that doesn't bother me all that much.

Re:Linus making friends fast

[TemporalBeing]

More to the point, though, as long as something provides a public interface and uses only public interfaces, it is entirely the right of the author to decide how to license it, and if the author decides to license it under the GPL but provide a linking exception to allow closed source drivers to call it, that is the author's right. Linus himself said that he felt binary-only drivers should be allowed, so he took advantage of the right to provide a linking exception, and yet now he wants to deny it to others? What's wrong with this picture?

He's not denying access to it. The issue (from what I can tell) seems to be that he/others find the the NDISWrapper is not using the proper set of kernel functionality.

As you point out "it is entirely the right of the author to decide how to license it" and "Linus himself said that he felt binary-only drivers should be allowed, so he took advantage of the right to provide a linking exception". That "linking" exception requires that a module properly declare whether its license is GPL or not. If not, then its access to the kernel is restricted; if it is, it is given access to most all the symbols - the GPLONLY symbols. This is for (a) compatibility, but also (b) stability. They didn't want binary drivers breaking the kernel.

From the sounds of it, they don't agree with the NDISWrapper guys (or whoever is complaining) that NDISWrapper deserves the ability to access the GPLONLY symbols. Perhaps the way NDISWrapper functions is breaks compatibility with the GPL - by loading non-GPL code . I don't know the whole story, but I think I would have to side with the Linux guys on this one. It's their "linking" exception, and you have to play by the rules.

Note: This is not a GPL issue with respect to the Linux kernel; if it's a GPL issue at all, it is with NDISWrapper not validly being able to use the GPL, and if that is the case, then they should not be allowed to access the GPLONLY symbols. The primary issue is a matter of playing by the rules the developers set - and that goes for GPL and non-GPL code alike, regardless of projects, commercialization, etc. (And no, I'm not claiming, implying, or otherwise stating the the Linux Kernel guys determine that for everyone. Look at the project authors and who has the right, the ability, to make such a rule. It'll change for every project.)

Re:

[dgatwood]

He's not denying access to it. The issue (from what I can tell) seems to be that he/others find the the NDISWrapper is not using the proper set of kernel functionality.

Read what I read again. I didn't say he was denying access to the driver. I said he was using his right to allow binary linking but denying the developers of the NDISWrapper code that same right. Sorry, poor choice of wording on my part.

This code is not giving binary-only drivers access to GPLONLY symbols. It is strictly providing an

Re:Linus making friends fast

[kelnos]

More to the point, though, as long as something provides a public interface and uses only public interfaces, it is entirely the right of the author to decide how to license it, and if the author decides to license it under the GPL but provide a linking exception to allow closed source drivers to call it, that is the author's right.

Sure it is. But "GPL with linking exception" is not compatible with the GPL when going "downstream" with a derived work. If software package A is released under the GPL, and software package B is a derived work of software package B, it *must* be released under the GPL. It cannot be released under the "GPL with linking exception."

Linus himself said that he felt binary-only drivers should be allowed, so he took advantage of the right to provide a linking exception, and yet now he wants to deny it to others?

No he hasn't, and no he didn't. Go ahead and read the COPYING file in the root of the kernel source tree. There's a note at the top that clarifies that that "user programs that use kernel services by normal system calls" aren't considered a derived work of the kernel and therefore aren't required to be covered by the GPL. It says nothing about modules.

What Linus himself *has* said in the past was that he considers binary modules ok *if* those modules weren't developed specifically for Linux. Take nvidia as an example: they have a binary driver core (possibly developed for Windows, possibly developed just as a generic driver core) which has an open-source shim to adapt it to the Linux kernel's specific interfaces. NDISWrapper could be thought of similarly, as an open-source shim to adapt Windows drivers to Linux's specific interfaces. However, this doesn't mean that NDISWrapper itself can be licensed under the GPL (of course, it can be licensed under "GPL with linking exception"), which is not compatible with Linux's GPLONLY symbols.

Heck, it wouldn't even be wrong in my book if it directly exported GPLONLY symbols as-is.

Sorry, but your book isn't relevant here. (I assume by "it" you mean NDISWrapper.) You don't own the copyright on the kernel, so you don't get to decide. While this stuff may not be tested in court, seems like the copyright holders are in the right here.

The purpose of the GPL was supposed to be that non-open source can't directly call into GPLed code to avoid compatibility problems if the open source code changed.

No, the purpose of the GPL is to allow anyone to freely modify and redistribute source code, but to require that the source code remain open. The GPL is about idealism (with a bit of pragmatism mixed in); it has nothing to do with "compatibility problems."

It's not a workaround to dodge the GPL.

Oh, I agree, it's not. NDISWrapper is a great (temporary!) tool to fill a void until manufacturers get their act together or people have the time and motivation to reverse-engineer the relevant chipsets. Can it be licensed under the GPL? No, it can't. It does things anathema to the GPL's purpose (linking to code with an incompatible license). Can it be licensed under the "GPL with linking exception"? Sure. Is "GPL with linking exception" compatible with the Linux kernel's license for a derived work? No, it's not.

You're at the mercy of the copyright holders and the courts as to whether or not you're allowed to use NDISWrapper with Linux (and you are, it just can't use GPLONLY symbols!). Deal with it, or find some supported hardware or a different OS.

Remember, every time the GPL is used to impede progress, proprietary software wins.

You're implying that there's some sort of competition going on here. Your personal agenda for open source might be to rule the world, but that's not everyone's. And some people who do share your agenda would like to "win" without cutting corners and compromising on their ideals. Is that naive? Maybe. But just because you don't understand other people's motivations, it doesn't make them wrong.

Re:Linus making friends fast

[dgatwood]

Sure it is. But "GPL with linking exception" is not compatible with the GPL when going "downstream" with a derived work. If software package A is released under the GPL, and software package B is a derived work of software package B, it *must* be released under the GPL. It cannot be released under the "GPL with linking exception."

NDISWrapper is not a derived work of the Linux kernel. That is a gross misuse of the term "derived work". Using headers and linking against something does not make it a derived work. That was, IMHO, decided way back in the early 80s with Galoob v Nintendo, though no GPL linking case has gone far enough in court to test this, AFAIK.

You are correct that I can't take someone else's code and add a linking exception, but that's not what is being done here by any stretch of the imagination, and there are numerous cases where open source wrappers have been written as a border between proprietary and GPLed code. Again, to my knowledge, no cases about this have ever made it to court, in part because arguments that such linking is a GPL violation are relatively precarious, and in part because most companies that have found themselves getting threatened with a lawsuit have been small enough that they choose to settle out of court rather than risk a lengthy and expensive court battle.

More to the point, you can argue that the GPLONLY limitations were intended to disallow linking by code that is licensed as GPL with a linking exception, but then you would also have to disallow any code within the Linux kernel itself that calls those functions unless those pieces of code are also marked with the GPLONLY restriction. That makes the GPLONLY functions substantially less useful to the point of being nearly worthless.

What Linus himself *has* said in the past was that he considers binary modules ok *if* those modules weren't developed specifically for Linux.

NDISWrapper is a module that loads binaries specifically developed for Windows, so there you go.

No, the purpose of the GPL is to allow anyone to freely modify and redistribute source code, but to require that the source code remain open. The GPL is about idealism (with a bit of pragmatism mixed in); it has nothing to do with "compatibility problems."

Funny, I saw Stallman give a speech, and he basically said that he started hating proprietary software specifically when a printer failed to work with a new computer setup. Had the driver been open, he could have fixed it. Had the OS been open, he could have fixed it to be compatible. Neither was, so he couldn't. While the goals of the GPL may have drifted from that original purpose these days, compatibility was a very important part of the reason the Free Software movement was created in the first place, and I think it is important that the movement not lose touch with its roots.

Re:

[Haeleth]

Indeed, this is doubly true for a plug-in API. There should not be restrictions for who can write code to a public specification, period. There are far too many people who say that the GPL should have this right and still decry Microsoft for their shady, intentionally non-GPL-compatible licenses. That is the height of hypocrisy.

It's not hypocritical at all, because the two things are not remotely comparable.

Microsoft is saying "here are some specifications for a document format, and here is a vague 'promise

"Linking" is not a term of copyright

[JSBiff]

I think almost all of these types of problems come down to the fact that, for copyright law with respect to computer software, the most *sane* approach is that linking does not create a derivative work, and therefor license terms cannot be applied to other works which link to the licensed work. NOTE: I am not a lawyer, this is not a statement of fact regarding current law, this is a statement of personal opinion. In otherwords, my opinion is that, if my view of copyright were adopted, there would be no GPL, only the LGPL. That is to say, since the only difference between the GPL and LGPL is the linking clause, and since I do not believe copyright should extend to other linked works, the GPL 'decays' to become the same thing as the LGPL.

Let me state it this way: It is my understanding that copyright law, currently, has no notion of 'linking'. Copyright covers copying material, or creating derivative works (such as translations, modified versions, etc). I don't know the full definition of derived work (I've tried to research it before, and it appears to get a bit complicated), but it is my understanding that the basic principle of a derived work is that it contains all or part of the work from which it is derived. For example, a translation is a derived work because, while all the words may be literally different, being in a different language, the works still essentially contains all the ideas and expressions from the original work.

It's also my understanding that copyright does not govern what you can and cannot do with with copyrighted work, except to the extent that you cannot copy, distribute, or perform for other people, the copyrighted work or distribute derivatives without permission (I think you can create derivatives without permission, even, you just can't distribute/copy/perform that derivative). So, copyright doesn't give me the power to say you can't 'link' your work with mine, unless such 'linking' creates a derivative and you then subsequently distribute/copy/perform that derivative work (so even if a derivative is created on the on the end-user computer, which I believe is not the case, I don't think copyright law would prohibit that).

The thing about software which dynamically links other software is, the two software works are fundamentally almost completely separate works, if I understand dynamic linking correctly. They are distributed separately (or at least, *can be* distributed separately), they are loaded into memory separately, and the works are never really combined, even in computer memory, I believe. Is that not correct? My understanding of 'dynamic linking' is that the computer is running code in one segment of memory, and encounters an instructions which just causes it to jump to another part of memory and start executing what's there, and when finished executing the linked function, to return to the original memory location + 1. If that is, in fact, the case, then it's rather like a note in a book which says, "Go read such-and-such magazine article, then return to this page and continue reading". Even if my book makes *no sense* unless you read the article I put the note in for, my book is still not a derivative, because it contains no copy of the magazine article. (I mention that last part because I've read where Linus, and some other people, make the claim that the test for derivative work should be whether software can run without the linked software - I personally think that is an irrelevant fact, because where there is no copying, there can be no violation of copyright).

Anyhow, I just ultimately believe that all this stuff about restricting what symbols can and can't be used by non-GPL software is just a mess, and not reasonable. I think the idea that because one work links another work, that the author of the linked work gets some kind of control over the second work is not reasonable. Separate works should have separate copyrights which do not touch each other AT ALL.

Now, it's my understanding that all this linking stuff vis-a-vis the GPL has never

Re:

[cheater512]

NDISWrapper deals with Window's binary blob drivers.
That, under anyone's definition, means nothing GPLed can touch them.

NDISWrapper tried calling its self GPL while exposing all of Linux's GPLed interfaces to the binary blobs.
A very straight forward violation.

Personally I never liked NDISWrapper.
I use Linux to get away from Windows. I dont want their drivers running on my system.

Many people use it even when there are superior native drivers.
Its been portrayed as a quick fix so if your hardware doesnt work o

Re:

[nuzak]

> Its been portrayed as a quick fix so if your hardware doesnt work out of the box, just use NDISWrapper.

If it doesn't work out of the box, I don't much care that it's superior. I'm tired of "learning how the system works" for the 1000th time. Not all toil is virtuous.

who owns the kernel?

[Crispy Critters]

"This is stupid, people are trying to release the code of the project to the community and the restrictive terms of the GPL is preventing them."

This would be different if it were purely their code, but it isn't. This isn't stand-alone code. What they created is a derivative work of the Linux kernel. They used code which they didn't write and they don't own. Your argument is that the people who actually wrote the original kernel code have no right to say how it and its derivative works are used. Legally, you are completely and totally wrong. Essentially, you are advocating an end to copyrights on computer code. That's fine, but it has nothing to do with the GPL.

Re:

[drinkypoo]

I don't know how you got marked all the way up to 5, but what you say has never been tested in court - which is the only thing that matters. It is NOT repeat NOT clear whether linking constitutes creation of a derivative work. Providing the source and headers may well prove to constitute a published specification, and the right to interoperate is generally protected by US law (there's even an exception to the DMCA restrictions on reverse engineering specifically for the purpose of interoperability.) So real

Re:

[cfulmer]

I'm not even sure that linking statically creates a derivative work, as much as it creates a compilation. It's more similar to including a poem in a book of poems than it is to changing the poem itself. A derivative work involves changing or recasting the original -- static linking doesn't do this. The reason that you can't (w/o permission) distribute a program with an embedded library is more basic -- you're violating the distribution right of the library (and, presumably, the duplication right also.)

It

Re:

[corychristison]

OpenBSD rejected NDISWrapper first, due to their "anti-binary blob" policy.

That and Linus changed his mind shortly after this was posted to Kernel Trap. Read a few comments up.

Re:.... right ....

[iabervon]

Good thing desktop users are unlikely to install a new non-distro kernel between February 28th, when Linus posted that, and March 4th, when he looked more carefully at what ndiswrapper is doing and determined that it's not re-exporting functions to non-GPL code, but rather using them to implement an API that's not a derived work of the kernel. Linus saying something dumb on a Thursday afternoon which he corrects on a Tuesday shouldn't be news on Wednesday, especially as it's a discussion about a kernel that hasn't been released yet, won't be for a couple of weeks, and probably won't be provided by distributions for a couple of months.