Blacklist binary-only modules lying about their license

The attached patch blacklists all modules having "Linuxant" or "Conexant" in their author string. This may seem a bit broad, but AFAIK both companies never have released anything under the GPL and have a strong history of binary-only modules.

Quoted 6 lines · Carl-Daniel Hailfinger

The attached patch blacklists all modules having "Linuxant" or "Conexant" in their author string. This may seem a bit broad, but AFAIK both companies never have released anything under the GPL and have a strong history of binary-only modules.

Blacklisting modules?!

Oh come on!
I agree the '\0' trick is not really nice, but blacklisting modules is not really better. It's not a functionality that adds anything to the kernel.
If ppl want/have to use that module let them!

Quoted 10 lines · Gilles May

Quoted 6 lines · Carl-Daniel Hailfinger

The attached patch blacklists all modules having "Linuxant" or "Conexant" in their author string. This may seem a bit broad, but AFAIK both companies never have released anything under the GPL and have a strong history of binary-only modules.

Quoted 7 lines

Blacklisting modules?!

Oh come on!
I agree the '\0' trick is not really nice, but blacklisting modules is not really better. It's not a functionality that adds anything to the kernel.
If ppl want/have to use that module let them!

Then they should list themselves as proprietory, there will be no problem loading them in that case. No need to tell fibs.

LinuxAnt offers binary only modules without any sources. To circumvent our MODULE_LICENSE checks LinuxAnt has inserted a "\0" into their declaration:

MODULE_LICENSE("GPL\0for files in the \"GPL\" directory; for others, only LICENSE file applies");

Anyway, I suspect that rather than blacklist bad people, I'd much prefer to have the module tags be done as counted strings instead. It should be easy enough to do by just having the macro prepend a "sizeof(xxxx)" thing or something.

Hmm. At least with -sdt=c99 it should be trivial, with something like

	#define __MODULE_INFO(tag, name, info)		\
	static struct { int len; const char value[] }	\
	__module_cat(name,__LINE__) __attribute_used__	\
	__attribute__((section(".modinfo"),unused)) =	\
		{ sizeof(__stringify(tag) "=" info),	\
		__stringify(tag) "=" info }

doing the job.

diff -urpN --exclude TAGS -X /home/rusty/devel/kernel/kernel-patches/current-dontdiff --minimal .31262-linux-2.6.6-rc2-bk4/include/linux/module.h .31262-linux-2.6.6-rc2-bk4.updated/include/linux/module.h

include/linux/module.h +1 -0

@@ -61,7 +64,14 @@ void sort_main_extable(void);
 #ifdef MODULE
 #define ___module_cat(a,b) __mod_ ## a ## b
 #define __module_cat(a,b) ___module_cat(a,b)
+/* Some sick fucks embeded NULs in MODULE_LICENSE to circumvent checks. */

On Tue, 2004-04-27 16:04:06 +1000, Rusty Russell <[email protected]> wrote in message <1083045844.2150.105.camel@bach>:

Quoted 9 lines · Linus Torvalds

diff -urpN --exclude TAGS -X /home/rusty/devel/kernel/kernel-patches/current-dontdiff --minimal .31262-linux-2.6.6-rc2-bk4/include/linux/module.h .31262-linux-2.6.6-rc2-bk4.updated/include/linux/module.h

include/linux/module.h +1 -0

@@ -61,7 +64,14 @@ void sort_main_extable(void);
 #ifdef MODULE
 #define ___module_cat(a,b) __mod_ ## a ## b
 #define __module_cat(a,b) ___module_cat(a,b)
+/* Some sick fucks embeded NULs in MODULE_LICENSE to circumvent checks. */

include/linux/module.h void sort_main_extable(void); · line 77

Quoted 10 lines

include/linux/module.h +6 -0

+#define __MODULE_INFO_CHECK(info)					  \
+	static void __init __attribute_used__				  \
+	__module_cat(__mc_,__LINE__)(void) {				  \
+		BUILD_BUG_ON(__builtin_strlen(info) + 1 != sizeof(info)); \
+	}
 #define __MODULE_INFO(tag, name, info)					  \
+__MODULE_INFO_CHECK(info);						  \
 static const char __module_cat(name,__LINE__)[]				  \
  __attribute_used__							  \
  __attribute__((section(".modinfo"),unused)) = __stringify(tag) "=" info

Erm, that's a pure compile-time check, which the companies can remove. So they can still put their fucked up license string into the module, customer's kernel won't detect it.

So I'm full for embedding the supplied string's size into the module, or some compile-time generated checksum. We need something that can be checked at module load time, not at compile time, or do I misread the code?

This way, the module format doesn't change, but we can do additional verification in the loader.

Quoted 2 lines · Carl-Daniel Hailfinger

This way, the module format doesn't change, but we can do additional verification in the loader.

The way I see it, they know a C string ends with a '\0'. This is like saying that a English sentence ends with a dot. If they wrote "GPL\0" they are effectively saying that the license *is* GPL period.

So, where the source code? :)

--+sHJum3is6Tsg7/J
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Tue, 2004-04-27 13:59:48 +0100, Paulo Marques <[email protected]> wrote in message <[email protected]>:

Quoted 6 lines

Quoted 2 lines · Carl-Daniel Hailfinger

This way, the module format doesn't change, but we can do additional verification in the loader.

=20
The way I see it, they know a C string ends with a '\0'. This is like=20 saying that a English sentence ends with a dot. If they wrote "GPL\0" the=

y=20

Quoted 3 lines

are effectively saying that the license *is* GPL period. =20
So, where the source code? :)

That's another (quite amusing:) point of view. Anybody willing to ask a lawyer?

The way I see it, they know a C string ends with a '\0'. This is like saying that a English sentence ends with a dot. If they wrote "GPL\0" they are effectively saying that the license *is* GPL period.

So, where the source code? :)

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

"PM" == Paulo Marques <[email protected]> writes:

under GPL, but even if it did, I do not think they have any obligation to give us the source. GPL says "You may do such and such provided if you do so and so" but that is all about the Licensee. It does not talk anything about what the copyright holder may, may not, nor must do :).

The way I see it, they know a C string ends with a '\0'. This is like saying that a English sentence ends with a dot. If they wrote "GPL\0" they are effectively saying that the license *is* GPL period.

Hi!

Quoted 1 line

The way I see it, they know a C string ends with a '\0'. This is like saying that a English sentence ends with a dot. If they wrote "GPL\0" they are effectively saying that the license *is* GPL period.

If you use modinfo, license probably will be displayed as GPL. I'd guess that sending bunch of lawyers their way is right solution.

The way I see it, they know a C string ends with a '\0'. This is like saying that a English sentence ends with a dot. If they wrote "GPL\0" they are effectively saying that the license *is* GPL period.

So, where the source code? :)

Quoted 5 lines

LinuxAnt offers binary only modules without any sources. To circumvent our MODULE_LICENSE checks LinuxAnt has inserted a "\0" into their declaration:

MODULE_LICENSE("GPL\0for files in the \"GPL\" directory; for others, only LICENSE file applies");

Hey, that is interesting in itself, since playing the above kinds of games makes it pretty clear to everybody that any infringement was done wilfully. They should be talking to their lawyers about things like that.

Hi,

LinuxAnt offers binary only modules without any sources. To circumvent our MODULE_LICENSE checks LinuxAnt has inserted a "\0" into their declaration:

MODULE_LICENSE("GPL\0for files in the \"GPL\" directory; for others, only LICENSE file applies");

The attached patch blacklists all modules having "Linuxant" or "Conexant" in their author string. This may seem a bit broad, but AFAIK both companies never have released anything under the GPL and have a strong history of binary-only modules.

What would be smarter would be to try to understand why they do this. At the moment, it seems to me that their only problem is to taint the kernel. Why ? I don't this that any old modutils/module-utils found in any distros don't load properly such modules. So perhaps they only want not to taint the kernel because it appears dirty to their customers who will not receive any more support from LKML. So perhaps what we really need is to add a new MODULE_SUPPORT field stating where to get support from in case of bugs, oopses or panics on a tainted kernel. Thus, the module author would be able to insert something such as "[email protected]" which will be displayed on each oops/panic/etc... Even if this is a long list because the customer uses connexant, nvidia, checkpoint and I don't know what, at least he will get 3 email addresses for his support. And it might reassure these authors to know that the customer will ask them before asking us with our automatic replies "unload your binary modules...".

Anyway it now seems like strings will have to be matched on their lenghts...

Hi,

LinuxAnt offers binary only modules without any sources. To circumvent our MODULE_LICENSE checks LinuxAnt has inserted a "\0" into their declaration:

MODULE_LICENSE("GPL\0for files in the \"GPL\" directory; for others, only LICENSE file applies");

Since string comparisons stop at the first "\0" character, the kernel is tricked into thinking the modules are GPL. Btw, the "GPL" directory they are speaking about is empty.

The attached patch blacklists all modules having "Linuxant" or "Conexant" in their author string. This may seem a bit broad, but AFAIK both companies never have released anything under the GPL and have a strong history of binary-only modules.

Regards,
Carl-Daniel

As an end user, if I buy a full fledged modem, I get some amount of proprietary, non GPL, code which executes within the board or the PCMCIA card of the modem. The GPL driver may even support the functionality of downloading a new version of *proprietary* code into the flash Eprom of the device. The GPL linux driver interfaces with it, and all is kosher.
On the other hand, I have the misfortune of being stuck with a soft-modem, roughly the *same* proprietary code is provided as a binary file, and a linux driver (source provided) interfaces with it. In that case the kernel is flagged as "tainted".

But in both cases, if the driver is poorly written, because of developer's inadequacy, or because of the proprietary code being poorly documented and/or implemented, my kernel may go nuts, be it tainted or not.

Can you honestly tell apart the two cases, if you don't make a it a case of "religion war"?

Quoted 11 lines · Giuliano Colla

As an end user, if I buy a full fledged modem, I get some amount of proprietary, non GPL, code which executes within the board or the PCMCIA card of the modem. The GPL driver may even support the functionality of downloading a new version of *proprietary* code into the flash Eprom of the device. The GPL linux driver interfaces with it, and all is kosher.
On the other hand, I have the misfortune of being stuck with a soft-modem, roughly the *same* proprietary code is provided as a binary file, and a linux driver (source provided) interfaces with it. In that case the kernel is flagged as "tainted".

Quoted 6 lines

But in both cases, if the driver is poorly written, because of developer's inadequacy, or because of the proprietary code being poorly documented and/or implemented, my kernel may go nuts, be it tainted or not.

Can you honestly tell apart the two cases, if you don't make a it a case of "religion war"?

Yes. *Especially* outside of religious wars - while fuckup capabilities of Joe Random Driver Monkey are unlimited, there is a difference between the impact of fuckups in the code that runs on CPU and in the code that runs on peripherial. If nothing else, the latter is less likely to try anything cute and tricky with locking.

In other words, with code running on the host CPU lusers have much, much more ways to luse, luse again when trying to "fix" things and make it harder to figure out what had caused the bloody mess.

As an end user, if I buy a full fledged modem, I get some amount of proprietary, non GPL, code which executes within the board or the PCMCIA card of the modem. The GPL driver may even support the functionality of downloading a new version of *proprietary* code into the flash Eprom of the device. The GPL linux driver interfaces with it, and all is kosher. On the other hand, I have the misfortune of being stuck with a soft-modem, roughly the *same* proprietary code is provided as a binary file, and a linux driver (source provided) interfaces with it. In that case the kernel is flagged as "tainted".

But in both cases, if the driver is poorly written, because of developer's inadequacy, or because of the proprietary code being poorly documented and/or implemented, my kernel may go nuts, be it tainted or not.

