Modules, Binary Only And Gpl

[iamasmith]

Hi,

I think this is worthy of discussion and would provide an excellent area to consolidate the issues over binary drivers i.e. the SD driver in the Zaurus kernel.

Now firstly as I understand it the principals behind GPL release of the kernel driver source (or not) as defined by Linus is that the driver must have essentially have originated in another form and be not originally derived or dependent upon specific Linux kernel knowledge because that would imply that it would be GPL as a derivative work of the kernel.

The GPL (not LGPL) basically says that code that becomes part of a product - that's the grey spot, can a kernel module be defined as being NOT part of the kernel - that is GPL inherits the licensing of the GPL product so I would expect that regardless of opinions on position of kernel modules they should all be GPL according to the license terms. - I think Stallman was quite explicit in terms of not being able to bend these rules.

Now, who has an opinion/good collection of postings on the subject...

(play nicely now !)

- Andy

[amrein]

For kernel modules, the source code must be released. But when the module loads dynamically something else... the problem is no more the same: the module uses and is used by the kernel but the part dynamically loaded is only used by the module. In short: your module can link to something else as long as the external componant doesn't rely on the kernel or the kernel knowledge.

NVidia closed source driver works like this for example: a part (the module) is compiled to be included in the current kernel, another part (the real driver) is out of the kernel.

If the SD driver is completely integrated into the Zaurus kernel (mean without external load) than the source code can be claim. If not, you can't do anything.

[Stubear]

My understanding is that as lnog as the kernel module is not shipped with the kernel then it doesn't need to be GPLed.

Examples that I'm aware of are SD driver, ATI and Nvidia binary only graphics card modules.

Stu

[kahm]