Can you honestly tell apart the two cases, if you don't make a it a case of "religion war"?

Can you honestly tell apart the two cases, if you don't make a it a case of "religion war"?

Firmware downloaded into a piece of hardware can't corrupt the kernel in the host.

(Unless it's a bus master which writes to random memory, which might be possible, but there is hardware you can buy to watch PCI transactions.)

Quoted 2 lines · Giuliano Colla

Can you honestly tell apart the two cases, if you don't make a it a case of "religion war"?

On Thu, Apr 29, 2004 at 11:15:13AM -0400, Timothy Miller answered:

Quoted 5 lines

Firmware downloaded into a piece of hardware can't corrupt the kernel in the host.

(Unless it's a bus master which writes to random memory, which might be possible, but there is hardware you can buy to watch PCI transactions.)

and unless it's a card with binary-only, proprietary BIOS code called at runtime by the kernel, for example by the vesafb.c video driver, which despite this has a MODULE_LICENSE("GPL").

Could someone explain why such execution of evil proprietary binary-only code on the host CPU should not also "taint" the kernel? ;-)

Quoted 9 lines · Marc Boucher

Quoted 2 lines · Giuliano Colla

Can you honestly tell apart the two cases, if you don't make a it a case of "religion war"?

On Thu, Apr 29, 2004 at 11:15:13AM -0400, Timothy Miller answered:

Quoted 5 lines

Firmware downloaded into a piece of hardware can't corrupt the kernel in the host.

(Unless it's a bus master which writes to random memory, which might be possible, but there is hardware you can buy to watch PCI transactions.)

Quoted 5 lines

and unless it's a card with binary-only, proprietary BIOS code called at runtime by the kernel, for example by the vesafb.c video driver, which despite this has a MODULE_LICENSE("GPL").
Could someone explain why such execution of evil proprietary binary-only code on the host CPU should not also "taint" the kernel? ;-)

That's a good question, but the BIOS code you're talking about is not part of the kernel. Sure, it's possible that it might still corrupt the kernel, but it's not being loaded into it as a module. The developer of the BIOS code never intended for their code to be run by the Linux kernel.

Is it still dangerous? Yes. Is it a violation of the GPL? No.

Also, developers of modules which thunk to BIOS code are aware of the potential problems and are typically willing to take responsibility for investigating bugs in their own code. (Bugs in the BIOS means you're screwed and need to get new hardware.) Developers of proprietary drivers are notoriously unhelpful when it comes to fixing bugs in their code.

The proprietary modem code for the HSF driver is not part of the kernel, nor did its original developers ever intend for it to be run by the Linux kernel.

Whether proprietary binary-only code is dynamically loaded through the module subsystem or physically by someone installing a card is a technicality with little relevance.

You have pointed out an interesting point in another email. I have to agree that, technically, thunking to BIOS code also taints the kernel, because it, too, is a black box which could corrupt the kernel. What do others have to say about that?

e.g. The symbios(*1)-SCSI-driver only shows devices enabled in its BIOS. This information is stored in a little NVRAM-chip(*2) and the driver uses this data, including bus-speed settings and the like. At least i (had/have*3) trouble with this "feature"!

Quoted 4 lines · Matthias Schniedermeyer

e.g. The symbios(*1)-SCSI-driver only shows devices enabled in its BIOS. This information is stored in a little NVRAM-chip(*2) and the driver uses this data, including bus-speed settings and the like. At least i (had/have*3) trouble with this "feature"!

So why does my '875 card works fine in my PPC box? No BIOS ever wrote to its NVRAM.

Quoted 2 lines

Can you honestly tell apart the two cases, if you don't make a it a case of "religion war"?

On Thu, Apr 29, 2004 at 11:15:13AM -0400, Timothy Miller answered:

Quoted 6 lines

Firmware downloaded into a piece of hardware can't corrupt the kernel in the host.

(Unless it's a bus master which writes to random memory, which might be possible, but there is hardware you can buy to watch PCI transactions.)

and unless it's a card with binary-only, proprietary BIOS code called at runtime by the kernel, for example by the vesafb.c video driver, which despite this has a MODULE_LICENSE("GPL").

Could someone explain why such execution of evil proprietary binary-only code on the host CPU should not also "taint" the kernel? ;-)

Let's try not to be ridiculous, please.

As an end user, if I buy a full fledged modem, I get some amount of proprietary, non GPL, code which executes within the board or the PCMCIA card of the modem. The GPL driver may even support the functionality of downloading a new version of *proprietary* code into the flash Eprom of the device. The GPL linux driver interfaces with it, and all is kosher.

On the other hand, I have the misfortune of being stuck with a soft-modem, roughly the *same* proprietary code is provided as a binary file, and a linux driver (source provided) interfaces with it. In that case the kernel is flagged as "tainted".

Can you honestly tell apart the two cases, if you don't make a it a case of "religion war"?

It has absolutely nothing to do with religion.

Quoted 5 lines

Let's try not to be ridiculous, please.

It's not abotu being ridiculous. It's about honoring peoples copyrights.

Quoted 3 lines

As an end user, if I buy a full fledged modem, I get some amount of proprietary, non GPL, code which executes within the board or the PCMCIA card of the modem. The GPL driver may even support the functionality of downloading a new version of *proprietary* code into the flash Eprom of the device. The GPL linux driver interfaces with it, and all is kosher.

Indeed. Everything is kosher, because the other piece of hardware and software has _nothing_ to do with the kernel. It's not linked into it, it cannot reasonably corrupt internal kernel data structures with random pointer bugs, and in general you can think of firmware as part of the _hardware_, not the software of the machine.

Quoted 3 lines

On the other hand, I have the misfortune of being stuck with a soft-modem, roughly the *same* proprietary code is provided as a binary file, and a linux driver (source provided) interfaces with it. In that case the kernel is flagged as "tainted".

It is flagged as tainted, because your argument that it is "the same code" is totally BOGUS AND UNTRUE!

In the binary kernel module case, a bug in the code corrupts random data structures, or accesses kernel internals without holding the proper locks, or does a million other things wrong, BECAUSE A KERNEL MODULE IS VERY INTIMATELY LINKED WITH THE KERNEL.

A kernel module is _not_ a separate work, and can in _no_ way be seen as "part of the hardware". It's very much a part of the _kernel_. And the kernel developers require that such code be GPL'd so that it can be fixed, or if there's a valid argument that it's not a derived work and not GPL'd, then the kernel developers who have to support the end result mess most definitely do need to know about the taint.

You are not the first (and sadly, you likely won't be the last) person to equate binary kernel modules with binary firmware. And I tell you that such a comparison is ABSOLUTE CRAPOLA. There's a damn big difference between running firmware on another chip behind a PCI bus, and linking into the kernel directly.

And if you don't see that difference, then you are either terminally stupid, or you have some ulterior reason to claim that they are the same case even though they clearly are NOT.

It has absolutely nothing to do with religion.

Linus Torvalds ha scritto:

Quoted 11 lines · Giuliano Colla

Quoted 5 lines

Let's try not to be ridiculous, please.

It's not abotu being ridiculous. It's about honoring peoples copyrights.

On that ground you're correct.

Quoted 45 lines

Quoted 8 lines

As an end user, if I buy a full fledged modem, I get some amount of proprietary, non GPL, code which executes within the board or the PCMCIA card of the modem. The GPL driver may even support the functionality of downloading a new version of *proprietary* code into the flash Eprom of the device. The GPL linux driver interfaces with it, and all is kosher.

Indeed. Everything is kosher, because the other piece of hardware and software has _nothing_ to do with the kernel. It's not linked into it, it cannot reasonably corrupt internal kernel data structures with random pointer bugs, and in general you can think of firmware as part of the _hardware_, not the software of the machine.

Quoted 6 lines

On the other hand, I have the misfortune of being stuck with a soft-modem, roughly the *same* proprietary code is provided as a binary file, and a linux driver (source provided) interfaces with it. In that case the kernel is flagged as "tainted".

It is flagged as tainted, because your argument that it is "the same code" is totally BOGUS AND UNTRUE!

In the binary kernel module case, a bug in the code corrupts random data structures, or accesses kernel internals without holding the proper locks, or does a million other things wrong, BECAUSE A KERNEL MODULE IS VERY INTIMATELY LINKED WITH THE KERNEL.

A kernel module is _not_ a separate work, and can in _no_ way be seen as "part of the hardware". It's very much a part of the _kernel_. And the kernel developers require that such code be GPL'd so that it can be fixed, or if there's a valid argument that it's not a derived work and not GPL'd, then the kernel developers who have to support the end result mess most definitely do need to know about the taint.

You are not the first (and sadly, you likely won't be the last) person to equate binary kernel modules with binary firmware. And I tell you that such a comparison is ABSOLUTE CRAPOLA. There's a damn big difference between running firmware on another chip behind a PCI bus, and linking into the kernel directly.

Quoted 6 lines

And if you don't see that difference, then you are either terminally stupid, or you have some ulterior reason to claim that they are the same case even though they clearly are NOT.

O.K. you're right. By a strictly technical point of view I goofed.

But please do consider a different perspective.

I'm an end user.
I download a damn Linuxant driver because the manufacturer of the laptop I own has seen fit to use a Conexant chipset.
In order to do that I must:
a) Pay a (small) sum.
b) Accept a Microsoft-like license agreement.
If at that point I haven't realized that I'm not getting a fully GPL'd software I'm really terminally stupid as you kindly suggest.

If I'm not technically skilled, I don't know how much of the stuff I downloaded executes in kernel space and how much in user's space. But, as an end user, I don't care too much, because bogus code executing in user space (with root privileges) cannot affect kernel stability, but can make my system completely unusable as far as I'm concerned (as an end user, I stress).

The big difference you mention exist when you *debug* the damn thing (which of course is your concern), but the difference fades out when you *use* it (which is my concern).

However, if I'm not terminally stupid, I will never think of addressing to kernel people in order to fix problems arising from or after loading the driver, and associated utilities, even if lsmod doesn't show "tainted" modules. Kernel people shouldn't even consider supporting the resulting mess.

That said, I'd like to explain what made me react to the announcement posted.

Linuxant have figured a Microsoft-like brute force hardware detection
mechanism: they attempt to load *all* drivers, and only the one which fits with actual hardware gets loaded. Of course the user gets tons of error messages. They've tried to reduce the amount of error message by using the pathetic workaround of a \0 after the GPL string. All of that is much on Microsoft style, i.e. to find a workaround instead of a solution.

But I didn't appreciate that the reaction to that mess has been also on Microsoft style.
The reaction has been:

a) a workaround of the workaround (if you put a \0, I'll detect the Linuxant string)

b) a lie (the /GPL directory is empty).

This appears to me the beginning of a process which may lead to further workarounds, and which will waste time and energies which may be addressed to more useful issues.

A more relaxed reaction of the sort:
"Dear Linuxant people, if you're unable to work out an acceptable hardware detection mechanism, why don't you address your line toward interesting opportunities in the agriculture field, instead of messing up with GPL license strings?"
would have been in my opinion much more appropriate.

But if you really insist on your policy, try at least to avoid Microsoft style, and upon recognition of the Linuxant/Conexant string, flag the module not as "tainted" but rather as "crappy", or "brain-damaged".

<..>

Quoted 4 lines

It has absolutely nothing to do with religion.

It shouldn't. But it's not good to convey even remotely this feeling. I'm proud of being, in my limited capacities, a member of the Open Source community. I want to continue to be proud of it. If I detect something that doesn't sound right, I feel it necessary to point it out. Nothing makes me happier than being proved wrong.

--
Ing. Giuliano Colla
Direttore Tecnico
Copeca srl
Bologna Italy

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Hello,

I have 2 parts to this IMHO exerpt.
Top half is system level oriented in response to the hardware detection "issue", and the bottom half is in regard to the tainted kernel module load flag.

Creating a hardware detection package for a distribution is not an
incredibly difficult thing to do, since most of the tools that one needs is readily available.

Now about the "tainted" flag, the end user who is at the level of who needs this whole package is probably not going to know too much about what "tainted" means, or would not know that is is even there.

Professionals will be flagged, but I think they have a right to know.

I would want to know if a device driver that I have loaded is indeed a binary-type within a wrapper of some kind. That will give me an indication of what to expect. If I caught any wind of the vendor HIDING such things from me, because they want to make their device driver APPEAR to be just as native as the rest, then I would say that TAINTS the VENDOR'S REPUTATION in my eyes.
You have to remember who you are trying to fool.

Linus Torvalds ha scritto:

Quoted 5 lines · Giuliano Colla

Quoted 2 lines

Let's try not to be ridiculous, please.

It's not abotu being ridiculous. It's about honoring peoples copyrights.

On that ground you're correct.
[...]
But please do consider a different perspective.

I'm an end user.
I download a damn Linuxant driver because the manufacturer of the laptop I own has seen fit to use a Conexant chipset.
In order to do that I must:
a) Pay a (small) sum.
b) Accept a Microsoft-like license agreement.
If at that point I haven't realized that I'm not getting a fully GPL'd software I'm really terminally stupid as you kindly suggest.

However, if I'm not terminally stupid, I will never think of addressing to kernel people in order to fix problems arising from or after loading the driver, and associated utilities, even if lsmod doesn't show "tainted" modules. Kernel people shouldn't even consider supporting the resulting mess.

That said, I'd like to explain what made me react to the announcement posted.

Linuxant have figured a Microsoft-like brute force hardware detection
mechanism: they attempt to load *all* drivers, and only the one which [...]
But I didn't appreciate that the reaction to that mess has been also on Microsoft style.
The reaction has been:

a) a workaround of the workaround (if you put a \0, I'll detect the Linuxant string)

b) a lie (the /GPL directory is empty).

Quoted 18 lines · Giuliano Colla

Linus Torvalds ha scritto:

Quoted 10 lines · Giuliano Colla

Quoted 6 lines

Let's try not to be ridiculous, please.

It's not abotu being ridiculous. It's about honoring peoples copyrights.

On that ground you're correct.
[...]
But please do consider a different perspective.

Quoted 10 lines

I'm an end user.
I download a damn Linuxant driver because the manufacturer of the laptop I own has seen fit to use a Conexant chipset.
In order to do that I must:
a) Pay a (small) sum.
b) Accept a Microsoft-like license agreement.
If at that point I haven't realized that I'm not getting a fully GPL'd software I'm really terminally stupid as you kindly suggest.

If you look at the price of a cardbus real modem on ebay, you might be surprised that these things are really cheap. Sometimes buying software to support the winmodems is actually more expensive than buying a real modem.

Quoted 7 lines

However, if I'm not terminally stupid, I will never think of addressing to kernel people in order to fix problems arising from or after loading the driver, and associated utilities, even if lsmod doesn't show "tainted" modules. Kernel people shouldn't even consider supporting the resulting mess.

How would you know NOT to complain to linux-kernel if there is no sign you shouldn't?

Quoted 10 lines

That said, I'd like to explain what made me react to the announcement posted.

Linuxant have figured a Microsoft-like brute force hardware detection
mechanism: they attempt to load *all* drivers, and only the one which [...]
But I didn't appreciate that the reaction to that mess has been also on Microsoft style.
The reaction has been:

Quoted 4 lines

a) a workaround of the workaround (if you put a \0, I'll detect the Linuxant string)

Was there anything else that could have been done for the existing fake GPL modules?

Quoted 3 lines

b) a lie (the /GPL directory is empty).

I have this FUCKING Linuxant .rpm with an empty GPL directory right on my hard disk. And this .rpm is signed by Linuxant. So either Linuxant has been hacked (someone stole the key, signed a bogus rpm and broke into thir site uploading it) or they are careless (forgetting to fill the GPL directory for some packages). In both cases I would not trust them.

There's no *run-time* sign. But I was made aware of that when I downloaded it from a different source, and I had to agree to a non GPL license. It didn't originate from kernel group and I'm using it at my own risk.

It may make sense not to have anything left in the GPL directory in a binary only .rpm package, because once linked GPL parts cannot be told apart from non-GPL ones.

Quoted 7 lines

It may make sense not to have anything left in the GPL directory in a binary only .rpm package, because once linked GPL parts cannot be told apart from non-GPL ones.

When speaking about loadable kernel modules: yes they can! That's what modinfo(8) is for!

Oh wait, someone played tricks with a \0 character...

Gr{oetje,eeting}s,

Date: Mon, 03 May 2004 00:26:13 +0200
From: Giuliano Colla <[email protected]>
To: Geert Uytterhoeven <[email protected]>
Cc: Carl-Daniel Hailfinger <[email protected]>,
Linus Torvalds <[email protected]>, [email protected], Rusty Russell <[email protected]>, Andrew Morton <[email protected]>, Linux Kernel Mailing List <[email protected]>
Subject: Re: [hsflinux] [PATCH] Blacklist binary-only modules lying about
their license

Geert Uytterhoeven ha scritto:

Quoted 9 lines · Giuliano Colla

Quoted 7 lines

It may make sense not to have anything left in the GPL directory in a binary only .rpm package, because once linked GPL parts cannot be told apart from non-GPL ones.

Quoted 9 lines

When speaking about loadable kernel modules: yes they can! That's what modinfo(8) is for!

Oh wait, someone played tricks with a \0 character...

Gr{oetje,eeting}s,

What I mean is that in a binary rpm you have binaries which link together GPL and non GPL code. There's not such a thing as a GPL binaries to put in the GPL directory. This holds true whether they play tricks or not. If you want to see the GPL'd code you must download the source package.
You may blame them for playing tricks with \0 character, but you can't blame them for an empty GPL directory in the binary package, when you find it properly populated in the source package.

Groetje,
-----
Giuliano Colla

Whenever people agree with me, I always feel I must be wrong (O. Wilde)

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

except that this brings up the issue of if the GPL will allow this linking to take place at all.

my understanding of what RMS and the FSF have said is that they don't believe that this is allowed at all.

I don't see a need to get all complicated about this. This is simple, really: since a C string ends at the '\0', the module has been declared to be GPL code. We shouldn't care if that C string is part of a larger array. This is a damn obvious case of willful circumvention of copyright control, access control, digital rights management, etc.

Unleash the sharks.

Hi,

LinuxAnt offers binary only modules without any sources.

To circumvent our
MODULE_LICENSE checks LinuxAnt has inserted a "\0" into their declaration:

MODULE_LICENSE("GPL\0for files in the \"GPL\" directory; for others, only LICENSE file applies");

The way I see it, they know a C string ends with a '\0'. This is like saying that a English sentence ends with a dot. If they wrote "GPL\0" they are effectively saying that the license *is* GPL period.

So, where the source code? :)

Funny, this reminds me of VGA BIOSes which put "IBM Compatible" at the right location, because lots of programs were looking for "IBM" to check if this way such a bios. Same check, same workaround :-) I hope they have patented this trick so that they will be the only ones using it :-)

Quoted 4 lines

The attached patch blacklists all modules having "Linuxant" or "Conexant" in their author string. This may seem a bit broad, but AFAIK both companies never have released anything under the GPL and have a strong history of binary-only modules.

What would be smarter would be to try to understand why they do this.

At
the moment, it seems to me that their only problem is to taint the kernel.

Why ? I don't this that any old modutils/module-utils found in any distros don't load properly such modules. So perhaps they only want not to taint the kernel because it appears dirty to their customers who will not receive any more support from LKML. So perhaps what we really need is to add a new

MODULE_SUPPORT field stating where to get support from in case of bugs, oopses or panics on a tainted kernel. Thus, the module author would be able to insert something such as "[email protected]" which will be displayed on each oops/panic/etc... Even if this is a long list because the customer uses connexant, nvidia, checkpoint and I don't know what, at least he will get 3 email addresses for his support. And it might reassure these authors to know that the customer will ask them before asking us with our automatic replies "unload your binary modules...".

Actually, we also have no desire nor purpose to prevent tainting. The purpose of the workaround is to avoid repetitive warning messages generated when multiple modules belonging to a single logical "driver" are loaded (even when a module is only probed but not used due to the hardware not being present). Although the issue may sound trivial/harmless to people on the lkml, it was a frequent cause of confusion for the average person.

Quoted 8 lines

Actually, we also have no desire nor purpose to prevent tainting. The purpose of the workaround is to avoid repetitive warning messages generated when multiple modules belonging to a single logical "driver" are loaded (even when a module is only probed but not used due to the hardware not being present). Although the issue may sound trivial/harmless to people on the lkml, it was a frequent cause of confusion for the average person.

Would it not be better to simply place a notice in the readme explaining what the error messages mean, rather than working around the liscense checking code? Educate the users, rather than fibbing.

--
Adam Jaskiewicz

Quoted 3 lines · Adam Jaskiewicz

Would it not be better to simply place a notice in the readme explaining what the error messages mean, rather than working around the liscense checking code? Educate the users, rather than fibbing.

Good idea. We will try to clarify the matter in the docs for the next release. A lot of users don't read them though, so a proper fix remains necessary..

Quoted 11 lines · Marc Boucher

Quoted 4 lines · Adam Jaskiewicz

Would it not be better to simply place a notice in the readme explaining what
the error messages mean, rather than working around the liscense checking code? Educate the users, rather than fibbing.

Good idea. We will try to clarify the matter in the docs for the next release.
A lot of users don't read them though, so a proper fix remains necessary..

Does your company honestly feel that misleading the module loading tools is actually the proper way to work around the issue of repetitive warning messages? This is blatently misleading and does not reflect well, especially when the "GPL" directory mentioned in the source string is actually empty.

A "proper fix" begins with not attempting to mislead the kernel/tools about the license...

Maybe kernel should display warning only once per given licence or even once per boot (who needs warning about tainting tainted kernel?)

Quoted 1 line · Grzegorz Kulewski

Maybe kernel should display warning only once per given licence or even once per boot (who needs warning about tainting tainted kernel?)

I think that's a very good point. If the kernel is already tainted, maybe we don't need to print out additional taint messages.

Quoted 4 lines · Chris Friesen

Quoted 2 lines · Grzegorz Kulewski

Maybe kernel should display warning only once per given licence or even once per boot (who needs warning about tainting tainted kernel?)

Quoted 2 lines

I think that's a very good point. If the kernel is already tainted, maybe we don't need to print out additional taint messages.

That could be confusing if it's important for the user to know which modules taint the kernel. If tainting is only mentioned for the first tainting, then the user might be lead to believe that subsquent ones do not taint the kernel, even though they do.

Maybe kernel should display warning only once per given licence or even once per boot (who needs warning about tainting tainted kernel?)

Quoted 2 lines · Grzegorz Kulewski

Maybe kernel should display warning only once per given licence or even once per boot (who needs warning about tainting tainted kernel?)

If your kernel is tainted by 3 different modules, it saves you 2 reboots when trying to replicate a problem with an untainted kernel.

Other than that, there's probably no reason to complain on a re-taint.

Quoted 7 lines · On Martes, 27 de Abril de 2004 20:54, [email protected] wrote:

Quoted 2 lines · Grzegorz Kulewski

Maybe kernel should display warning only once per given licence or even once per boot (who needs warning about tainting tainted kernel?)