There was a Slashdot article not too long ago (Don't have a link, sorry) that pointed to an online discussion with Torvalds on this topic.

It appears that loading a non-gpl compliant module was in violation of the GPL, full stop. The NVIDIA and ATI solutions were brought up, but I think they were found to be technically in violation as well.

I don't think they've got it all hammered out yet, and I don't remember if they actually want to completely prohibit such solutions.

My response to the whole thread was an intense disenchantment with the GPL, or at least this particular interpretation of it - it threatens to make Linux into a philosophical exercise instead of a useful OS.

[iamasmith]

A couple of interesting things that I found were.

i. Being derived from the Kenel and thus GPL could be defined by...

   a. Not compiling independently of the Kernel source being available.
   b. Actually using any of the Kernel headers.

ii. Shipping and using tainting modules is slightly different. It's all down to distribution. You can actually do anything that you want with Open Source software, you can modify it in any way that you like and keep it ALL to yourself but as soon as you distribute it then that's where the difficulty kicks in. Now a non-GPL module is supposed to taint the kernel (tainting the kernel should occur for a variety of things and this IS one of them). Now if you get a module that is shipped entirely independently of the kernel and install it then it is you that has introduced the module, you have installed it, it isn't the manufacturer that has shipped the module and kernel together and the tainting only takes place when you load the module. Hence your kernel becomes tainted/non GPL compliant but that doesn't matter because you aren't going to ship it !. This is why SuSE and other Linux distro vendors cannot include things like the nVidia driver. But it does raise a question over modules shipped on built units such as the Z - or even preinstalled systems with a kernel and non-GPL video drivers !

Note, sharp and a variety of other vendors could solve this ambiguity and release open source drivers for SD if they used a bridge internally and addressed the SD card via the bridge. The CF interface sounds particularly good for this, I mean you CAN get CF to SD adaptors so why not build the adaptor chipset into the unit and address all SD/SDIO functions via that ?

[kopsis]

There question of whether a kernel module must be released under the GPL all boils down the the legal issue of "derived work". Derived work is a very gray area in US copyright law and there are very few absolute rules for determining if something is a derived work. Yes, requiring the kernel source to build the module would make it difficult to argue that the module is not a derived work ... but some lawyers have a knack for winning "difficult arguments". Simply "including" kernel headers is much more gray. If using the a well documented system call interface in the kernel does not make applications GPL, it's a little bit of a stretch to claim that using a well documented module interface in the kernel does make the module GPL. I'm not saying there are no valid arguments to support that position ... just that there are probably an equal number against it.

As for the idea of a binary component that interfaces to a GPL'd module stub ... Linus has gone on record saying that he feels that is every bit as much of a violation of the GPL as is making the whole module closed-source binary. And whitepapers published by the FSF to clarify their stand on "derived works" back up Linus' position. Linus hasn't made a big issue of this with the Nvidia driver simply because it's pretty obvious that it's not a derived work (Nvidia ported an existing Windows driver to Linux).

A bigger issue that people need to consider is whether allowing closed-source binary modules for Linux is good or bad (good != legal). The simple fact of the matter is that there are (and always will) be proprietary hardware standards. SD, MemoryStick, RapidIO, etc. The organizations that have created those standards make them available only to paying members. And a condition of membership is that you will not disclose the information contained in the specifications. That means code that implements the spec can never be released under an open source license. Period. Even if someone won a successful GPL law suit against Sharp for the closed-source SD driver, the only available remedy would be an injunction against distributing the driver (and possibly monetary damages). The courts couldn't force opening the driver source because that would violate another valid contract.

No one is going to change the protective mentality of the industry consortiums behind the closed hardware standards. They have far too much R&D money invested in the development of the hardware to just "give away" their designs. So if Linux developers and users start taking a hard line GPL stand against binary modules, the only thing it's going to accomplish is complete loss of support for those devices on Linux. Perhaps not that big a deal on desktops and servers, but this would essentially make Linux taboo in a lot of embedded applications (like the Zaurus).

And if you think the embedded systems developers will fight the industry consortiums to "open" the hardware standards, dream on. They'll just switch to a non-GPL'd OS like WinCE, VxWorks, Symbian, or even BSD. Most end users will never know the difference. But those of us who do like to tinker with our gadgets will lose a lot of capabilities since vendors will no longer be obligated to release source for any part of the kernel. Want to write a driver for a new Bluetooth card? Sorry. Want to tweak the preemptive behavior of the kernel? No dice. Something to think about before beating Sharp up about their closed-source SD driver violating the GPL.

[kopsis]

Note, sharp and a variety of other vendors could solve this ambiguity and release open source drivers for SD if they used a bridge internally and addressed the SD card via the bridge.

I want to address this suggestion seperately from may last rant

This is a completely valid suggestion from a technical standpoint. The reasons not to do it are as follows:

• Adds non-recurring cost. The Xscale (and StrongArm) already have hardware interfaces for SD cards. Using a bridge chip instead of something you already have means you need to design in that chip.
• Adds recurring cost. You have to buy bridge chips for every unit that ships and that increases unit cost. That means higher prices or less profit. Yeah, it's not a big cost, but consumer electronics is a very price sensitive business.
• Adds real estate. Circuit boards on handheld devices are already packed. Adding yet another chip means bigger or more complex boards which adds cost.
• Adds power consumption. Every chip in the device uses power. If you can access the SD directly from the CPU, you're going to use less power than accessing via the CPU plus a bridge chip.

One of the main factors for using Linux in an embedded device is to take cost out. In the embedded world, software is designed to fit the hardware, not vice versa. When an OS (and not even technical aspects of the OS, but licensing issues) starts driving hardware design, developers will just switch to a different OS.

[iamasmith]

Dave,

All very sound stuff there as usual, you really add a lot to these discussions.

I'm not per-se beating up Sharp in this just suggesting some what ifs. I would like to see purchasing decisions within large corporates that would allow them to remain platform agnostic and have a variety of uses from their hardware with long term community support rather than vendor support.

The only way of doing this obviously seems to be to try to sell people who are in charge of 30K seat HW refreshes on the value of choosing hardware that is all open spec and well documented.... consider the original IBM PC and the nature of the technical reference guides... mind you IBM at the time wanted to hedge their bets in case DOS didn't take off right ??

I think that a group had a go at forming an Open Hardware Standards Consortium at one time. I don't know if it was their express intention of trying to tip the purchasing market to pressurise manufacturers but I can see a lot of positive returns if this were to ever happen.

- Andy

[iamasmith]

....standards. SD, MemoryStick, RapidIO, etc. The organizations that have created those standards make them available only to paying members. And a condition of membership is that you will not disclose the information contained in the specifications. That means code that implements the spec can never be released under an open source license. Period.

I'm not actually sure the SD NDA is quite that restrictive, certainly HP have released as part of the familiar kernel for the H5450 a driver that handles MMC cards through the SD interface of that unit.

I questioned Jamey Jicks on this in June because I wanted to get a response on why there wouldn't be a driver for the 3970 (which I had at the time)... here's an extract.

Andrew Smith wrote....
>Everything seems to be a little vague as to what's happening if anything
>with the 39xx MMC driver.
>
>The 54xx port seems to be working fine (did I see that SD cards were
>working too ?) so there seem to be drivers for PXA250 although the GPIO
>lists in the current Kernel Source for the 39xx seem to be lacking some
>of the entries present in the 54xx source (SD/MMC Power Enable etc. -
>bit of a show stopper).
>
>  
>
The spec for the chip in the 5xxxx and the h22xx is available publicly.

>There are loads of references to the SD card spec being under NDA and
>that this project will never release an open source driver for SD. Is
>this related in any way to the difficulty in releasing specs for the
>39xx that would enable a functional MMC driver at least ? + Why doesn't
>this effect the 54xx, is this something related to Toshiba's chipsets in
>the 39xx ? Is it that chipset particularly thats under NDA ?
>
>  
>
The spec for the chip in the 39xx is non-HP proprietary, so HP cannot
release the spec.  The vendor has declined to make this spec public.

... So there does seem to be a vendor element in it, it's not just the SD guys hamstringing everyone....

Of course I haven't seen the SD NDA.... NO, I don't want to see it, take it away ....

BTW: It WAS this issue that tipped me over the edge to buying a Zaurus (binary driver or not) and I bought an SL-C860... not a sigsegv since either !

[kopsis]

The spec for the chip in the 5xxxx and the h22xx is available publicly.

{snip}

The spec for the chip in the 39xx is non-HP proprietary, so HP cannot
release the spec.  The vendor has declined to make this spec public.

Ok, wild speculation here, but the above leads me to believe that HP has put the SD interface into some kind of a bridge chip (see, I told you your idea was technically feasable  ). If that's the case then their "SD driver" isn't an SD driver at all but an "SD bridge driver". Its entirely possible that revealing the interface to the bridge chip won't disclose any of the protected details of the actual SD interface.

More wild speculation, but I'm also under the impression that the Zaurus connects the SD directly to the CPU's SD interface (benchmark results and the fact that Sharp was able to fix some early interface timing problems with a new module are what lead me to that conclusion). If that's the case then the driver code on the Z does contain a big helping of "secret sauce" and would be protected under SD NDA. And having done some consulting work for companies that were SD association members, I can assure you that the SD NDA is very restrictive (remember that SD stands for SecureDigital).

Sharp has, as far as I know, released code for everything else in the kernel, so I'm inclined to believe that there's a strong NDA blocking the SD stuff. I agree that it would be nice if the consortiums would "open" their specs, but it just isn't going to happen. Your IBM PC example illustrates why. With the PC, IBM "opened their kimono" to the world. The BIOS info they published let Compaq build a better PC than the PC and the rest is history. The industry has been totally paranoid ever since. If the kernel developers and guardians of the GPL don't accept that (and I think they do ... grudgingly), then they'll just force the embedded world down the BSD path. Not that BSD is a bad thing (it's worked out great for Sun and Apple) but as an embedded systems engineer, I like having a choice

[kahm]

You know what? I was really hoping someone was going to reply and tell me that I remembered wrong and that I was full of it.

Unfortunately, Kopsis has to come along and tell me that no, I was remembering right all along.

I'm glad that Linus and company aren't taking a hard line on the issue, as I really like linux. Without 3rd party driver support (and the fact that it is impossible for all drivers to be open-sourced seems to be lost on many people) Linux quickly loses a lot of functionality and appeal in many markets.

Do I like using closed drivers? Not particularily, but sometimes I don't really have a choice.