If your kernel is tainted by 3 different modules, it saves you 2 reboots when trying to replicate a problem with an untainted kernel.

what about something like a /proc/tainted list of modules?

I think that /proc/tainted would be better than spamming logs after each load of tainted module...
But probably modules should not be removed from /proc/tainted on unloading (to prevent from "un-tainting" the kernel by "clever" users).

2 ideas:

Printing if the tainted module is loaded or unloaded

Quoted 1 line · Grzegorz Kulewski

Maybe kernel should display warning only once per given licence or even once per boot (who needs warning about tainting tainted kernel?)

If your kernel is tainted by 3 different modules, it saves you 2 reboots when trying to replicate a problem with an untainted kernel.

Other than that, there's probably no reason to complain on a re-taint.

Quoted 7 lines · Marc Boucher

Quoted 3 lines · Adam Jaskiewicz

Would it not be better to simply place a notice in the readme explaining what the error messages mean, rather than working around the liscense checking code? Educate the users, rather than fibbing.

Good idea. We will try to clarify the matter in the docs for the next release. A lot of users don't read them though, so a proper fix remains necessary..

Does your company honestly feel that misleading the module loading tools is actually the proper way to work around the issue of repetitive warning messages? This is blatently misleading and does not reflect well, especially when the "GPL" directory mentioned in the source string is actually empty.

Quoted 1 line · Chris Friesen

Does your company honestly feel that misleading the module loading tools is actually the proper way to work around the issue of repetitive warning messages? This is blatently misleading and does not reflect well, especially when the "GPL" directory mentioned in the source string is actually empty.

It is a purely technical workaround. There is nothing misleading to the human eye,

and the GPL directory isn't empty; it is included in full in our generic .tar.gz, rpm and .deb packages.

Quoted 10 lines · Marc Boucher

Quoted 1 line · Chris Friesen

Does your company honestly feel that misleading the module loading tools is actually the proper way to work around the issue of repetitive warning messages? This is blatently misleading and does not reflect well, especially when the "GPL" directory mentioned in the source string is actually empty.

It is a purely technical workaround. There is nothing misleading to the human eye,

modinfo reports a GPL license, and the kernel does not report itself as tainted. That's misleading.

Quoted 2 lines

and the GPL directory isn't empty; it is included in full in our generic .tar.gz, rpm and .deb packages.

My apologies. I was going on the word of the original poster.

Quoted 9 lines · Marc Boucher

Quoted 5 lines · Chris Friesen

Does your company honestly feel that misleading the module loading tools is actually the proper way to work around the issue of repetitive warning messages? This is blatently misleading and does not reflect well, especially when the "GPL" directory mentioned in the source string is actually empty.

Quoted 2 lines

It is a purely technical workaround. There is nothing misleading to the human eye,

modinfo reports a GPL license, and the kernel does not report itself as tainted. That's misleading.

Quoted 3 lines

and the GPL directory isn't empty; it is included in full in our generic .tar.gz, rpm and
.deb packages.

My apologies. I was going on the word of the original poster.

A lot of users don't read them though, so a proper fix remains necessary..

Hi Adam,

Quoted 8 lines · Adam Jaskiewicz

Quoted 8 lines

Actually, we also have no desire nor purpose to prevent tainting. The purpose of the workaround is to avoid repetitive warning messages generated when multiple modules belonging to a single logical "driver" are loaded (even when a module is only probed but not used due to the hardware not being present). Although the issue may sound trivial/harmless to people on the lkml, it was a frequent cause of confusion for the average person.

Quoted 3 lines

Would it not be better to simply place a notice in the readme explaining what the error messages mean, rather than working around the liscense checking code? Educate the users, rather than fibbing.

Good idea. We will try to clarify the matter in the docs for the next release. A lot of users don't read them though, so a proper fix remains necessary..

Actually, we also have no desire nor purpose to prevent tainting. The purpose of the workaround is to avoid repetitive warning messages generated when multiple modules belonging to a single logical "driver" are loaded (even when a module is only probed but not used due to the hardware not being present).

Quoted 4 lines · Marc Boucher

Actually, we also have no desire nor purpose to prevent tainting. The purpose of the workaround is to avoid repetitive warning messages generated when multiple modules belonging to a single logical "driver" are loaded (even when a module is only probed but not used due to the hardware not being present).

You lied about the license, rather than submit a one-line change to kernel/module.c.

This shows a lack of integrity that I find personally repulsive.

Name: Only Print Taint Message Once
Status: Trivial

Only print the tainted message the first time. Its purpose is to warn users that we can't support them, not to fill their logs.

diff -urpN --exclude TAGS -X /home/rusty/devel/kernel/kernel-patches/current-dontdiff --minimal .22310-linux-2.6.6-rc2-bk5/kernel/module.c .22310-linux-2.6.6-rc2-bk5.updated/kernel/module.c
--- .22310-linux-2.6.6-rc2-bk5/kernel/module.c 2004-04-22
08:04:00.000000000 +1000
+++ .22310-linux-2.6.6-rc2-bk5.updated/kernel/module.c 2004-04-28
09:03:31.000000000 +1000

kernel/module.c +1 -1

@@ -1131,7 +1131,7 @@ static void set_license(struct module *m
 		license = "unspecified";
 
 	mod->license_gplok = license_is_gpl_compatible(license);
-	if (!mod->license_gplok) {
+	if (!mod->license_gplok && !(tainted & TAINT_PROPRIETARY_MODULE)) {
 		printk(KERN_WARNING "%s: module license '%s' taints kernel.\n",
 		       mod->name, license);
 		tainted |= TAINT_PROPRIETARY_MODULE;

Signature · 2 lines

-- 
Anyone who quotes me in their signature is an idiot -- Rusty Russell

Rusty, the workaround was done a while ago, back in the 2.5 days when your new module code was still very much in flux. It was necessary to have an effective short-term solution for the existing installed base (2.4), since we could not continue to confuse customers while waiting for the patch to propagate. In other cases, we have gladly submitted patches when we encountered bugs and could fix them. Had we known that the module fix was so simple, it would of course have been submitted it to you in parallel.

Also since you and I have worked well together in other projects (netfilter core) and are long time friends, I don't understand why you are so quick to question my integrity in public. We didn't lie about anything; the license text is perfectly clear,

and the
political situation with Conexant's proprietary signal processing code outside of our control.

Quoted 9 lines · Marc Boucher

Rusty, the workaround was done a while ago, back in the 2.5 days when your new module code was still very much in flux. It was necessary to have an effective short-term solution for the existing installed base (2.4), since we could not continue to confuse customers while waiting for the patch to propagate. In other cases, we have gladly submitted patches when we encountered bugs and could fix them. Had we known that the module fix was so simple, it would of course have been submitted it to you in parallel.

No, it wasn't *necessary*: you made a choice that not confusing your customers was more important to you than not increasing the support burden on kernel developers by releasing a silently tainted module into the wild.

That might make sense from your business perspective, but you must accept its consequences: anger from those you've inconvenienced for your benefit. There's no reason they should give a fuck if your customers are confused or not.

Quoted 5 lines

Also since you and I have worked well together in other projects (netfilter core) and are long time friends, I don't understand why you are so quick to question my integrity in public. We didn't lie about anything; the license text is perfectly clear,

No, it's only clear if someone looks at the module's source (what's available of it), in which case the license would presumably be clear from comments or documentation anyway. The main purpose of the MODULE_LICENSE() macro is to label the *module binary* with the license. To the standard tools that look at it there, it says "GPL" which is clearly misleading.

Quoted 4 lines

and the
political situation with Conexant's proprietary signal processing code outside of our control.

Signature · 4 lines

David Gibson			| For every complex problem there is a
david AT gibson.dropbear.id.au	| solution which is simple, neat and
				| wrong.
http://www.ozlabs.org/people/dgibson

Quoted 9 lines · David Gibson

Quoted 8 lines · Marc Boucher

Rusty, the workaround was done a while ago, back in the 2.5 days when your new module code was still very much in flux. It was necessary to have an effective short-term solution for the existing installed base (2.4), since we could not continue to confuse customers while waiting for the patch to propagate. In other cases, we have gladly submitted patches when we encountered bugs and could fix them. Had we known that the module fix was so simple, it would of course have been submitted it to you in parallel.

Quoted 4 lines

No, it wasn't *necessary*: you made a choice that not confusing your customers was more important to you than not increasing the support burden on kernel developers by releasing a silently tainted module into the wild.

In an enterprise, customers always come first. Nonetheless, I don't believe that this issue had a significant impact on kernel developers.

Futile attempts to perform license checks generating redundant and confusing errors, restricting access to kernel APIs for religious reasons,

and the general lack of stable APIs and pragmatic understanding for the needs of third-party driver suppliers result in much greater everyday inconveniences to ordinary users and are more damaging to the acceptance

of linux than the theoretical inconvenience our workaround might have caused to kernel developers.

Quoted 15 lines · Marc Boucher

Quoted 14 lines · David Gibson

Quoted 8 lines · Marc Boucher

Rusty, the workaround was done a while ago, back in the 2.5 days when your new module code was still very much in flux. It was necessary to have an effective short-term solution for the existing installed base (2.4), since we could not continue to confuse customers while waiting for the patch to propagate. In other cases, we have gladly submitted patches when we encountered bugs and could fix them. Had we known that the module fix was so simple, it would of course have been submitted it to you in parallel.

No, it wasn't *necessary*: you made a choice that not confusing your customers was more important to you than not increasing the support burden on kernel developers by releasing a silently tainted module into the wild.

Quoted 2 lines

In an enterprise, customers always come first. Nonetheless, I don't believe that this issue had a significant impact on kernel developers.

You have absolutely no right to place _any_ burden at all on kernel hackers. "I don't believe..." just doesn't cut it.

[...]

Quoted 3 lines

Futile attempts to perform license checks generating redundant and confusing errors, restricting access to kernel APIs for religious reasons,

So? It is not _your_ call to decide under what conditions (if any) you are allowed to use said APIs. You did not comply with the conditions as stated. Nothing more to be said about it, you admitted so yourself.

Quoted 5 lines

and the general lack of stable APIs and pragmatic understanding for the needs of third-party driver suppliers result in much greater everyday inconveniences to ordinary users and are more damaging to the acceptance

Third-party driver suppliers are welcome to work _with_ the kernel community, who will in many cases happily fix their drivers as a matter of course when updating the kernel. As long as source is available, that is. If not, hackers don't want to spend time for _others_ to be able to reap benefits. Go read the GPL, and then think hard about why Linux hackers elected the GPL as the license for the kernel.

Quoted 3 lines

of linux than the theoretical inconvenience our workaround might have caused to kernel developers.

There is a very down-to-earth inconvenience called "license violation" here. You got a license to use the kernel API under certain conditions, you violated those.

Signature · 9 lines

Dr. Horst H. von Brand                   User #22616 counter.li.org
Departamento de Informatica                     Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria              +56 32 654239
Casilla 110-V, Valparaiso, Chile                Fax:  +56 32 797513
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Quoted 1 line · Horst von Brand

Marc Boucher <[email protected]> said:

Quoted 5 lines

Quoted 2 lines

In an enterprise, customers always come first. Nonetheless, I don't believe that this issue had a significant impact on kernel developers.

You have absolutely no right to place _any_ burden at all on kernel hackers. "I don't believe..." just doesn't cut it.

I stated a personal opinion based on the observation that the issue was raised in a politically provocative way. It didn't come up because specific kernel developers were having a hard time debugging systems with our drivers.

People should understand that we are really trying to help Linux by providing alternative support and drivers for proprietary hardware that otherwise cannot be easily handled in the traditional free-software ways, otherwise they would already have been implemented long ago by one of the many talented linux kernel hackers out there.

Folks who do not agree with the freedom of choice we are providing can simply avoid purchasing hardware without 100% open-source drivers, instead of launching political attacks based on incorrect facts or behaving like a wild mob using intimidation practices (someone posted my personal physical address on Slashdot today).

Quoted 8 lines

Quoted 3 lines

Futile attempts to perform license checks generating redundant and confusing errors, restricting access to kernel APIs for religious reasons,

So? It is not _your_ call to decide under what conditions (if any) you are allowed to use said APIs. You did not comply with the conditions as stated. Nothing more to be said about it, you admitted so yourself.

AFAIK, no GPLONLY APIs are involved.

The workaround is for a confusing
cosmetic issue that has been acknowledged by kernel developers and is being fixed. I have also sent Rusty a proposal for a technical change in our modem drivers that would restore tainting (again, there was never any intent, motivation nor purpose to bypass that)

while keeping the volume
of messages under control.

In an enterprise, customers always come first. Nonetheless, I don't believe that this issue had a significant impact on kernel developers. Had their support burden been significantly increased by our products, the issue would have come up much sooner.

Quoted 4 lines · Marc Boucher

In an enterprise, customers always come first. Nonetheless, I don't believe that this issue had a significant impact on kernel developers. Had their support burden been significantly increased by our products, the issue would have come up much sooner.

This has all deteriorated into childish bickering rather than meaningful debate.

The problem is that Linuxant or whoever has done something which is misleading and violates a tenet of the GPL and the module interface of the Linux kernel.

There may be technical reasons which excuse this, but in the end, Linuxant needs to correct their (unintentional) error and move on. In this society, if you violate copyright and get caught, you get slammed. You've been caught and slammed. Fortunately, no one is suing you over it.

But spending your time arguing about it rather than making it right is only making you look like a jerk. At this point, no one cares about your excuses for why you did it -- excuses accepted, technical reasons understood, we don't blame you for what you did in the PAST.

If I were in your position, I would say, "I'm sorry. I understand the problem, and I will fix it as soon as possible." THAT would be a professional and ethical thing to do. It's also a good way to get on the GOOD side of the Linux community. Everyone makes mistakes; what matters is how they DEAL with those mistakes.

Timothy,

I am truly sorry about the concern this has caused, have already publicly apologized for not submitting a patch to properly correct the issue when the workaround was implemented, and proposed a change to the modem drivers that should go in as soon as possible to restore tainting and one instance of the warning messages while avoiding the flood.

At the same time, I think that the "community" should, without relinquishing its principles, be less eager before getting the facts to attack people and companies trying to help in good faith, and be more realistic when it comes to satisfying practical needs of ordinary users.

At the same time, I think that the "community" should, without relinquishing its principles, be less eager before getting the facts to attack people and companies trying to help in good faith, and be more realistic when it comes to satisfying practical needs of ordinary users.

Quoted 1 line · Marc Boucher

At the same time, I think that the "community" should, without relinquishing its principles, be less eager before getting the facts to attack people and companies trying to help in good faith, and be more realistic when it comes to satisfying practical needs of ordinary users.

I wouldn't be averse to changing the text the kernel prints when loading a module with an incompatible license. If the text "$MOD_FOO: module license '$BLAH' taints kernel." upsets the users, it's easy enough to change it.

How about the following?

"Due to $MOD_FOO's license ($BLAH), the Linux kernel community cannot resolve problems you may encounter. Please contact $MODULE_VENDOR for support issues."

Quoted 12 lines · Rik van Riel

Quoted 5 lines · Marc Boucher

At the same time, I think that the "community" should, without relinquishing its principles, be less eager before getting the facts to attack people and companies trying to help in good faith, and be more realistic when it comes to satisfying practical needs of ordinary users.

I wouldn't be averse to changing the text the kernel prints when loading a module with an incompatible license. If the text "$MOD_FOO: module license '$BLAH' taints kernel." upsets the users, it's easy enough to change it.

Quoted 5 lines

How about the following?

"Due to $MOD_FOO's license ($BLAH), the Linux kernel community cannot resolve problems you may encounter. Please contact $MODULE_VENDOR for support issues."

I think something like that is much easier to decipher.

I wouldn't be averse to changing the text the kernel prints when loading a module with an incompatible license. If the text "$MOD_FOO: module license '$BLAH' taints kernel." upsets the users, it's easy enough to change it.

How about the following?

"Due to $MOD_FOO's license ($BLAH), the Linux kernel community cannot resolve problems you may encounter. Please contact $MODULE_VENDOR for support issues."

Signature · 3 lines

"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it." - Brian W. Kernighan

Hi Rik,

Your new proposed message sounds much clearer to the ordinary mortal and would imho be a significant improvement. Perhaps printing repetitive warnings for identical $MODULE_VENDOR strings could also be avoided, taking care of the redundancy/volume problem as well..

Quoted 4 lines

Your new proposed message sounds much clearer to the ordinary mortal and would imho be a significant improvement. Perhaps printing repetitive warnings for identical $MODULE_VENDOR strings could also be avoided, taking care of the redundancy/volume problem as well..

Is this worth 100 or 200 bytes of code though?
I'd have to say no.

Quoted 2 lines · Ian Stirling

Quoted 1 line

Your new proposed message sounds much clearer to the ordinary mortal and would imho be a significant improvement. Perhaps printing repetitive warnings for identical $MODULE_VENDOR strings could also be avoided, taking care of the redundancy/volume problem as well..

Quoted 2 lines

Is this worth 100 or 200 bytes of code though?
I'd have to say no.

I suspect it'll be worth it. If only because it'll save the kernel community from people asking things like:

"help, my kernel is tainted! what does it mean and how can I fix it?"

Quoted 6 lines · Marc Boucher

Hi Rik,

Your new proposed message sounds much clearer to the ordinary mortal and would imho be a significant improvement. Perhaps printing repetitive warnings for identical $MODULE_VENDOR strings could also be avoided, taking care of the redundancy/volume problem as well..

Is this worth 100 or 200 bytes of code though?
I'd have to say no.

Quoted 8 lines · you

Quoted 6 lines · Marc Boucher

Hi Rik,

Your new proposed message sounds much clearer to the ordinary mortal and would imho be a significant improvement. Perhaps printing repetitive warnings for identical $MODULE_VENDOR strings could also be avoided, taking care of the redundancy/volume problem as well..

Quoted 2 lines

Is this worth 100 or 200 bytes of code though?
I'd have to say no.

1000-2000(?) instructions to display the message and some x(?) instructions

Hi Rik,

Your new proposed message sounds much clearer to the ordinary mortal and would imho be a significant improvement. Perhaps printing repetitive warnings for identical $MODULE_VENDOR strings could also be avoided, taking care of the redundancy/volume problem as well..

Quoted 1 line · Marc Boucher

At the same time, I think that the "community" should, without relinquishing its principles, be less eager before getting the facts to attack people and companies trying to help in good faith, and be more realistic when it comes to satisfying practical needs of ordinary users.

I wouldn't be averse to changing the text the kernel prints when loading a module with an incompatible license. If the text "$MOD_FOO: module license '$BLAH' taints kernel." upsets the users, it's easy enough to change it.

How about the following?

"Due to $MOD_FOO's license ($BLAH), the Linux kernel community cannot resolve problems you may encounter. Please contact $MODULE_VENDOR for support issues."

Quoted 3 lines

"Due to $MOD_FOO's license ($BLAH), the Linux kernel community cannot resolve problems you may encounter. Please contact $MODULE_VENDOR for support issues."

Sounds very "politically correct", but certainly more descriptive and less alarming.

Quoted 6 lines · Timothy Miller

Quoted 3 lines

"Due to $MOD_FOO's license ($BLAH), the Linux kernel community cannot resolve problems you may encounter. Please contact $MODULE_VENDOR for support issues."

Sounds very "politically correct", but certainly more descriptive and less alarming.

More importantly, it directs the support burden to where it, IMHO, belongs.

Quoted 7 lines · Rik van Riel

Quoted 5 lines · Timothy Miller

Quoted 3 lines

"Due to $MOD_FOO's license ($BLAH), the Linux kernel community cannot resolve problems you may encounter. Please contact $MODULE_VENDOR for support issues."

Quoted 6 lines

Quoted 2 lines

Sounds very "politically correct", but certainly more descriptive and less alarming.

More importantly, it directs the support burden to where it, IMHO, belongs.

Just to throw in my two cents at the end of this long debate... :-)

I heartily endorse (for what little that is worth ;-) the change in text. It adds clarity, it provides more information as to where to go for information. It is hard to misconstrue as a message of impending doom, consider that a good synonym for tainted is corrupted, and a corrupted kernel is a bad thing :-).

Cheers,
Paul

While we're on all of this, are we going to change "tained" to some other less alarmist word?

Hmmm... how about "untrusted"? Not sure...

Quoted 3 lines · Timothy Miller

Hmmm... how about "untrusted"? Not sure...

I like "untrusted". Another option is some like "binary only modules can make your system unstable and kernel developers have nothing to do with that" (but well written, and shorter if possible).

Signature · 3 lines

Jorge Bernal aka. Koke
[email protected] // [email protected]
JID: [email protected]

The inherent instability of binary modules is a religious myth. Any

Quoted 1 line · Marc Boucher

The inherent instability of binary modules is a religious myth. Any

No, it's REAL, unless VERY CAREFULLY handled. If your binary uses a spinlock, it either works only on SMP or only on UP. If your binary uses any number of kernel structures and interfaces, you are subject to the whims of whomever compiled the kernel. spinlock debuging changes the sizeof(spinlock_t). Some APIs become macros or inlines depending on config options.

You have to toally separate all the kernel code from the binary code. If you can't do that, you end up with a kernel module that works ONLY on a very small subset of kernels. And that sucks. We don't want to encourage that. If your driver manages to cleanly pull out all the binary gunk from the kernel gunk, then kudos to you.

I still don't like it, but at least it has a chance of running.

The inherent instability of binary modules is a religious myth. Any module can be stable or unstable, depending on how it's written, tested and the environment (hardware/evolving APIs it depends on). For example, Apple's current Mac OS X is extremely stable imho, despite the fact that their hardware drivers are generally binary-only.

The same goes for trustworthiness. It's a matter of point of view / preference whether you trust open-source projects and their security (which can be far from perfect, as evidenced by the recent break-ins in various servers hosting source repositories) more than stuff produced by a corporation. Every model has disadvantages and advantages.

I think that Rik is right when saying that the key information that should be conveyed is who is responsible for providing support. The wording should be kept neutral, without negative connotation nor religious bias.

Perhaps others on this list are getting as tired as I am of your using the term "religious bias" as a negative connotation against people who
support and protect the open source nature of Linux. Maybe you could
at least pretend to respect the people who you supposedly apologized to.

Dear Sean,

Quoted 5 lines · Sean Estabrooks

Perhaps others on this list are getting as tired as I am of your using the term "religious bias" as a negative connotation against people who
support and protect the open source nature of Linux. Maybe you could
at least pretend to respect the people who you supposedly apologized to.

I not only highly respect Rusty but have closely worked and been friends with him for several years. The same applies to several other kernel developers.

Please don't get me wrong. We are entirely for the open-source nature of Linux, and I have been personally contributing for the last 15 years to many open-source projects (for examples, see the AUTHORS section of "man iptables", or search google for my previous email addresses [email protected] & [email protected] to get more historical background).

Quoted 14 lines · Marc Boucher

Dear Sean,

Quoted 5 lines · Sean Estabrooks

Perhaps others on this list are getting as tired as I am of your using the term "religious bias" as a negative connotation against people who
support and protect the open source nature of Linux. Maybe you could
at least pretend to respect the people who you supposedly apologized to.

I not only highly respect Rusty but have closely worked and been friends with him for several years. The same applies to several other kernel developers.

Quoted 5 lines

Please don't get me wrong. We are entirely for the open-source nature of Linux, and I have been personally contributing for the last 15 years to many open-source projects (for examples, see the AUTHORS section of "man iptables", or search google for my previous email addresses [email protected] & [email protected] to get more historical background).

Well, people change over time. 8)

from http://www.linuxant.com/driverloader/

"DriverLoader technology is the ideal Linux solution to support devices for
which no adequate native open-source drivers are available. It also allows vendors to drastically reduce time to market or eliminate the need to support multiple drivers for Windows and Linux. By using the same driver on both platforms, significant resources can be saved."

Rusty was right.

Quoted 30 lines · Bartlomiej Zolnierkiewicz

Quoted 13 lines · Marc Boucher

Dear Sean,

Quoted 5 lines · Sean Estabrooks

Perhaps others on this list are getting as tired as I am of your using the term "religious bias" as a negative connotation against people who
support and protect the open source nature of Linux. Maybe you could
at least pretend to respect the people who you supposedly apologized to.

I not only highly respect Rusty but have closely worked and been friends with him for several years. The same applies to several other kernel developers.

Quoted 5 lines

Please don't get me wrong. We are entirely for the open-source nature of Linux, and I have been personally contributing for the last 15 years to many open-source projects (for examples, see the AUTHORS section of "man iptables", or search google for my previous email addresses [email protected] & [email protected] to get more historical background).

Well, people change over time. 8)

from http://www.linuxant.com/driverloader/

"DriverLoader technology is the ideal Linux solution to support devices for which no adequate native open-source drivers are available. It also allows vendors to drastically reduce time to market or eliminate the need to support multiple drivers for Windows and Linux. By using the same driver on both platforms, significant resources can be saved."

Quoted 1 line

Rusty was right.

Why did you omit the next paragraph (which completes the story):

"We have attempted to reduce the inconvenience of binary-only drivers by separating the proprietary code from the operating-system specific code. The latter is provided in source form, allowing users to install the drivers under any supported version (2.4 or later) of the Linux kernel."

Quoted 8 lines

"DriverLoader technology is the ideal Linux solution to support devices for
which no adequate native open-source drivers are available. It also
allows
vendors to drastically reduce time to market or eliminate the need to
support
multiple drivers for Windows and Linux. By using the same driver on both platforms, significant resources can be saved."

Quoted 1 line

Rusty was right.

Why did you omit the next paragraph (which completes the story):

"We have attempted to reduce the inconvenience of binary-only drivers by separating the proprietary code from the operating-system specific code. The latter is provided in source form, allowing users to install the drivers under any supported version (2.4 or later) of the Linux kernel."

Quoted 9 lines · Peter Williams

Quoted 9 lines

"DriverLoader technology is the ideal Linux solution to support devices for
which no adequate native open-source drivers are available. It also
allows
vendors to drastically reduce time to market or eliminate the need to
support
multiple drivers for Windows and Linux. By using the same driver on
both platforms, significant resources can be saved."

Quoted 8 lines

Quoted 1 line

Rusty was right.

Why did you omit the next paragraph (which completes the story):

"We have attempted to reduce the inconvenience of binary-only drivers by separating the proprietary code from the operating-system specific code. The latter is provided in source form, allowing users to install the drivers under any supported version (2.4 or later) of the Linux kernel."

While it does allow for Linux to get certain kinds of drivers quicker, it turns hardware developers into slackers who don't want to REALLY support Linux and eats away at the spirit of Linux as an open system.

What you're doing may short-term enhance hardware support for Linux, but in the long term, it is a set-back for Linux because it does not encourage hardware vendors to support Linux directly and even pushes true Linux support further into the future.

However we also believe that pragmatically bringing in support for key hardware (which currently cannot otherwise be easily handled in the traditional open-source approach) will benefit Linux, help it gain even more usefulness/acceptance, and make larger numbers of exposed people realize the natural advantages of open-source, then become contributors. On the other hand, forcing open-source down throats with impractical "tainting" schemes, scare tactics or other coercive methods may achieve the opposite effect or turn Linux into just an ideological/political movement rather than the ubiquitous operating system it deserves to be.

Dear Marc,

Who decided that the goal was to become ubiquitous at any cost? How are you so sure that removing the incentive/reward for hardware vendors to release open source drivers is best for Linux in the long run?

There are major chipset vendors out there who have managed to become market leaders while not providing any drivers for Linux.

But other vendors are also still releasing new native linux drivers, despite the availability of our solutions (Intel's project for Centrino

This essentially proves that we are not removing the incentive to do proper native drivers, simply providing more options for 1) people who would otherwise be stuck or unable to use the full functionality of their machines under Linux right now, and 2) vendors who are not able to afford or justify the cost of developing native linux drivers due to the size of the current Linux desktop market. In general these vendors plan to one day produce native drivers, once the numbers make it possible.

Quoted 1 line · Sean Estabrooks

Quoted 5 lines

Dear Marc,

Who decided that the goal was to become ubiquitous at any cost? How are you so sure that removing the incentive/reward for hardware vendors to release open source drivers is best for Linux in the long run?

There are major chipset vendors out there who have managed to become market leaders while not providing any drivers for Linux.

But other vendors are also still releasing new native linux drivers, despite the availability of our solutions (Intel's project for Centrino at ipw2100.sourceforge.net is a great example).

This essentially proves that we are not removing the incentive to do proper native drivers,

Quoted 1 line · Marc Boucher

On Apr 30, 2004, at 12:43 AM, Sean Estabrooks wrote:

It's strictly a cost-based function for a business. If a business can achieve Linux support for free, without paying driver and support engineers, they do so.

DriverLoader significantly lowers that cost, while not providing an open source solution at all.

DriverLoader significantly lowers that cost, while not providing an open source solution at all.

Quoted 1 line · Jeff Garzik

DriverLoader significantly lowers that cost, while not providing an open source solution at all.

Ah, I see.... that makes a HUGE difference. Now I understand what the fuss
is all about. So, that is why everyone jumped on Marc Boucher's throat
trying to annihilate, humiliate, frighten by unsubstantiated allegations
and generally grind him into tiny specks of dust, at the same time falsely
pretending that all the fuss was only about that silly '\0' byte they left in their license string (I wish they knew better not to do that --- there are millions of ways to achieve what they want).

Quoted 8 lines · Tigran Aivazian

Quoted 1 line · Jeff Garzik

DriverLoader significantly lowers that cost, while not providing an open source solution at all.

Ah, I see.... that makes a HUGE difference. Now I understand what the fuss
is all about. So, that is why everyone jumped on Marc Boucher's throat
trying to annihilate, humiliate, frighten by unsubstantiated allegations
and generally grind him into tiny specks of dust, at the same time falsely
pretending that all the fuss was only about that silly '\0' byte they left in their license string (I wish they knew better not to do that --- there are millions of ways to achieve what they want).

Your statement is unsubstantiated. Many companies try to work around the GPL, or walk very close (and often over) the fine line of compliance. They want to get something for nothing, because that's what companies are there for--to make money. There aren't very many altruistic for-profit companies.

Personally, what sticks in my craw is the fact that this company did something wrong, and then tried to defend its actions by claiming that it was to make it easier for the customer. That excuse doesn't wash--what they did was *illegal*. The fact that it also makes it harder to get open-source drivers is a side effect for me.

Chris

Chris,

people should, before insulting us publicly or make unsubstantiated claims that we "lie" or engage in "illegal" actions, perhaps consult a lawyer, and simultaneously use the opportunity to enquire about the meaning of "slander".

I repeat, the \0 is purely a technical workaround, done without any mischievous intent.

We didn't try to hide anything since
the code containing the workaround is open-source, and we even explained back in February the purpose of this workaround on the public hsflinux mailing list, while suggesting that a patch should be sent to effectively take care of the problem. I even apologized to Rusty for not sending that patch ourselves.

Quoted 3 lines · Marc Boucher

Chris,

Quoted 4 lines

people should, before insulting us publicly or make unsubstantiated claims that we "lie" or engage in "illegal" actions, perhaps consult a lawyer, and simultaneously use the opportunity to enquire about the meaning of "slander".

The C string library considers a null to terminate the string. You added a null after the "GPL". It appears to me that this is telling the kernel that the module is licensed as "GPL", even though it is obvious to a person

Quoted 4 lines · Chris Friesen

Quoted 3 lines · Marc Boucher

Chris,

Quoted 8 lines

Quoted 4 lines

people should, before insulting us publicly or make unsubstantiated claims that we "lie" or engage in "illegal" actions, perhaps consult a lawyer, and simultaneously use the opportunity to enquire about the meaning of "slander".

The C string library considers a null to terminate the string. You added a null after the "GPL". It appears to me that this is telling the kernel that the module is licensed as "GPL", even though it is obvious to a person

How about the following:

The MODULE_LICENCE macro is a technical way of indicating the licence to the kernel. There are various ways of putting "comments and remarks" about the licence in the source code, but techically, if

	strcmp (MODULE_LICENCE, "GPL") == 0

then the module is licenced under GPL. (*)

Chris,

people should, before insulting us publicly or make unsubstantiated claims that we "lie" or engage in "illegal" actions, perhaps consult a lawyer, and simultaneously use the opportunity to enquire about the meaning of "slander".

Quoted 4 lines · Marc Boucher

Chris,

people should, before insulting us publicly or make unsubstantiated claims that we "lie" or engage in "illegal" actions, perhaps consult a lawyer, and simultaneously use the opportunity to enquire about the meaning of "slander".

Oh please, I don't think the people here deserve being threatened by you..

Take care, Gilles

Signature · 1 line

If you don't live for something you'll die for nothing!

I am not threatening anyone, only reminding folks that making unsubstantiated public allegations that unfairly damage a person or company's reputation is wrong and generally illegal.

Marc

Quoted 5 lines · Marc Boucher

I am not threatening anyone, only reminding folks that making unsubstantiated public allegations that unfairly damage a person or company's reputation is wrong and generally illegal.

Marc

I do not think the allegations are unsubstantiated or unfair;

on the
contrary, people have identified with specificity what is offensive and probably illegal. Might I remind you of 17 USC 1201(b)(1):

Nope. The real objection was misleading people about the license of the module. That part was clearly wrong.

No person shall manufacture, import, offer to the public, provide, or otherwise traffic in any technology, product, service, device, component, or part thereof, that -

(A) is primarily designed or produced for the purpose of circumventing protection afforded by a technological measure that effectively protects a right of a copyright owner under this title in a work or a portion thereof;

(B) has only limited commercially significant purpose or use other than to circumvent protection afforded by a technological measure that effectively protects a right of a copyright owner under this title in a work or a portion thereof; or

(C) is marketed by that person or another acting in concert with that person with that person's knowledge for use in circumventing protection afforded by a technological measure that effectively protects a right of a copyright owner under this title in a work or a portion thereof.

Issuing the taint warning when a derivative work is created is a right of the copyright owner(s); you have explained the embedded \0 as a "mere" technical measure designed to circumvent the taint warning. In my reading, that qualifies it as a violation of the paragraph above.

Part or all of 12 USC 1202 may also apply for similar reasons.

The DMCA may be unpopular, but it is still law.

Michael Poole (who is not a lawyer)

Quoted 6 lines · Michael Poole

Quoted 4 lines · Marc Boucher

I am not threatening anyone, only reminding folks that making unsubstantiated public allegations that unfairly damage a person or company's reputation is wrong and generally illegal.

Quoted 4 lines

Quoted 1 line

Marc

I do not think the allegations are unsubstantiated or unfair;

A number of allegations were clearly wrong. Some posters have even admitted or even criticized these factually incorrect accusations. Instead of wasting more time/energy arguing or litigating, we hope that this debate will now end peacefully and have helped to clarify and resolve problems.

Quoted 4 lines

on the
contrary, people have identified with specificity what is offensive and probably illegal. Might I remind you of 17 USC 1201(b)(1):

It is extremely ironic that the free software community who was so strongly opposed to the DMCA and considering it so evil now invokes it in such a far fetched manner (Alan Cox was probably cynical about this but you don't seem to be). It is also far from clear whether tainting and the MODULE_LICENSE() macro are a "technological measure that effectively protects" anything.

Again, our workaround is purely cosmetic, its side-effect on tainting totally unintentional, we are sorry that it has caused so much concern and we will be fixing it in good faith (even if it is a broken concept), while hoping that the underlying problems will be correctly resolved in future kernels/modutils.

Quoted 3 lines

Nope. The real objection was misleading people about the license of the module. That part was clearly wrong.

We did not mislead people. Our license terms are clear and openly stated in many places.
You could perhaps argue that we "mislead" a string comparison to fix a usability problem, but this kind of technique is very common today, especially under Linux where numerous interfaces are simulated.

Would
you pretend that things like Wine are wrong and misleading when making windows software believe that it runs under the real thing?

I am not threatening anyone, only reminding folks that making unsubstantiated public allegations that unfairly damage a person or company's reputation is wrong and generally illegal.

Look... you've admitted that what you did was wrong, you've apologized, and you're working on a solution. That's what everyone wants.

So why are you continuing to defend yourself?

Just get over it and move on.

Chris,

people should, before insulting us publicly or make unsubstantiated claims that we "lie" or engage in "illegal" actions, perhaps consult a lawyer, and simultaneously use the opportunity to enquire about the meaning of "slander".

I repeat, the \0 is purely a technical workaround, done without any mischievous intent.

Quoted 1 line · Jeff Garzik

DriverLoader significantly lowers that cost, while not providing an open source solution at all.

Ah, I see.... that makes a HUGE difference. Now I understand what the fuss
is all about. So, that is why everyone jumped on Marc Boucher's throat
trying to annihilate, humiliate, frighten by unsubstantiated allegations
and generally grind him into tiny specks of dust, at the same time falsely
pretending that all the fuss was only about that silly '\0' byte they left in their license string (I wish they knew better not to do that --- there are millions of ways to achieve what they want).

There are major chipset vendors out there who have managed to become market leaders while not providing any drivers for Linux.

But other vendors are also still releasing new native linux drivers, despite the availability of our solutions (Intel's project for Centrino at ipw2100.sourceforge.net is a great example).

This essentially proves that we are not removing the incentive to do proper native drivers, simply providing more options for 1) people who would otherwise be stuck or unable to use the full functionality of their machines under Linux right now, and 2) vendors who are not able to afford or justify the cost of developing native linux drivers due to the size of the current Linux desktop market. In general these vendors plan to one day produce native drivers, once the numbers make it possible.

However we also believe that pragmatically bringing in support for key

hardware (which currently cannot otherwise be easily handled in the traditional open-source approach) will benefit Linux, help it gain even more usefulness/acceptance, and make larger numbers of exposed people realize the natural advantages of open-source, then become contributors. On the other hand, forcing open-source down throats with impractical "tainting" schemes, scare tactics or other coercive methods

may achieve the opposite effect or turn Linux into just an ideological/political movement rather than the ubiquitous operating system it deserves to be.

On Thu, 29 Apr 2004 18:24:58 -0400
Marc Boucher <[email protected]> wrote:

Quoted 1 line

I think that Rik is right when saying that the key information that should be conveyed is who is responsible for providing support. The wording should be kept neutral, without negative connotation nor religious bias.

Perhaps others on this list are getting as tired as I am of your using the term "religious bias" as a negative connotation against people who
support and protect the open source nature of Linux. Maybe you could
at least pretend to respect the people who you supposedly apologized to.

Quite true. This isn't about religion. It's about people's right to choose how they license their the code they write.

This is about copyright law and our right to choose what others we can do with what we have copyrighted.

While I agree that there is a political agenda behind the GPL, we have to respect the rights of those who choose to apply it as a license to their creative works.

And furthermore, having a political agenda is not inherently wrong.

<snip>
Sure, but it is imho generally better to maintain reasonable balance and serve the "common good" rather than specific political interests. However that is purely personal opinion and everyone is free to choose/practice their political ideals, preferably without stepping onto others.

"Now loading a non GPL driver. Please consider supporting vendors that
provide open source drivers for their hardware. Your kernel will now be marked as tainted, all this means is that you should send any support requests to the author of this driver."

While we're on all of this, are we going to change "tained" to some other less alarmist word? Say there is a /proc file or some report that you can generate about the kernel that simply wants to indicate that the kernel contains closed-source modules, and we want to use a short, concise word like "tainted" for this. "An untrusted module has been loaded into this kernel" would be just a bit too long to qualify.

Hmmm... how about "untrusted"? Not sure...

Quoted 3 lines · Timothy Miller

While we're on all of this, are we going to change "tained" to some other less alarmist word? Say there is a /proc file or some report that you can generate about the kernel that simply wants to indicate that the kernel contains closed-source modules, and we want to use a short, concise word like "tainted" for this. "An untrusted module has been loaded into this kernel" would be just a bit too long to qualify.

Quoted 1 line

Hmmm... how about "untrusted"? Not sure...

"Unsupported" seems a good candidate to me. It describes the situation fairly well. Such a kernel is unsupported by the kernel community, and probably by the binary module vendor too. They tend to restrict support to their own module . . .

Quoted 11 lines · Helge Hafting

Quoted 9 lines · Timothy Miller

While we're on all of this, are we going to change "tained" to some other less alarmist word? Say there is a /proc file or some report that you can generate about the kernel that simply wants to indicate that the kernel contains closed-source modules, and we want to use a short, concise word like "tainted" for this. "An untrusted module has been loaded into this kernel" would be just a bit too long to qualify.

Hmmm... how about "untrusted"? Not sure...

Quoted 4 lines

"Unsupported" seems a good candidate to me. It describes the situation fairly well. Such a kernel is unsupported by the kernel community, and probably by the binary module vendor too. They tend to restrict support to their own module . . .

GOOD! And if people misunderstood "unsupported" to also mean that the VENDOR doesn't support it either, that's fine, because it's almost always true. :)

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Quoted 12 lines · Rik van Riel

Quoted 5 lines · Marc Boucher

At the same time, I think that the "community" should, without relinquishing its principles, be less eager before getting the facts to attack people and companies trying to help in good faith, and be more realistic when it comes to satisfying practical needs of ordinary users.

I wouldn't be averse to changing the text the kernel prints when loading a module with an incompatible license. If the text "$MOD_FOO: module license '$BLAH' taints kernel." upsets the users, it's easy enough to change it.

Quoted 5 lines

How about the following?

"Due to $MOD_FOO's license ($BLAH), the Linux kernel community cannot resolve problems you may encounter. Please contact $MODULE_VENDOR for support issues."

Sounds very "politically correct", but certainly more descriptive and less alarming.

In an enterprise, customers always come first.

In other cases, we have gladly submitted patches when we
encountered bugs and
could fix them. Had we known that the module fix was so simple, it would of course have been
submitted it to you in parallel.

Quoted 5 lines · Marc Boucher

In other cases, we have gladly submitted patches when we
encountered bugs and
could fix them. Had we known that the module fix was so simple, it would of course have been
submitted it to you in parallel.

Let me spell it out.

You deceived users by circumventing a check designed to tell them that their kernel was tainted. You deceived maintainers who receive "untainted" bug reports. In a way, you lied directly to the kernel
community: the module code is our agent in checking module licenses.

That you've been doing it for a while, or that you didn't spend significant time investigating alternatives or talking to the maintainer about your problem only compounds the damage. That I know and like you only heightens my disappointment.

Hence I stand by my original comment:

This shows a lack of integrity that I find personally repulsive.

Hope that clarifies,
Rusty.

Signature · 1 line

Anyone who quotes me in their signature is an idiot -- Rusty Russell

Dear Rusty,

We generally prefer to focus on making stuff work for users, rather than waste time arguing about controversial GPL politics.

That's why after the practical workaround was done we moved on to deal with more acute technical issues at the time and failed to properly discuss/follow up on the matter with you. Please accept my sincere personal apology for this.

I would like however to point out that part of the reason why people sometimes resort to such kludges is that some kernel maintainers have been rather reluctant to accommodate proprietary drivers which

unfortunately are a necessary real-world evil (Linus told me just a few days ago that he didn't care and to "go away" after we requested a clean solution to handle larger kernel stacks for "foreign" NDIS drivers in a way that could perhaps coexist with the new 4K stacks used by default in recent 2.6.6/fedora kernels).

Anyway, in an effort to reasonably resolve the \0 issue, to (hopefully) mutual satisfaction I propose that we update our drivers to explicitly set the tainted bit manually after they are loaded - perhaps via sysctl() or by running "echo 1 > /proc/sys/kernel/tainted" via {modules,modprobe}.conf, or simply changing the '\0' to ' ' in one of the modules' MODULE_LICENSE() macro, causing the kernel to be tainted upon load and the confusing messages to appear once instead of 5-6 times in a row. The latter approach seems simple and straightforward. Would it be acceptable to you as a compromise until your patch and hopefully something equivalent for 2.4 propagate to users?

Quoted 3 lines · Marc Boucher

Dear Rusty,
We generally prefer to focus on making stuff work for users, rather than waste time arguing about controversial GPL politics.

There is no need to _argue_ about the GPL if you don't want to. Just obey the terms. If you don't, then you're arguing.

To me, the argument above looks like "we concentrate on making
things work for our customers, not on obeying the laws." An argument frequently used by people you probably don't want to be compared with. You probably didn't intend it that way, but that what it looks like for those serious about the GPL.

Quoted 8 lines

That's why after the practical workaround was done we moved on to deal with more acute technical issues at the time and failed to properly discuss/follow up on the matter with you. Please accept my sincere personal apology for this.
I would like however to point out that part of the reason why people sometimes resort to such kludges is that some kernel maintainers have been rather reluctant to accommodate proprietary drivers which

Do not be surprised that people don't want to support your driver for free. Everything has a price. Business usually wants to be paid in money, kernel coders tend to want payment in the form of GPL'ed code.

Not wanting to pay in code _is_ ok, but then you get to deal with any trouble happening to any kernel running your module, because nobody else volunteers.

Quoted 6 lines

unfortunately are a necessary real-world evil (Linus told me just a few days ago that he didn't care and to "go away" after we requested a clean solution to handle larger kernel stacks for "foreign" NDIS drivers in a way that could perhaps coexist with the new 4K stacks used by default in recent 2.6.6/fedora kernels).

Well, sometimes design decisions simply doesn't go your way. There may indeed be no way to make Linus change his mind, so of course he tells you to go away. The same would happen if you tried to have microsoft make a design change _they_ don't want. You are lucky in the linux case though, kernel developers may not support your NDIS driver but you _can_ supply your own kernel patch (or a complete kernel) with big stacks. Right now the 4k stack is relatively new, so the patch for 8k is simple. In the future, there will probably be bigger pages and then your problem goes away. In the meantime you're allowed to maintain your own patch for whatever you can't get into mainline.

Quoted 9 lines

Anyway, in an effort to reasonably resolve the \0 issue, to (hopefully) mutual satisfaction I propose that we update our drivers to explicitly set the tainted bit manually after they are loaded - perhaps via sysctl() or by running "echo 1 > /proc/sys/kernel/tainted" via {modules,modprobe}.conf, or simply changing the '\0' to ' ' in one of the modules' MODULE_LICENSE() macro, causing the kernel to be tainted upon load and the confusing messages to appear once instead of 5-6 times in a row. The latter approach seems simple and straightforward. Would it be acceptable to you as a compromise until your patch and hopefully something equivalent for 2.4 propagate to users?

I believe you have to remove the \0 to operate legally (or release the full source under the GPL for real.) Your customer's problem is fixable though. Either by also changing the logging level
so the message doesn't go out on the console, or by patching the line with that printk() out of your customer's kernel. You can do this as a part of your install program. If it gets too hard, consider
supplying the customer with your own precompiled kernel.

Helge Hafting

Quoted 5 lines

I believe you have to remove the \0 to operate legally (or release the full source under the GPL for real.) Your customer's problem is fixable though. Either by also changing the logging level
so the message doesn't go out on the console, or by patching the line with that printk() out of your customer's kernel. You can do this as a part of your install program. If it gets too hard, consider
supplying the customer with your own precompiled kernel.

Thank you for the advice. However, if you knew our customers and understood their needs better you would realize that these are not feasible options.

Quoted 5 lines · Marc Boucher

Quoted 5 lines

I believe you have to remove the \0 to operate legally (or release the full source under the GPL for real.) Your customer's problem is fixable though. Either by also changing the logging level
so the message doesn't go out on the console, or by patching the line with that printk() out of your customer's kernel. You can do this as a part of your install program. If it gets too hard, consider
supplying the customer with your own precompiled kernel.

Quoted 1 line

Thank you for the advice. However, if you knew our customers and understood their needs better you would realize that these are not feasible options.

If your only "options" involve violating the GPL, then you cannot do business in this area.

"Someone won't let me release some code" isn't an excuse for breaking
the law.

Quoted 9 lines

I believe you have to remove the \0 to operate legally (or release the full source under the GPL for real.)
Your customer's problem is fixable though. Either by also changing the logging level
so the message doesn't go out on the console, or by patching the line with that printk() out of your customer's kernel.
You can do this as a part of your install program. If it gets too hard, consider
supplying the customer with your own precompiled kernel.

Thank you for the advice. However, if you knew our customers and understood their needs better you would realize that these are not feasible options.

Quoted 3 lines

Thank you for the advice. However, if you knew our customers and understood their needs better you would realize that these are not feasible options.

I think you have to live with multiple warning messages, at least until Rusty's patch propagate to mainline. It's not fatal.

Hi Helge,

Quoted 7 lines · Helge Hafting

Quoted 3 lines · Marc Boucher

Dear Rusty,
We generally prefer to focus on making stuff work for users, rather than waste time arguing about controversial GPL politics.

Quoted 2 lines

There is no need to _argue_ about the GPL if you don't want to. Just obey the terms. If you don't, then you're arguing.

We are not disobeying the terms nor is there anything in the GPL that prohibits specifically our workaround.

In fact, there is tons of GPL software out there that use even more blatant/questionable techniques to work around constraints imposed by commercial software, which illustrates the hypocrisy of some advocates.

Quoted 4 lines

To me, the argument above looks like "we concentrate on making
things work for our customers, not on obeying the laws." An argument frequently used by people you probably don't want to be compared with. You probably didn't intend it that way, but that what it looks like for those serious about the GPL.

You can try to make it look like whatever you like but this is not what I said.

Quoted 14 lines

Quoted 9 lines

That's why after the practical workaround was done we moved on to deal with more acute technical issues at the time and failed to properly discuss/follow up on the matter with you. Please accept my sincere personal apology for this.
I would like however to point out that part of the reason why people sometimes resort to such kludges is that some kernel maintainers have been rather reluctant to accommodate proprietary drivers which

Do not be surprised that people don't want to support your driver for free. Everything has a price. Business usually wants to be paid in money, kernel coders tend to want payment in the form of GPL'ed code.

Quoted 3 lines

Not wanting to pay in code _is_ ok, but then you get to deal with any trouble happening to any kernel running your module, because nobody else volunteers.

We are providing code as much as possible, without expecting free support, but are still getting flamed.

Quoted 8 lines

Quoted 6 lines

unfortunately are a necessary real-world evil (Linus told me just a few days ago that he didn't care and to "go away" after we requested a clean solution to handle larger kernel stacks for "foreign" NDIS drivers in a way that could perhaps coexist with the new 4K stacks used by default in recent 2.6.6/fedora kernels).

Quoted 10 lines

Well, sometimes design decisions simply doesn't go your way. There may indeed be no way to make Linus change his mind, so of course he tells you to go away. The same would happen if you tried to have microsoft make a design change _they_ don't want. You are lucky in the linux case though, kernel developers may not support your NDIS driver but you _can_ supply your own kernel patch (or a complete kernel) with big stacks. Right now the 4k stack is relatively new, so the patch for 8k is simple. In the future, there will probably be bigger pages and then your problem goes away. In the meantime you're allowed to maintain your own patch for whatever you can't get into mainline.

Kernel patching and recompilation is not a practical option for most average linux users, who are unable or unwilling do it, because it is a long and difficult procedure.

We aim to provide professional products that are straightforward to install and just work out of the box, with standard distributions, not custom kernel patches.

Quoted 10 lines

Quoted 9 lines

Anyway, in an effort to reasonably resolve the \0 issue, to (hopefully) mutual satisfaction I propose that we update our drivers to explicitly set the tainted bit manually after they are loaded - perhaps via sysctl() or by running "echo 1 > /proc/sys/kernel/tainted" via {modules,modprobe}.conf, or simply changing the '\0' to ' ' in one of the modules' MODULE_LICENSE() macro, causing the kernel to be tainted upon load and the confusing messages to appear once instead of 5-6 times in a row. The latter approach seems simple and straightforward. Would it be acceptable to you as a compromise until your patch and hopefully something equivalent for 2.4 propagate to users?

Quoted 5 lines

I believe you have to remove the \0 to operate legally (or release the full source under the GPL for real.) Your customer's problem is fixable though. Either by also changing the logging level
so the message doesn't go out on the console, or by patching the line with that printk() out of your customer's kernel. You can do this as a part of your install program. If it gets too hard, consider
supplying the customer with your own precompiled kernel.

Thank you for the advice. However, if you knew our customers and understood their needs better you would realize that these are not feasible options.

We generally prefer to focus on making stuff work for users, rather than waste time arguing about controversial GPL politics.

I would like however to point out that part of the reason why people sometimes resort to such kludges is that some kernel maintainers have been rather reluctant to accommodate proprietary drivers which unfortunately are a necessary real-world evil

Quoted 2 lines · Marc Boucher

We generally prefer to focus on making stuff work for users, rather than waste time arguing about controversial GPL politics.

Well, as one of your customers (I am a paid/licensed user of your Conexant modem drivers for my Dell D800) I am completely turned off by this. I use a myriad of different binary drivers on various Linux systems, things like the NVidia binary driver, EMC PowerPath, VMware binary module, etc. EMC PowerPath compares well to your example as it consist of multiple modules and each one spits out a message. EMC simply used their documentation to tell the user that these messages means that the kernel can no longer be supported by the Linux community, however, they can be safely ignored.

Quoted 4 lines

I would like however to point out that part of the reason why people sometimes resort to such kludges is that some kernel maintainers have been rather reluctant to accommodate proprietary drivers which unfortunately are a necessary real-world evil

In my opinion your actions also represent a real-world evil. As a user I'm reluctant to use proprietary drivers and certainly don't expect the ones that I am forced to used to lie about that fact and try to pretend to be GPL when they are not.

After reading this I realized that I myself have probably
reported kernel BUG's while your drivers were loaded, not realizing that my kernel was really tainted because it didn't report that fact. Who knows how many other users may have done the same thing?

You seem to think that acceptance of Linux is somehow more important that the GPL. In my opinion it's exactly the opposite, acceptance and recognition of the the importance of the GPL and the rights it gives you is more important than the acceptance of Linux.

If the "real-world" forces you to do something
that gives up those rights (loading a binary module) the kernel should definitely make the user aware.

Later,
Tom

Quoted 5 lines

If the "real-world" forces you to do something
that gives up those rights (loading a binary module) the kernel should definitely
make the user aware.

The important part here is making the user aware, which we have clearly done.

Marc

No, the important thing is to admit when you were *wrong* and fix the problem.

But many people suffer from inability to admit a mistake (like GWB).

The problem goes both ways. Non-standard, unreported and hard to detect kernel patches have caused numerous users to report alleged driver bugs to us. You wouldn't know how much time and resources these things cost us.

Hi everyone,

Quoted 3 lines · Carl-Daniel Hailfinger

Hi,

LinuxAnt offers binary only modules without any sources.

Not true. Linuxant modules come with full source for operating-system specific code.

Quoted 5 lines

To circumvent our
MODULE_LICENSE checks LinuxAnt has inserted a "\0" into their declaration:

MODULE_LICENSE("GPL\0for files in the \"GPL\" directory; for others, only LICENSE file applies");

Quoted 4 lines · Paulo Marques

The way I see it, they know a C string ends with a '\0'. This is like saying that a English sentence ends with a dot. If they wrote "GPL\0" they are effectively saying that the license *is* GPL period.

Quoted 1 line

So, where the source code? :)

Unfortunately Linuxant cannot release the source for the proprietary portions [...]

Quoted 7 lines · Willy Tarreau

[...]

Quoted 4 lines

The attached patch blacklists all modules having "Linuxant" or "Conexant" in their author string. This may seem a bit broad, but AFAIK both companies never have released anything under the GPL and have a strong history of binary-only modules.

Quoted 1 line

What would be smarter would be to try to understand why they do this.

Exactly. Linuxant's intent is NOT to circumvent any license checks (see below for why this specific workaround was put in) which would be unnecessary since the drivers in question do not use any GPL_ONLY functions, as far as I know.

Quoted 1 line

At the moment, it seems to me that their only problem is to taint the kernel.

Actually, we also have no desire nor purpose to prevent tainting. The purpose

of the workaround is to avoid repetitive warning messages generated when multiple modules belonging to a single logical "driver" are loaded (even when a module is only probed but not used due to the hardware not being present). Although the issue may sound trivial/harmless to people on the lkml, it was a frequent cause of confusion for the average person.

Other Linuxant drivers (like DriverLoader and Riptide) do not need nor use this workaround because they are not composed of multiple modules and one set of warning messages is usually bearable.

Quoted 4 lines

Why ? I don't this that any old modutils/module-utils found in any distros don't load properly such modules. So perhaps they only want not to taint the kernel because it appears dirty to their customers who will not receive any more support from LKML. So perhaps what we really need is to add a new

Quoted 8 lines

MODULE_SUPPORT field stating where to get support from in case of bugs, oopses or panics on a tainted kernel. Thus, the module author would be able to insert something such as "[email protected]" which will be displayed on each oops/panic/etc... Even if this is a long list because the customer uses connexant, nvidia, checkpoint and I don't know what, at least he will get 3 email addresses for his support. And it might reassure these authors to know that the customer will ask them before asking us with our automatic replies "unload your binary modules...".

Linuxant would very much welcome such steps to improve the current situation, and is willing to eliminate workarounds once they are no longer necessary.

Quoted 3 lines · Carl-Daniel Hailfinger

Hi,

LinuxAnt offers binary only modules without any sources.

Not true. Linuxant modules come with full source for operating-system specific code.