--- linux-2.6.5/kernel/module.c~ 2004-04-04 05:37:37.000000000 +0200
+++ linux-2.6.5/kernel/module.c 2004-04-27 01:24:14.000000000 +0200
@@ -34,6 +34,7 @@
#include <linux/vermagic.h>
#include <linux/notifier.h>
#include <linux/stop_machine.h>
+#include <linux/string.h>
#include <asm/uaccess.h>
#include <asm/semaphore.h>
#include <asm/pgalloc.h>
@@ -1112,6 +1113,14 @@
}
}
+static inline int license_author_is_not_blacklisted(const char *author)
+{
+ /* LinuxAnt is known to ship non-GPL modules with license=="GPL"
+ to cheat on our checks. Stop them from doing that. */
+ return !(strstr(author, "Linuxant")
+ || strstr(author, "Conexant"));
+}
+
static inline int license_is_gpl_compatible(const char *license)
{
return (strcmp(license, "GPL") == 0
@@ -1121,12 +1130,16 @@
|| strcmp(license, "Dual MPL/GPL") == 0);
}
-static void set_license(struct module *mod, const char *license)
+static void set_license(struct module *mod, const char *license,
+ const char *author)
{
if (!license)
license = "unspecified";
+ if (!author)
+ author = "unspecified";
- mod->license_gplok = license_is_gpl_compatible(license);
+ mod->license_gplok = license_is_gpl_compatible(license)
+ && license_author_is_not_blacklisted(author);
if (!mod->license_gplok) {
printk(KERN_WARNING "%s: module license '%s' taints kernel.\n",
mod->name, license);
@@ -1466,7 +1479,8 @@
module_unload_init(mod);
/* Set up license info based on the info section */
- set_license(mod, get_modinfo(sechdrs, infoindex, "license"));
+ set_license(mod, get_modinfo(sechdrs, infoindex, "license"),
+ get_modinfo(sechdrs, infoindex, "author"));
/* Fix up syms, so that st_value is a pointer to location. */
err = simplify_symbols(sechdrs, symindex, strtab, versindex, pcpuindex,
Carl-Daniel Hailfinger wrote:
>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!
Take care, Gilles
--
If you don't live for something you'll die for nothing!
On Tue, 27 Apr 2004, Carl-Daniel Hailfinger wrote:
>
> 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.
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.
That should make it pretty easy to parse the .modinfo section too.
Linus
On Tue, 27 Apr 2004, Gilles May wrote:
> Carl-Daniel Hailfinger wrote:
>
> >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!
Then they should list themselves as proprietory, there will be no problem
loading them in that case. No need to tell fibs.
On Tue, Apr 27, 2004 at 04:09:36AM +0200, Carl-Daniel Hailfinger wrote:
> 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");
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 :-)
> 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...
Regards,
Willy
On Tue, 2004-04-27 at 14:31, Linus Torvalds wrote:
> 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.
Cute, but breaks the "modinfo" tool unfortunately. I'd prefer not to do
that. Since they want to circumvent this, almost anything we want to do
is a waste of time.
Rusty.
Name: Stop most obvious abuse of MODULE_LICENSE
Status: Tested on 2.6.6-rc2-bk4
Arms race forces bloat upon module users.
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
--- .31262-linux-2.6.6-rc2-bk4/include/linux/module.h 2004-04-22 08:03:55.000000000 +1000
+++ .31262-linux-2.6.6-rc2-bk4.updated/include/linux/module.h 2004-04-27 15:52:19.000000000 +1000
@@ -16,6 +16,9 @@
#include <linux/kmod.h>
#include <linux/elf.h>
#include <linux/stringify.h>
+#include <linux/init.h>
+#include <linux/kernel.h>
+#include <linux/compiler.h>
#include <asm/local.h>
#include <asm/module.h>
@@ -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. */
+#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
--
Anyone who quotes me in their signature is an idiot -- Rusty Russell
Willy Tarreau wrote:
>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...
>
>
And they will put [email protected](.org) there :-)
You never know...
--
GJ
On Tue, 2004-04-27 16:04:06 +1000, Rusty Russell <[email protected]>
wrote in message <1083045844.2150.105.camel@bach>:
> On Tue, 2004-04-27 at 14:31, Linus Torvalds wrote:
> 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
> --- .31262-linux-2.6.6-rc2-bk4/include/linux/module.h 2004-04-22 08:03:55.000000000 +1000
> +++ .31262-linux-2.6.6-rc2-bk4.updated/include/linux/module.h 2004-04-27 15:52:19.000000000 +1000
> @@ -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. */
> +#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?
MfG, JBG
--
Jan-Benedict Glaw [email protected] . +49-172-7608481
"Eine Freie Meinung in einem Freien Kopf | Gegen Zensur | Gegen Krieg
fuer einen Freien Staat voll Freier B?rger" | im Internet! | im Irak!
ret = do_actions((curr | FREE_SPEECH) & ~(NEW_COPYRIGHT_LAW | DRM | TCPA));
Zwane Mwaikambo wrote:
> On Tue, 27 Apr 2004, Gilles May wrote:
>
>
>>Carl-Daniel Hailfinger wrote:
>>
>>
>>>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!
If you had read the patch instead of complaining, you would have seen that
the only change is to taint the kernel for those modules.
> Then they should list themselves as proprietory, there will be no problem
> loading them in that case. No need to tell fibs.
Indeed.
Carl-Daniel
--
http://www.hailfinger.org/
Jan-Benedict Glaw wrote:
> On Tue, 2004-04-27 16:04:06 +1000, Rusty Russell <[email protected]>
> wrote in message <1083045844.2150.105.camel@bach>:
>
>>On Tue, 2004-04-27 at 14:31, Linus Torvalds wrote:
>>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
>>--- .31262-linux-2.6.6-rc2-bk4/include/linux/module.h 2004-04-22 08:03:55.000000000 +1000
>>+++ .31262-linux-2.6.6-rc2-bk4.updated/include/linux/module.h 2004-04-27 15:52:19.000000000 +1000
>>@@ -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. */
>>+#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?
# objdump -t forcedeth.ko |grep '\.modinfo'|sort
00000000 l d .modinfo 00000000
00000000 l O .modinfo 0000000c __mod_license1618
00000020 l O .modinfo 00000036 __mod_description1617
00000060 l O .modinfo 00000031 __mod_author1616
000000a0 l O .modinfo 00000047 __mod_max_interrupt_work1614
00000100 l O .modinfo 0000002b __mod_alias58
00000140 l O .modinfo 0000002b __mod_alias57
00000180 l O .modinfo 0000002b __mod_alias56
000001ab l O .modinfo 00000009 __module_depends
000001c0 l O .modinfo 0000002d __mod_vermagic5
Wouldn't it be possible to check the length info from the module symbol
table and compare it with the strlen for the corresponding symbol? If that
gives us a mismatch, refuse to load the module (or mark it as
proprietary). Additionally, check that nothing but NULLs is used as
padding between the strings.
This way, the module format doesn't change, but we can do additional
verification in the loader.
Regards,
Carl-Daniel
--
http://www.hailfinger.org/
Carl-Daniel Hailfinger wrote:
>
> This way, the module format doesn't change, but we can do additional
> verification in the loader.
>
I agree with Rusty Russell. Anything that we do can be circunvented.
If they are really into it, they can build a small tool to change the symbol
information from the module.
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? :)
--
Paulo Marques - http://www.grupopie.com
"In a world without walls and fences who needs windows and gates?"
On Tue, 2004-04-27 13:59:48 +0100, Paulo Marques <[email protected]>
wrote in message <[email protected]>:
> Carl-Daniel Hailfinger wrote:
> >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? :)
That's another (quite amusing:) point of view. Anybody willing to ask a
lawyer?
MfG, JBG
--
Jan-Benedict Glaw [email protected] . +49-172-7608481
"Eine Freie Meinung in einem Freien Kopf | Gegen Zensur | Gegen Krieg
fuer einen Freien Staat voll Freier B?rger" | im Internet! | im Irak!
ret = do_actions((curr | FREE_SPEECH) & ~(NEW_COPYRIGHT_LAW | DRM | TCPA));
Jan-Benedict Glaw <[email protected]> said on Tue, 27 Apr 2004 15:12:57 +0200:
>
> --+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]>:
> > Carl-Daniel Hailfinger wrote:
> > >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
> > 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?
In the wonderful Good Ol USofA, I think it would be trivial to apply
the DMCA: A character string following the appropriate convention
(null termination) is a protection mechanism.
Breaking that convention is a cicumvention device.
If it can work for XOR, and gets someone thrown in prison for 12
months, surely it will work for null termination?
Pretty clear cut, so, who's going to write this lovely company a
letter/send in the land-sharks (someone better, otherwise companies
will realise very quickly that they can stamp all over us with no
retribution[1])? I don't own any relevant copyright, unfortunately.
[1] Has anything been done about the other members on the hall or
shame?
--
TimC -- http://astronomy.swin.edu.au/staff/tconnors/
HANDLE WITH EXTREME CARE: This Product Contains Minute Electrically
Charged Particles Moving at Velocities in Excess of Five Hundred
Million Miles Per Hour.
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.
On Tue, Apr 27, 2004 at 09:43:12AM -0400, Albert Cahalan wrote:
> 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.
>
I did, you're on slashdot
http://developers.slashdot.org/article.pl?sid=04/04/27/1435217
--
Jon
http://tesla.resnet.mtu.edu
The only meaning in life is the meaning you create for it.
Hi everyone,
On Tue, Apr 27, 2004 at 04:09:36AM +0200, Carl-Daniel Hailfinger wrote:
> Hi,
>
> LinuxAnt offers binary only modules without any sources.
Not true. Linuxant modules come with full source for operating-system specific
code.
> 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");
Paulo Marques said:
> 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? :)
Unfortunately Linuxant cannot release the source for the proprietary portions
of the Conexant HCF and HSF softmodem drivers, because it does not own these
parts and the terms under which they have been licensed from Conexant prohibit
it.
We have tried to attenuate the inconvenience of these restrictions by isolating
the proprietary code and releasing source for all operating-system specific
code, so that people can rebuild the modules for any kernel.
I believe that this is a fair compromise. Otherwise, it wouldn't be possible to
use Conexant softmodems under Linux right now, since 1) the hardware is quite
obscure, 2) no-one has fully implemented the modulations (such as V.92 etc..)
and related protocols (V.44/V.42[bis]) for free, because this stuff is quite
complex and involves many patents. Before blaming Conexant for protecting their
intellectual property, one should note that as far as I know none of the
other softmodem manufacturers (Lucent/Agere, SmartLink, Motorola, PC-Tel etc..)
have ever accepted to give the source code away for their proprietary
implementations of modem modulations either.
Willy Tarreau <willy () w ! ods ! org> wrote:
> 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 :-)
>
> > 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.
>
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.
> 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.
> 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...".
Linuxant would very much welcome such steps to improve the current situation,
and is willing to eliminate workarounds once they are no longer necessary.
Sincerely,
Marc
--
Marc Boucher
President
Linuxant inc.
http://www.linuxant.com
Hi Paulo,
On Tue, Apr 27, 2004 at 13:59:48 +0100, Paulo Marques wrote:
> 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? :)
IANAL, but I think the copyright holder is not bound to the GPL and can
supply what ever he wants, just the licensee is required to make the
source available.
J?rgen
>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
Hi Adam,
On Apr 27, 2004, at 1:25 PM, Adam Jaskiewicz wrote:
>
>> 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.
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..
Regards
Marc
--
Marc Boucher
President
Linuxant inc.
http://www.linuxant.com
>
> --
> Adam Jaskiewicz
>
Marc Boucher wrote:
> On Apr 27, 2004, at 1:25 PM, Adam Jaskiewicz wrote:
>> 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...
Chris
On Tue, 27 Apr 2004, Chris Friesen wrote:
> Marc Boucher wrote:
>
> > On Apr 27, 2004, at 1:25 PM, Adam Jaskiewicz wrote:
>
> >> 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?)
Grzegorz Kulewski
On Apr 27, 2004, at 1:46 PM, Chris Friesen wrote:
> Marc Boucher wrote:
>
>> On Apr 27, 2004, at 1:25 PM, Adam Jaskiewicz wrote:
>
>>> 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.
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.
Marc
--
Marc Boucher
President
Linuxant inc.
http://www.linuxant.com
Grzegorz Kulewski wrote:
> 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.
Chris
Marc Boucher wrote:
>
>
> On Apr 27, 2004, at 1:46 PM, Chris Friesen wrote:
>> 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.
> 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.
Chris
On Tue, 27 Apr 2004 19:53:39 +0200, Grzegorz Kulewski said:
> 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.
Instead of printing module taint messages to the screen, why couldn't
they just
be written to syslog? Then it wouldn't matter if there were several
taint
messages. For example, I know my nVidia driver taints the kernel, I
don't need
to see that message over and over again.
Marc Boucher <marc () linuxant ! com> wrote:
> 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.
On Martes, 27 de Abril de 2004 20:54, [email protected] wrote:
> On Tue, 27 Apr 2004 19:53:39 +0200, Grzegorz Kulewski said:
> > 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?
> Other than that, there's probably no reason to complain on a re-taint.
On Tue, 27 Apr 2004, Jorge Bernal (Koke) wrote:
> On Martes, 27 de Abril de 2004 20:54, [email protected] wrote:
> > On Tue, 27 Apr 2004 19:53:39 +0200, Grzegorz Kulewski said:
> > > 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).
Grzegorz Kulewski
On Tue, 27 Apr 2004, Steve Lee wrote:
> Instead of printing module taint messages to the screen, why couldn't
> they just
> be written to syslog? Then it wouldn't matter if there were several
> taint
> messages. For example, I know my nVidia driver taints the kernel, I
> don't need
> to see that message over and over again.
Yes, that is exactly what it was a few years ago when I checked (and
probably still is) --- a bug in modutils which needs to be fixed as those
messages are too annoying and aggressive. It should be changed to be made
possible to disable them via /etc/syslog.conf because a normal user
wouldn't have a clue how to disable them otherwise.
Those kind of "kernel messages" should not be seen except when a user
wants to prepare a bug report and send it to linux-kernel. Then he ought
to check dmesg and discover that he is in fact running binary only modules
and also he will discover the support email address and send his report
there instead of here.
Generally, breaking Unix philosophy with such aggressive messages
bypassing standard interfaces is what normally happens in commercial
Unix-es, which are driven by "market requirements" i.e. dictated by people
who have no clue what proper Unix is or should be. So, this part of
modutils is, ironically, very much anti-Linux and "commercial Unix"-like,
although it tries to look precisely opposite. It should be fixed, imho.
I even think that the whole "EXPORT_SYMBOL" vs "EXPORT_SYMBOL_GPL" thing
is moot and anti-freedom because it violates ability of hackers (even if
they happen to work for companies producing binary-only modules, that's
irrelevant) to make proper technical design decisions and instead obey
some person's idea of what is a "good" or "bad" caller of his API. But so
be it, since that's the way Linus and others prefers Linux to be.
Kind regards
Tigran
On Martes, 27 de Abril de 2004 21:16, Grzegorz Kulewski wrote:
>
> 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
and/or
using the /proc/tainted interface to enable/disable loading of tainted
modules.
So that are 2 different things: a) how do we handle the tainted mods
notifications and b) if we let the user decide if he/she wants tainted
modules to be "blocked"
On Tue, 27 Apr 2004, Marc Boucher wrote:
> A lot of users don't read them though, so a proper fix remains
> necessary..
Looking at some very very old scripts I wrote for clean loading binary
modules I see some code to fix this:
dmesg -n 1
# do the module loading
dmesg -n 6
But, it assumes the syslog/klog is not running (well, you can temporarily
stop it) and also it starts minilogd temporarily and then kills it and
restarts syslog/klog.
Try it and see if it works for you. About 2-3 years ago it definitely
worked :)
Kind regards
Tigran
On Tue, 27 Apr 2004 21:41:51 +0200, "Jorge Bernal (Koke)" said:
> 2 ideas:
>
> Printing if the tainted module is loaded or unloaded
We already have a message when it's loading, and a message on unload is
superfluous - if I insmod the NVidia driver and then unload it, the kernel is
still tainted by it, because it had a chance to mangle memory while it was
loaded.
And yes, sometimes the damage can be hiding for a LONG time - I know I've seen
bug reports on the list that involved "module A dorked a pointer which wasn't
noticed for 3 days until module B tried to...."
Would the attached strawman patch make people happ(y|ier)?
--- linux-2.6.6-rc2-mm2/kernel/module.c.orig 2004-04-27 09:56:22.000000000 -0400
+++ linux-2.6.6-rc2-mm2/kernel/module.c 2004-04-27 16:16:59.764158885 -0400
@@ -1131,7 +1131,7 @@ static void set_license(struct module *m
mod->license_gplok = license_is_gpl_compatible(license);
if (!mod->license_gplok) {
- printk(KERN_WARNING "%s: module license '%s' taints kernel.\n",
+ printk(KERN_NOTICE "%s: module license '%s' taints kernel.\n",
mod->name, license);
tainted |= TAINT_PROPRIETARY_MODULE;
}
Chris Friesen wrote:
> Grzegorz Kulewski wrote:
>
>> 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.
>
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.
Chris Friesen wrote:
> Marc Boucher wrote:
>
>>
>>
>> On Apr 27, 2004, at 1:46 PM, Chris Friesen wrote:
>
>
>>> 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.
>
>> 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.
Even that is a violation of the GPL. You can't link closed-source code
with GPL code and release it legally.
Binary-only modules are technically a violation of the GPL, but kernel
developers have chosen to allow it under tight constraints.
But the building and releasing ANYTHING which is made up of GPL code and
closed-source code and released as an atomic unit (not merely agregated
on the same medium) is illegal.
On Tue, 27 Apr 2004, Timothy Miller wrote:
> Chris Friesen wrote:
> > Grzegorz Kulewski wrote:
> >> 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.
>
> 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.
Ok, so we can write big and fat KERNEL WAS JUST TAINTED warning on first
tainting module load and then issue only small notices to the log...
Grzegorz Kulewski
>>>>> "PM" == Paulo Marques <[email protected]> writes:
PM> The way I see it, they know a C string ends with a '\0'. This is like
PM> saying that a English sentence ends with a dot. If they wrote "GPL\0"
PM> they are effectively saying that the license *is* GPL period.
PM> So, where the source code? :)
I do not know if their having "GPL\0" in their object makes it
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 :).
On Tue, 27 Apr 2004 14:17:06 PDT, Junio C Hamano said:
> 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 :).
Remember however that it's *really* difficult to create a kernel module
that's not a derivative work of the kernel - and for *that* side of
the fence, they are indeed a licensee of the kernel source tree, not
the copyright holder of their code....
On Mon, 26 Apr 2004, Linus Torvalds wrote:
> On Tue, 27 Apr 2004, Carl-Daniel Hailfinger wrote:
> >
> > 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.
>
> 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.
>
> That should make it pretty easy to parse the .modinfo section too.
>
> Linus
Its a joke anyway gcc3.x allows this to happen. As i posted on the
gcc mailinglist some time ago :
"Re: C Code mutilation by using gcc-3.3.x"
http://gcc.gnu.org/ml/gcc/2004-02/msg00313.html :
-------------------------------------------------
"
>
> On Feb 4, 2004, at 12:01, Robert M. Stockmann wrote:
> > Whats going on here?
>
> gcc 3.x supports C99 style of initializing of structors which was not
> supported in 2.95.3.
To be more specific about what i am complaining about, here's a
error message i get when doing ./configure inside ntfsprogs-1.8.4 :
checking version of gcc... 2.95.3, bad
configure: error: Please upgrade your gcc compiler to gcc-2.96+ or gcc-3+
version! Earlier compiler versions will NOT work as these do not support
unnamed/annonymous structures and unions which are used heavily in linux-ntfs.
[jackson:stock]:(~/src/ntfsprogs-1.8.4)$
Aha, unnamed/annonymous structures and unions .....
Well thats briljant... in 2 years time all Open Source code will be unnamed
and anonymous in the form of propiatary .o modules, and Linus will still
be happy to deliver his /usr/src/linux/kernel subtree of the Linux
kernel source. Quite funny to see Open Source evolving by implementing
"modern" C compilers like gcc-3.x.
BTW. inside the Linux kernel source the Changes file explicitly states :
"The recommended compiler for the kernel is gcc 2.95.x (x >= 3), and it
should be used when you need absolute stability. You may use gcc 3.0.x
instead if you wish, although it may cause problems. Later versions of gcc
have not received much testing for Linux kernel compilation, and there are
almost certainly bugs (mainly, but not exclusively, in the kernel) that
will need to be fixed in order to use these compilers. In any case, using
pgcc instead of egcs or plain gcc is just asking for trouble."
-------------------------------------------------------------------------
It surely looks like the unnamed and annonymous powers of gcc-3.x finally
have reached the linux-kernel list. If you allow trash into your
gcc compilers, the resulting code and binary's are in the same
way affected.
regards,
Robert
--
Robert M. Stockmann - RHCE
Network Engineer - UNIX/Linux Specialist
crashrecovery.org [email protected]
Sad state of affairs.
I don't know anything on the guru's side of coding and stuff in the
kernel, but I do know enough to say the module in question WAS coded
to give a false impression (or true, if you like) to the kernel so
that it supressed the 'tainted' kernel warnings.
But surely in an open source project [any project], tainted code
needs to be highlighted? What else is in there, or not? A GNU/Linux
platform needs to be told when a unknown and unvetted binary loads -
who can prove what it does otherwise, and therefore the onus is on
the user?
Maybe binary suppliers need to speak to kernel crew first on what
they need to do to get around these issues legally before it is
'discovered' and appears to be an attempt get around safeguards in
place.
Nick
--
"When you're chewing on life's gristle,
Don't grumble, Give a whistle..."
On Tue, 27 Apr 2004, Michael Poole wrote:
> "Robert M. Stockmann" <[email protected]> writes:
>
> [snip]
> > To be more specific about what i am complaining about, here's a
> > error message i get when doing ./configure inside ntfsprogs-1.8.4 :
> >
> > checking version of gcc... 2.95.3, bad
> > configure: error: Please upgrade your gcc compiler to gcc-2.96+ or gcc-3+
> > version! Earlier compiler versions will NOT work as these do not support
> > unnamed/annonymous structures and unions which are used heavily in linux-ntfs.
> > [jackson:stock]:(~/src/ntfsprogs-1.8.4)$
> >
> > Aha, unnamed/annonymous structures and unions .....
>
> Please keep rants about applications' coding style where they belong:
> off the linux-kernel list. If you bothered to READ what Linus wrote,
> you would see that the structure being defined has a name -- in fact,
> gcc requires that, since the structure would be defined at file scope
> rather than inside another structure or union.
>
> Michael
Hi Michael,
look i have made complaints about gcc-3.x some time ago, on the gcc
mailinglist. Also there they put my opinions aside, with arguments
like any powerfull feature can be used in a bad and in a good way.
The powerfull feature here is the C99 coding style, which allows for
unnamed and anonymous structures and unions. Don't kill our C99 cause it
can do bad things. Of course not.
However when dealing with OEM hardware vendors, which have signed contracts
with Microsoft about windows drivers, i think we cannot allow these same
OEM hardware vendors to introduce binary only drivers of unknown quality into
the linux kernel. Its exactly these events which give the Linux kernel, or
even Linux in general, give a bad reputation. Think about rants like this :
"The Promise FastTrak TX4000 IDE-RAID controller works perfect inside Windows,
but inside Linux i even lost my data."
The Promise Fasttrak issue i discussed here :
http://gcc.gnu.org/ml/gcc/2004-02/msg00293.html
If every major hardware vendor (like e.g. Adaptec, LSI Logic) will change
its policy, to implement its drivers as semi- binary only kernel modules, like
Promise did with its FastTrak line of controllers, like in the example above,
the Open Source lable of the linux kernel can be placed into the computer
museum. Isn't that exactly what a certain Redmond software company wants
to achieve?
Cheers,
Robert
--
Robert M. Stockmann - RHCE
Network Engineer - UNIX/Linux Specialist
crashrecovery.org [email protected]
On Wed, Apr 28, 2004 at 12:59:23AM +0200, Robert M. Stockmann wrote:
> look i have made complaints about gcc-3.x some time ago, on the gcc
> mailinglist. Also there they put my opinions aside, with arguments
> like any powerfull feature can be used in a bad and in a good way.
> The powerfull feature here is the C99 coding style, which allows for
> unnamed and anonymous structures and unions. Don't kill our C99 cause it
> can do bad things. Of course not.
> If every major hardware vendor (like e.g. Adaptec, LSI Logic) will change
> its policy, to implement its drivers as semi- binary only kernel modules, like
> Promise did with its FastTrak line of controllers, like in the example above,
> the Open Source lable of the linux kernel can be placed into the computer
> museum. Isn't that exactly what a certain Redmond software company wants
> to achieve?
What the hell do these two paragraphs have to do with each other?
On Wed, 2004-04-28 at 02:58, Marc Boucher wrote:
> 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
@@ -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;
--
Anyone who quotes me in their signature is an idiot -- Rusty Russell
Marc Boucher wrote:
> Hi everyone,
>
> On Tue, Apr 27, 2004 at 04:09:36AM +0200, Carl-Daniel Hailfinger wrote:
>
>>Hi,
>>
>>LinuxAnt offers binary only modules without any sources.
>
>
> Not true. Linuxant modules come with full source for operating-system specific
> code.
As somebody else already asked: Where is that source?
>>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");
>
>
>
> Paulo Marques said:
>
>>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? :)
>
>
> Unfortunately Linuxant cannot release the source for the proprietary portions
> [...]
Then why do you claim the license of the proprietary portions is GPL?
> Willy Tarreau <willy () w ! ods ! org> wrote:
>
>> [...]
>>
>>>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.
>
> 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.
As far as you know. Can we assume you didn't bother to check?
>>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
Then why the fuck did you prevent tainting this way?
> 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.
"Repetitive messages". The way you did it, there are no messages at all.
If you had wanted to avoid repetitive messages, you could have
- asked on linux-kernel to not output further warnings if the kernel is
already tainted
- given at least one module a non-GPL MODULE_LICENSE.
So you are nothing but a liar caught red-handed. And such a bad liar at that.
> 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.
>
>
>>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...".
>
>
> Linuxant would very much welcome such steps to improve the current situation,
> and is willing to eliminate workarounds once they are no longer necessary.
Let me translate that.
"Linuxant has willfully screwed kernel developers. If they want Linuxant
to stop, they first have to do the following things: [long list]"
Since your modules are out there, we need a way to mark them as
proprietary. My patch did exactly that and nothing else.
Carl-Daniel
--
http://www.hailfinger.org/
On Tue, 27 Apr 2004, Tim Hockin wrote:
> On Wed, Apr 28, 2004 at 12:59:23AM +0200, Robert M. Stockmann wrote:
> > look i have made complaints about gcc-3.x some time ago, on the gcc
> > mailinglist. Also there they put my opinions aside, with arguments
> > like any powerfull feature can be used in a bad and in a good way.
> > The powerfull feature here is the C99 coding style, which allows for
> > unnamed and anonymous structures and unions. Don't kill our C99 cause it
> > can do bad things. Of course not.
>
> > If every major hardware vendor (like e.g. Adaptec, LSI Logic) will change
> > its policy, to implement its drivers as semi- binary only kernel modules, like
> > Promise did with its FastTrak line of controllers, like in the example above,
> > the Open Source lable of the linux kernel can be placed into the computer
> > museum. Isn't that exactly what a certain Redmond software company wants
> > to achieve?
>
> What the hell do these two paragraphs have to do with each other?
>
C99 coding style, more specific the use of unnamed and anonymous structures
and unions, allows the kernel programmer to interface, read glue, binary only
driver modules to interface with any linux kernel source tree.
Using this feature one can link and merge any binary only module.o to any
kernel source version of your choice. In this way, typically, a OEM vendor,
releases a semi open-source link kit, which also contains binary only
components, once. This semi open source link-kit will then work with any 2.6.x
or 2.4.2x kernel source tree.
The needed header files, which need to be read by the gcc compiler, contain
unnamed and annonymizes structures and unions. In the worst case scenario,
only the name of used variables are given and no info about variable type or
size are inside these headers files. gcc-2.95.3 fails to succesfully link these
semi open-source link-kits, and gcc-3.x (which supports C99) of course has
no problems doing this.
Robert
--
Robert M. Stockmann - RHCE
Network Engineer - UNIX/Linux Specialist
crashrecovery.org [email protected]
On Wed, Apr 28, 2004 at 01:30:58AM +0200, Robert M. Stockmann wrote:
> > What the hell do these two paragraphs have to do with each other?
>
> C99 coding style, more specific the use of unnamed and anonymous structures
> and unions, allows the kernel programmer to interface, read glue, binary only
> driver modules to interface with any linux kernel source tree.
What the hell are you going on about? Unnamed structures are a
syntactical construct and have ZILCH to do with runtime.
> The needed header files, which need to be read by the gcc compiler, contain
> unnamed and annonymizes structures and unions. In the worst case scenario,
> only the name of used variables are given and no info about variable type or
> size are inside these headers files. gcc-2.95.3 fails to succesfully link these
Opaque types have been available FOREVER.
On Tue, 27 Apr 2004, Tim Hockin wrote:
> On Wed, Apr 28, 2004 at 01:30:58AM +0200, Robert M. Stockmann wrote:
> > > What the hell do these two paragraphs have to do with each other?
> >
> > C99 coding style, more specific the use of unnamed and anonymous structures
> > and unions, allows the kernel programmer to interface, read glue, binary only
> > driver modules to interface with any linux kernel source tree.
>
> What the hell are you going on about? Unnamed structures are a
> syntactical construct and have ZILCH to do with runtime.
I thought so too, until your semi open-source link kit is linked to that
brand-new linux kernel source tree, and at the same time the binary
components of your link-kit have become incompatible with that newer kernel.
Result? one might even loose its data, upon booting that newly build
kernel and modules, in case your storage-controller has a binary only
link-kit as its driver.
> > The needed header files, which need to be read by the gcc compiler, contain
> > unnamed and annonymizes structures and unions. In the worst case scenario,
> > only the name of used variables are given and no info about variable type or
> > size are inside these headers files. gcc-2.95.3 fails to succesfully link these
>
> Opaque types have been available FOREVER.
sure, but can one qualify that as Open Source?
Robert
--
Robert M. Stockmann - RHCE
Network Engineer - UNIX/Linux Specialist
crashrecovery.org [email protected]
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.
Marc
--
Marc Boucher
Linuxant inc.
On Apr 27, 2004, at 7:12 PM, Rusty Russell wrote:
> On Wed, 2004-04-28 at 02:58, Marc Boucher wrote:
>> 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
> @@ -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;
>
> --
> Anyone who quotes me in their signature is an idiot -- Rusty Russell
>
Chris Friesen wrote:
> Marc Boucher wrote:
>
>> On Apr 27, 2004, at 1:46 PM, Chris Friesen wrote:
>
>
>>> 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.
The "nothing misleading to the human eye" argument is totally bogus. The
human eye does not see your sources (especially not the sources of the
completely proprietary modules).
"Marc Boucher is a sl^Hick funny d^H^H^H^H^Huck."
Is the above sentence insulting or not?
"But your honor, there is nothing misleading to the human eye. Calling
somebody a slick funny duck may seem strange, but it is surely not an insult!"
>> 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.
No need to apologize. If you want to check for yourself, you'll see that
at least the SUSE .rpm packages do NOT contain any source. If you are
interested, I can send you the (signed by Linuxant) .rpm package I am
talking about.
Regards,
Carl-Daniel
--
http://www.hailfinger.org/
On Tue, 27 Apr 2004, Tim Hockin wrote:
> On Wed, Apr 28, 2004 at 01:59:08AM +0200, Robert M. Stockmann wrote:
> > > What the hell are you going on about? Unnamed structures are a
> > > syntactical construct and have ZILCH to do with runtime.
> >
> > I thought so too, until your semi open-source link kit is linked to that
> > brand-new linux kernel source tree, and at the same time the binary
> > components of your link-kit have become incompatible with that newer kernel.
>
> This is possible with any structure, named or unnamed. It's called an
> ABI, and it's one of the reasons that binary modules suck. It doesn't
> have *anything* to do with unnamed structures. At all. And if you think
> so, show me code.
here's a example :
http://www.promise.com/support/file/driver/1_fasttrak_tx4000_partial_source_1.00.0.19.zip
>
> > > Opaque types have been available FOREVER.
> >
> > sure, but can one qualify that as Open Source?
>
> If used properly (and they are used in Linux, I believe) they can be very
> handy. It's a non-sequiter. no coding technique, no matter how
> incoherent, is incompatible with open source.
Opaque types should be no problem. However the complete definition must reside
somewhere _inside_ the complete source. Opaque types is even a bless, i agree.
It summarizes code to only reflect what is essential, instead of repeating
tedious and long struct types and defines. However if Opaque types are used
inside a partial_source tree, where the complete definition is hidden
inside the binary only closed source parts, then its the complete opposite
of what i would call a bless.
Robert
--
Robert M. Stockmann - RHCE
Network Engineer - UNIX/Linux Specialist
crashrecovery.org [email protected]
On Tue, Apr 27, 2004 at 08:02:03PM -0400, Marc Boucher wrote:
>
> 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.
> 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.
>and the
> political situation with Conexant's proprietary signal processing
> code outside of our control.
--
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
On Tue, 27 Apr 2004, Tim Hockin wrote:
> On Wed, Apr 28, 2004 at 02:18:59AM +0200, Robert M. Stockmann wrote:
> > > This is possible with any structure, named or unnamed. It's called an
> > > ABI, and it's one of the reasons that binary modules suck. It doesn't
> > > have *anything* to do with unnamed structures. At all. And if you think
> > > so, show me code.
> >
> > here's a example :
> >
> > http://www.promise.com/support/file/driver/1_fasttrak_tx4000_partial_source_1.00.0.19.zip
>
> Care to show me where they use unnamed structures, and how it has anything
> to do with binary modules?
fasttrak.h :
/*********************************************************************
fasttrak.h -- PROMISE FastTrak Controllers device driver for Linux.
Copyright (C) 2002-2005 PROMISE Technology, Inc.
This program is free software; you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
the Free Software Foundation; version 2 of the License.
Bugs/Comments/Suggestions should be mailed to:
[email protected]
For more information, goto:
http://www.promise.com
*********************************************************************/
#ifndef _ft3xx_h
#define _ft3xx_h
#include <linux/version.h>
#if LINUX_VERSION_CODE >= KERNEL_VERSION(2,4,0)
#define ft3xx { \
next: NULL, \
proc_dir: NULL, \
proc_info: NULL, \
name: "ft3xx", \
detect: ft3xx_detect, \
release: ft3xx_release, \
ioctl: ft3xx_ioctl, \
info: NULL, \
command: NULL, \
queuecommand: ft3xx_queuecommand, \
eh_abort_handler : ft3xx_abort_eh, \
eh_device_reset_handler : ft3xx_reset_eh, \
abort: ft3xx_abort, \
reset: ft3xx_reset, \
slave_attach: NULL, \
bios_param: ft3xx_bios_param, \
can_queue: Can_Queue, /* max simultaneous cmds */\
this_id: 7, /* scsi id of host adapter */\
sg_tablesize: Max_SG_Table - 2,/* max scatter-gather cmds */\
cmd_per_lun: 1, /* cmds per lun (linked cmds) */\
present: 0, \
unchecked_isa_dma: 0, /* no memory DMA restrictions */\
use_clustering: 0, \
use_new_eh_code: 0, /* enable this field next time*/\
emulated: 0, \
proc_name: "ft3xx" \
}
#else
#define ft3xx { \
next: NULL, \
proc_dir: NULL, \
proc_info: NULL, \
name: "ft3xx", \
detect: ft3xx_detect, \
release: ft3xx_release, \
ioctl: ft3xx_ioctl, \
info: NULL, \
command: NULL, \
queuecommand: ft3xx_queuecommand, \
eh_abort_handler : ft3xx_abort_eh, \
eh_device_reset_handler : ft3xx_reset_eh, \
abort: ft3xx_abort, \
reset: ft3xx_reset, \
slave_attach: NULL, \
bios_param: ft3xx_bios_param, \
can_queue: Can_Queue, /* max simultaneous cmds */\
this_id: 7, /* scsi id of host adapter */\
sg_tablesize: Max_SG_Table - 2, /* max scatter-gather cmds */\
cmd_per_lun: 1, /* cmds per lun (linked cmds) */\
present: 0, \
unchecked_isa_dma: 0, /* no memory DMA restrictions */\
use_clustering: 0, \
use_new_eh_code: 0, /* enable this field next time*/\
emulated: 0, \
}
#endif
#endif /* _ft3xx_h */
This header file is needed to be able to link ft3xx.o . In which way binary
incompatibility is introduced, inside this case is hard to tell. We
will never know i guess , since the type and size of the above components
is hidden inside the binary only part :
-rw-r--r-- 1 stock stock 227757 Oct 13 2003 ftlib.o
Well it works, with gcc-3.x, but not with gcc-2.95.3
>
> > Opaque types should be no problem. However the complete definition must reside
> > somewhere _inside_ the complete source. Opaque types is even a bless, i agree.
>
> If you're open, then yes. If you're not open, you could have the
> definition of the opaque type inside your own closed code, and things will
> still work. In fact, that's the sane way to do closed structures.
>
Hardware which uses these things inside its linux drivers, is hardware
i would never run Linux on.
Robert
--
Robert M. Stockmann - RHCE
Network Engineer - UNIX/Linux Specialist
crashrecovery.org [email protected]
Hi David,
On Apr 27, 2004, at 8:25 PM, David Gibson wrote:
> On Tue, Apr 27, 2004 at 08:02:03PM -0400, Marc Boucher wrote:
>>
>> 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.
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.
>
> 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.
It's not only "my" customers, but more importantly Linux users at large.
Conexant modem chipsets are extremely common hardware devices
that need to be properly supported within the constraints that we are
facing.
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.
>
>> 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.
No need to even look at the source; this information is clearly
provided in the
LICENSE (which is also displayed on our website before downloading),
in the README file, and possibly other places too.
If the "standard tools" were more properly designed, such workarounds
would be totally unnecessary, and we would much rather avoid them.
Cordially
Marc
>
>> and the
>> political situation with Conexant's proprietary signal processing
>> code outside of our control.
>
> --
> 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
>
On Tue, 27 Apr 2004, Tim Hockin wrote:
> On Wed, Apr 28, 2004 at 02:56:16AM +0200, Robert M. Stockmann wrote:
> > > Care to show me where they use unnamed structures, and how it has anything
> > > to do with binary modules?
> >
> > fasttrak.h :
> > #define ft3xx { \
> > next: NULL, \
> ...
> > }
> > #endif
>
> > This header file is needed to be able to link ft3xx.o . In which way binary
> > incompatibility is introduced, inside this case is hard to tell. We
> > will never know i guess , since the type and size of the above components
> > is hidden inside the binary only part :
>
> Do you know C, or just pretend to?
I am no kernel coder, if its that what you mean.
>
> Those are structure initializers, not unnamed types. They've provided a
> macro to use to initialize instances of some structure.
>
> fasttrak.c:890 shows
> static Scsi_Host_Template driver_template = ft3xx;
>
> The structure definition for 'Scsi_Host_Template' is in
> /usr/src/linux/drivers/scsi/hosts.h which is included in fasttrak.c.
Ok you got me there. I would suggest to change fasttrak.h like this
to obtain better readability :
#ifndef _ft3xx_h
#define _ft3xx_h
#include <linux/version.h>
#include "/usr/src/linux/drivers/scsi/hosts.h"
#if LINUX_VERSION_CODE >= KERNEL_VERSION(2,4,0)
#define ft3xx { \
next: NULL, \
...
};
>
> If you run it thru the preprocessor, you'd see
> static Scsi_Host_Template driver_template = {
> next: NULL,
> ...
> };
>
> No opaque structs. No unnamed types. No magic. It's not pretty, and
> it's bound to break on any non-standard rig, but it's NOT what you claim
> it is.
>
> The initializer style (foo: value) is probably why gcc-2.95 blows up, but
> I don't have it here to verify.
It does, which awakened me all up in arms. certainly if gcc-2.95.3
is still mentioned as recommended gcc version for the ia32 platform
inside /usr/src/linux/Documentation/Changes. It pissed me off not
being able to use gcc-2.95.3 when using that fasttrak driver.
>
> You really should know what you're talking about before you launch a
> crusade against something.
>
I agree the fasttrak partial-source kit is not the all defining example.
Still i believe nasty stuff is possible.
Robert
--
Robert M. Stockmann - RHCE
Network Engineer - UNIX/Linux Specialist
crashrecovery.org [email protected]
On Wed, 2004-04-28 at 10:02, Marc Boucher wrote:
> 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.
--
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?
Regards
Marc
--
Marc Boucher
Linuxant inc.
On Apr 27, 2004, at 9:57 PM, Rusty Russell wrote:
> On Wed, 2004-04-28 at 10:02, Marc Boucher wrote:
>> 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.
> --
> Anyone who quotes me in their signature is an idiot -- Rusty Russell
>
Marc Boucher <[email protected]> said:
> On Tue, Apr 27, 2004 at 04:09:36AM +0200, Carl-Daniel Hailfinger wrote:
> > Hi,
> > LinuxAnt offers binary only modules without any sources.
> Not true. Linuxant modules come with full source for operating-system
> specific code.
If they don't distribute _all_ source, it is not distribution under GPL.
--
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
Marc Boucher <[email protected]> said:
> On Apr 27, 2004, at 8:25 PM, David Gibson wrote:
> > On Tue, Apr 27, 2004 at 08:02:03PM -0400, Marc Boucher wrote:
> >> 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.
> 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.
[...]
> 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.
> 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.
> 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.
--
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
On Apr 27, 2004, at 11:23 PM, Horst von Brand wrote:
> Marc Boucher <[email protected]> said:
>> On Apr 27, 2004, at 8:25 PM, David Gibson wrote:
>>> On Tue, Apr 27, 2004 at 08:02:03PM -0400, Marc Boucher wrote:
>>>> 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.
>
>> 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).
>
> [...]
>
>> 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.
>
>> 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.
We have not asked for nor expected the kernel community to fix the
proprietary
parts of, for the sake of example, the Conexant softmodem drivers,
which is not
an easy task to do just from a practical point of view since it often
requires
expensive test equipment and specialized DSP knowledge to work on
effectively.
However the portions of our products that specifically relate to the
linux kernel are
provided in source form and generally accessible to the community.
>
>> 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.
There is a very down-to-earth tendency on the part of some people to
play
lawyer on the net and make unsubstantiated allegations.
Cordially
Marc
> --
> 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/
>
[email protected] wrote:
> On Tue, 27 Apr 2004 19:53:39 +0200, Grzegorz Kulewski said:
>
>
>>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.
>
The tainting flag is in each module. Instead of trying them all
to see what taints the kernel, run "find"
over /etc/modules/<kernelversion>
to find all modules installed, and use some program
that print out the taintedness for each file. Simple, and
works even for modules that never gets loaded during normal use.
I don't know if such a program exists, but it should be trivial
to make, just paste the kernel "tainting" code into a
ordinary program.
Helge Hafting
Marc Boucher wrote:
>
> Hi Adam,
>
> On Apr 27, 2004, at 1:25 PM, Adam Jaskiewicz wrote:
>
>>
>>> 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.
>
>
> 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..
When distributing your module (with the license string fixed)
you may also distribute a kernel patch that disables the console message.
Better: you could change the logging level so the user only gets messages
in syslog and not on the console. A customer clueless enough to be confused
by the tainting message probably don't need those other console messages either.
Users with enough clue to want these messages may then turn them on again.
Helge Hafting
Marc Boucher wrote:
>
> 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.
> 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.
> 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.
>
> 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
On Tue, 2004-04-27 at 23:28, Marc Boucher wrote:
> 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.
> 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
Hi Helge,
On Apr 28, 2004, at 7:47 AM, Helge Hafting wrote:
> Marc Boucher wrote:
>> 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.
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.
>
> 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.
>
>> 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.
We are providing code as much as possible, without expecting free
support, but are still getting flamed.
>
>> 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.
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.
>> 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.
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.
Marc
>
> Helge Hafting
>
Marc Boucher wrote:
>
>
> 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.
Marc Boucher <[email protected]> said:
> On Apr 27, 2004, at 11:23 PM, Horst von Brand wrote:
> > Marc Boucher <[email protected]> said:
[...]
> >> 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.
You don't _know_ that for a fact; due to the fraudulent modules perhaps
they lost untold hours trying to find out how something broke, with no hope
to find it because it was your module.
> 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.
More power to you! But when doing so _please_ do respect the wishes (and
conditions) they place on whoever does so. That is all that is being asked
from you. Not give up your firstborn, not cough up lots of dough, not sign
obnoxious NDAs, nothing.
> 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).
I strongly condemn such an action.
[...]
> >> 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.
Then why fake GPL at all?
> 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)
Tainting messages are there among others to warn people they are running a
non-supported configuration. Bypassing that "for cosmetic reasons" is
exactly bypassing an important reason for tainting. It also gets in the way
of kernel hackers trying to help said customers with their problems, so it
bypasses the other reason for tainting.
> while keeping the volume
> of messages under control.
You should have asked, and helped fix it (e.g., comming up with a means to
show the message once for a group of related modules, or making all modules
that don't contain binary blobs truly GPL (in the process defining
interfaces that other winmodems could use, perhaps), or whatever). "Sorry,
your door didn't open. I needed to get in, so I broke it down." won't go
down too well if it is your house they are talking about...
--
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
Marc -
Wanted to take a moment to thank you for the incredible job you and
Linuxant have done supporting the Linux community. I have been
following the threads on the lkml and must say that I am appalled at
the way you are being <personally> treated. If it were not for
Linuxant, owners of the "linux unfriendly" chipsets would be SOL. I for
one was pis**d when I found out my 2100b wireless card in my brand
spanking new X31 was not supported; until of course, I stumbled upon
driverloader. While there are other "free" alternatives out there and
also the ipw2100 project, I for one do not want to go through the
effort of compiling, modifying kernel parameters etc. For me, the $20
spent on driverloader was well worth it and allowed me to scrap XP for
Linux. And how about support? I surely appreciated the personal
support, and hours, you spent on my laptop hanging issue. Would I
recieve that from the other project's community members?
With that said, I must admit that I was one of those confused users
when I first saw the tainted kernel message(s). I have used Linux (I
repeat, <<used>> Linux) since about 96 or so. I don't claim to be an
expert or a developer but by no means am a Linux newbie. Just because I
am more interested in applications, window managers and graphical
environments such as gnome and kde, then meaningless (to the user)
kernel messages, does not make me a stupid user. However, not fully
understanding the kernel message, I thought something was wrong the
first time I noticed it (VMware modules as I recall.)
The Kernel developers should be focused on bringing Linux to the
attention of EVERY desktop user, not just those who are knowledgeable
of kernel messages, configuration, APIs and the GPL. Why do you think
that distributions such as Xandros have become so popular to users
switching to Linux? It seems rather simple to me; the product just
plain works! Is the diamond of their OS, the file manager, released
under the GPL? Of course not, and the users do not care! They just want
to be able to integrate into existing Windows environments,
authenticate against their NT/AD domains and be able to map to existing
Windows network resources - all seamlessly.
In summary, I firmly feel that there needs to be a mindset change if
Linux is to eat away at Windows market share on the desktops. Let's
take a certain Linux distributor as an example; here is a quote from a
recent posting on the 4K stacks issue:
"Too bad. External binary modules never have, and never will hold back
development. NVIDIA need to issue driver updates that work accordingly."
Reworded from a user-focused perspective:
"External binary modules shouldn't hold back development. Although
NVIDIA needs to issue driver updates that work accordingly, <>
understands that our users are the number one priority. Therefore,
until new modules are released, we will offer a workaround for users
who are effected."
Sincerely,
Keith
----------------------------------------------
Mailblocks - A Better Way to Do Email
http://about.mailblocks.com/info
On Apr 28, 2004, at 3:32 PM, Timothy Miller wrote:
>
>
> Marc Boucher wrote:
>
>>> 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.
>
>
> If your only "options" involve violating the GPL, then you cannot do
> business in this area.
that's not what I said. What I said is that kernel patches are not an
acceptable temporary workaround for the large installed base of average
customers, since they generally cannot or do not want to bother
recompiling stuff. We still make source for linux code and other parts
required to allow the technically inclined to easily rebuild the
modules and comply with the GPL.
> "Someone won't let me release some code" isn't an excuse for breaking
> the law.
>
The proprietary code that cannot be released in source form is
licensed material that was essentially developed by another party
(Conexant) for other platforms. It clearly does not constitute a
derived work of Linux.
Marc
--
Marc Boucher
Linuxant inc.
Marc Boucher wrote:
>
> 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.
I was not personally offended, but I hope what you said here is taken by
others as a good-faith gesture.
>
> 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.
This is just part of the community, something which you should learn to
take advantage of. It's part of an impressive system of checks and
balances.
A major principle of internet communication is that people will say
venomous things in email which they would never say to you in person.
You have to take what they say for what it MEANS, not what it looks like.
If you're flamed, particularly in a forum like LKML, pay attention to
the meat of what the person is saying. If the person is right, GREAT.
If the person has completely misunderstood the situation, let it go.
And then, don't get drawn into endless debate defending yourself to
every comment that people make. Sometimes, it's best to just summarize
the situation, acknowledge people's complaints, explain which ones are
factual, and explain that you're working on a solution.
There are a number of people on LKML who seem to do an amazing job of
getting to the point in a debate. Take Theodore Ts'o, for example. In
particular, his posts are a pleasure to read because they are so clear
and full of knowledge.
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.
Sincerely
Marc
--
Marc Boucher
Linuxant inc.
On Apr 28, 2004, at 1:37 PM, Timothy Miller wrote:
>
> Marc Boucher wrote:
>
>> 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.
>
Marc Boucher wrote:
>> 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.
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.
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");
>
> 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.
Even better they should be talking to our layers.
Are they trying to get access to GPL-only symbols?
--
64 bytes from 195.113.31.123: icmp_seq=28 ttl=51 time=448769.1 ms
Hi!
> 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.
Pavel
--
64 bytes from 195.113.31.123: icmp_seq=28 ttl=51 time=448769.1 ms
On Apr 28, 2004, at 10:03 AM, Tom Sightler wrote:
> On Tue, 2004-04-27 at 23:28, Marc Boucher wrote:
>> 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.
I'm sorry, but the typical user of EMC PowerPath cannot really be
compared to the typical winmodem user.
If the issue hadn't been a real confusing / usability problem for
thousands of individual customers, we wouldn't have bothered with the
workaround.
>> 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.
It is very common practice to simulate the perception of software to
work around things and provide increased comfort and compatibility.
Entire GPL projects like wine, reactos, ndiswrapper (an open-source
clone of our DriverLoader), and even the linux kernel itself implement
foreign APIs or many workarounds to make programs or drivers function,
even believe that they are running in another environment. Do these
projects "lie" and represent real-world evils by technically pretending
/ emulating results when they are in fact not the real thing?
> 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?
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.
> 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.
Some folks are more ideological than practical, but most people use
Linux to solve practical needs.
The former are a lot more vocal than the silent majority.
> 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
>
> Later,
> Tom
>
>
On Wed, 28 Apr 2004 12:40:43 -0400
Marc Boucher <[email protected]> wrote:
lent majority.
>
> > 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).
Pavel Machek wrote:
> Hi!
>
>
>>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 very fact that someone who represents the company is willing to talk
to us on LKML should be mega points in their favor.
Yes, they did something wrong, but they're giving us the time of day,
something a lot of companies don't do until the FSF has been hounding
them for a year.
Stephen Hemminger wrote:
>
>
> 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).
Marc apologized.
On Tue, 27 Apr 2004, Paulo Marques wrote:
> 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? :)
Definitely my favorite approach of dealing with these
people. Does anybody know whether their modules use
any EXPORT_SYMBOL_GPL symbols and whether they touch
any code I could claim copyright on ?
If it touches any of my code, where should I mail the
cease & desist ? ;)
--
"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
On Tue, 27 Apr 2004, Marc Boucher wrote:
> In an enterprise, customers always come first.
If that were true, you wouldn't be charging anybody
any money for the product ;)
However, in real companies there are other groups
of people just as important as the customers,
including investors, employees and the copyright
holders of any code your business critically
depends on.
--
"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
Keith D Burgess Jr <[email protected]> said on Wed, 28 Apr 2004 11:56:38 -0700:
> The Kernel developers should be focused on bringing Linux to the
> attention of EVERY desktop user, not just those who are knowledgeable
> of kernel messages, configuration, APIs and the GPL. Why do you think
Um, I don't think you presonally know why most linux kernel developers
are working. Some work to make a technically superior OS. Some work
for idealogical reasons.
I suspect not many are "focused on bringing Linux to the attention of
EVERY desktop user" because they are not interested in that. That's a
job for someone in suits. And just because you think they shoudl be
focussed on that doesn't mean they should be.
--
TimC -- http://astronomy.swin.edu.au/staff/tconnors/
Brown's Theorem (Physics III student, Usyd):
"The only thing that behaves like a billiard
ball, is a billiard ball"
On Wed, 28 Apr 2004, Marc Boucher wrote:
> 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.
The problem shouldn't be going both ways, though.
It is your decision to publish a module that taints
the kernel, so the support burden should not fall on
the kernel community...
--
"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
On Wed, 28 Apr 2004, Marc Boucher wrote:
> 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."
--
"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
Rik van Riel wrote:
> On Wed, 28 Apr 2004, Marc Boucher wrote:
>
>
>>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."
>
I think something like that is much easier to decipher.
On Thursday 29 April 2004 02:40, you wrote:
> Rik van Riel wrote:
> > On Wed, 28 Apr 2004, Marc Boucher wrote:
> >>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."
>
> I think something like that is much easier to decipher.
Why cannot the binary module suppliers tell their customers why this 'tainted'
message is appearing in their kernel log?
You know they are human, and have a mind of their own, they would probably
have understood the fact that the company is providing it's own set of
drivers that might not be tested fully on every kernel release. And so their
customers (like what nVidias and others companies customers have done in the
past) would turn to this company for support instead of the lkml.
Kenneth
does not need to state the fact that this is just 2 cents.
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..
Cheers
Marc
On Apr 28, 2004, at 8:02 PM, Rik van Riel wrote:
>
> 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."
>
>
>
> --
> "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
>
Marc Boucher wrote:
>
> 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.
On Thu, 29 Apr 2004, Ian Stirling wrote:
> > 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.
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?"
--
"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
On Thursday 29 April 2004 04:36, you wrote:
> Marc Boucher wrote:
> > 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.
1000-2000(?) instructions to display the message and some x(?) instructions to
check if it's been reported before, yeah, i'd have to say no too. ;)
Kenneth
Rik van Riel wrote:
> On Thu, 29 Apr 2004, Ian Stirling wrote:
>
>
>>>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.
>
>
> 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?"
Sorry.
I meant adding code to suppress warnings, not the expanded warning, which is sensible.
On 4/28/04 at 8:02 PM (GMT-0400), Rik van Riel <[email protected]> wrote:
>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."
That's too sensible: Linux wouldn't be Linux without incomprehensible
messages like:
$ sudo urpmi /home/rzeman/kernel-smp-2.4.25.4mdk-1-1mdk.i586.rpm
installing /home/rzeman/kernel-smp-2.4.25.4mdk-1-1mdk.i586.rpm
Preparing...
##################################################
1:kernel-smp-2.4.25.4mdk
##################################################
look like there was a problem, the default vmlinuz version is not the same
of the initrd which mean you have a mdk kernel and not a mdk initrd you may
go in trouble
or doing a menuconfig on a new 2.4.26 kernel and having it nicely tell me
that my choice HAD to be a module, not built in, because it depends upon
something else already selected as a module--without bothering to deign to
say what the dependency was so I had to play grand guessing games.
/this week's irritations.
--
Mac OS X: Because making UNIX user-friendly was easier than fixing Windows.
Rik van Riel wrote:
> On Wed, 28 Apr 2004, Marc Boucher wrote:
>
>
>>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."
Sounds very "politically correct", but certainly more descriptive and
less alarming.
On Thu, 29 Apr 2004, Timothy Miller wrote:
> > "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.
--
"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
Carl-Daniel Hailfinger ha scritto:
>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
>
>
<snip>
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".
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"?
For sake of completeness. *My* download of
https://www.linuxant.com/drivers/hsf/full/archive/hsfmodem-6.03.00lnxt04032800full/hsfmodem-6.03.00lnxt04032800full.tar.gz
contains, in the /modules/GPL/ directory the following files:
-rw-r--r-- 1 colla colla 18860 ago 23 2003 COPYING
-rw-r--r-- 1 colla colla 13609 gen 18 00:51 oscompat.h
-rw-r--r-- 1 colla colla 32573 mar 26 09:16 serial_cnxt.c
-rw-r--r-- 1 colla colla 3392 ago 23 2003 serial_cnxt.h
-rw-r--r-- 1 colla colla 57857 ago 24 2003 serial_core.c
-rw-r--r-- 1 colla colla 9789 ago 22 2003 serial_core.h
I strongly hope that developers' efforts will be addressed to more
valuable topics than detecting the "Linuxant" string in a loadable
module. Not forgetting that Linux\0ant, L\0inuxant, etc. would display
the same way ;-)
Kind Regards
--
Ing. Giuliano Colla
Direttore Tecnico
Copeca srl
Bologna
Italy
On Thu, Apr 29, 2004 at 08:40:53PM +0200, Giuliano Colla wrote:
> 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"?
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.
Giuliano Colla wrote:
> 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"?
>
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.)
On Apr 29, 2004, at 17:14, Rik van Riel wrote:
> On Thu, 29 Apr 2004, Timothy Miller wrote:
>
>>> "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.
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
On Thu, 29 Apr 2004, Giuliano Colla wrote:
>
> Let's try not to be ridiculous, please.
It's not abotu being ridiculous. It's about honoring peoples copyrights.
> 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.
> 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.
> 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.
Linus
Giuliano Colla wrote:
> 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:
>
> 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? ;-)
Marc
Paul Wagland wrote:
>
> On Apr 29, 2004, at 17:14, Rik van Riel wrote:
>
>> On Thu, 29 Apr 2004, Timothy Miller wrote:
>>
>>>> "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.
>
>
> 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? 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...
On Thu, Apr 29, 2004 at 02:10:41PM -0700, Linus Torvalds wrote:
> It has absolutely nothing to do with religion.
... and as the matter of fact, religious nuts *do* equate those two (c.f.
assorted debian-devel resident wankers)
On Thu, Apr 29, 2004 at 05:36:59PM -0400, Timothy Miller wrote:
> While we're on all of this, are we going to change "tained" to some
> other less alarmist word?
"screwed"
On Jueves, 29 de Abril de 2004 23:36, Timothy Miller wrote:
>
> 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).
--
Jorge Bernal aka. Koke
[email protected] // [email protected]
JID: [email protected]
Marc Boucher wrote:
> Giuliano Colla wrote:
>
>>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:
>
>>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? ;-)
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.
On Apr 29, 2004, at 6:12 PM, Timothy Miller wrote:
>
> Marc Boucher wrote:
>> Giuliano Colla wrote:
>>> 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:
>>> 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? ;-)
>
> 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.
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.
>
> 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.
>
Linuxant is also more than willing to take responsibility for fixing
potential bugs in its drivers: it's a big part of our purpose and
business.
Marc
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.
Responsible projects, people and corporations usually all care a lot
about their reputation and can be trustworthy, regardless of the
specific form in which they distribute software.
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.
Marc
On Apr 29, 2004, at 5:47 PM, Jorge Bernal (Koke) wrote:
> On Jueves, 29 de Abril de 2004 23:36, Timothy Miller wrote:
>>
>> 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).
>
> --
> Jorge Bernal aka. Koke
> [email protected] // [email protected]
> JID: [email protected]
>
On Thu, Apr 29, 2004 at 06:24:58PM -0400, Marc Boucher wrote:
> 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.
On Thu, Apr 29, 2004 at 06:24:58PM -0400, Marc Boucher wrote:
>
> 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.
You are missing the point. Badly. All software sucks, be it open-source
of proprietary. The only question is what can be done with particular
instance of suckage, and that's where having the source matters.
On Wednesday 28 April 2004 19:15, Marc Boucher wrote:
> > 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.
I think you have to live with multiple warning messages,
at least until Rusty's patch propagate to mainline.
It's not fatal.
--
vda
On Thursday 29 April 2004 05:47, Kenneth Aafl?y wrote:
> On Thursday 29 April 2004 04:36, you wrote:
> > Marc Boucher wrote:
> > > 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.
>
> 1000-2000(?) instructions to display the message and some x(?) instructions
No. ~20 bytes or less on x86 (push,call printk() isns).
Plus text of the message (~150 bytes?).
If you're talking about *time* to execute 2000 insns, that
too does not make much sense.
--
vda
No Linux spinlocks, kernel structures, interfaces, macros or inlines
whatsoever are used in the binary-only proprietary modem code that
is bundled with our drivers. All Linux-related things are fully
separated
in open-source modules. As I said before, Linuxant is trying very hard
to attenuate the inconveniences of political constraints for people.
Despite this, like any in complex software, there are occasional
compatibility issues with certain configurations since the kernel
can be wildly customized/patched, APIs are constantly evolving,
and PC hardware incredibly diverse.
But we are here to assume our responsibility in fixing and properly
maintaining the drivers as well as we can.
Marc
On Apr 29, 2004, at 6:32 PM, Tim Hockin wrote:
> On Thu, Apr 29, 2004 at 06:24:58PM -0400, Marc Boucher wrote:
>> 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.
>
Marc Boucher wrote:
>
> 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.
So, what you're saying is that you have taken a binary driver, not
written by you, designed for an entirely different ABI, and you have
written some code, which you have released under GPL, that interfaces
between the Linux Kernel and the binary driver?
Kinda like that project which lets people use Windows network drivers
under Linux?
I don't see a problem with that, ideologically. I mean, it sucks that
we can't get Linux-specific drivers, but at least people can use the
hardware.
HOWEVER, there are two problems:
(1) It still taints the kernel, because the behavior of the Windows
driver is still a black box that cannot be debugged. The only way to
avoid that would be to run the Windows driver in some kind of sandbox.
(2) Misleading the kernel (and users) into thinking that the driver does
not taint the kernel, when in fact it does, is wrong.
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?
Denis Vlasenko wrote:
>>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.
I have to agree. The only thing that Marc did wrong was to evade the
tainting. Everything else seems to be above-board.
On Thu, 29 Apr 2004 18:24:58 -0400
Marc Boucher <[email protected]> wrote:
> 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.
Sean.
Dear Sean,
On Apr 29, 2004, at 7:55 PM, Sean Estabrooks wrote:
>
> 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).
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.
Sincerely
Marc
--
Marc Boucher
Linuxant inc.
On Friday 30 of April 2004 04:15, Marc Boucher wrote:
> Dear Sean,
>
> On Apr 29, 2004, at 7:55 PM, Sean Estabrooks wrote:
> > 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).
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.
Regards,
Bartlomiej
Bartlomiej Zolnierkiewicz wrote:
> On Friday 30 of April 2004 04:15, Marc Boucher wrote:
>
>>Dear Sean,
>>
>>On Apr 29, 2004, at 7:55 PM, Sean Estabrooks wrote:
>>
>>>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).
>
>
> 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.
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."
Peter
--
Dr Peter Williams, Chief Scientist [email protected]
Aurema Pty Limited Tel:+61 2 9698 2322
PO Box 305, Strawberry Hills NSW 2012, Australia Fax:+61 2 9699 9174
79 Myrtle Street, Chippendale NSW 2008, Australia http://www.aurema.com
On Thu, 29 Apr 2004 22:15:19 -0400
Marc Boucher <[email protected]> wrote:
<snip>
> 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.
<snip>
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?
In any case, should your goals trump those of active and senior kernel
maintainers? They decided that tainting the kernel was appropriate.
Forgive me for saying you seem more self righteous than sorry about your
underhanded dealings with people you claim to respect.
Regards,
Sean.
On Apr 30, 2004, at 12:43 AM, Sean Estabrooks wrote:
>
> 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, 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.
Marc
> 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?
There is more.
Not executing external code, but trusting external data.
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"!
*1: NCR, Symbios-Logic, LSI-Logic, whatever they are called today
*2: You need anything "bigger" than the 810-model
*3: I'm not sure if i still have trouble with this feature because i
haven't changed the setup in my computer for 3 years, it MAY be that i
still use a workaround for this feature. My next computer won't have
SCSI anymore, so i don't care if i still use a workaround.
Bis denn
--
Real Programmers consider "what you see is what you get" to be just as
bad a concept in Text Editors as it is in women. No, the Real Programmer
wants a "you asked for it, you got it" text editor -- complicated,
cryptic, powerful, unforgiving, dangerous.
On Fri, 30 Apr 2004 01:44:24 -0400
Marc Boucher <[email protected]> wrote:
> 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.
That's not how you pitch it on your website. For instance, how many
sales does Intel's Centrino project lose because you make non GPL-friendly
hardware viable under Linux? Anyway, no matter how sure you are of
your position, it doesn't justify what you did.
Sean.
Marc Boucher wrote:
>
>
> On Apr 30, 2004, at 12:43 AM, Sean Estabrooks wrote:
>
>>
>> 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.
I'm not so sure you should pluralize "vendors" ;-)
> 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,
That conclusion cannot be drawn from the pretense...
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.
Jeff
On Fri, 2004-04-30 01:44:24 -0400, Marc Boucher <[email protected]>
wrote in message <[email protected]>:
> There are major chipset vendors out there who have managed to become
> market leaders while not providing any drivers for Linux.
Which I think is a bad thing. Vendors work for their customers (hey,
even you said something like that) and /me as a customer wants to see
specs for the devices. So? Comply or die, dear vendor.
(Oh, I'm to buy a new laptop at some time. Any hints for a good machine?
Fully supported and not-that-much sucking? The sparc boxes from tadpole
look nice...)
> 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).
It's nice if they actually work on drivers (ie. the e100 driver is more
stable on some chipset-buildin NICs than the eepro100), but that
wouldn't be the final factor for or against a decision about a product.
Documentation therefor matters! If a supplied driver is commented very
well, I'd even accept that for docs!
> 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.
I think that most vendors actually do have specs for their hardware. In
most cases, it should even be enough to let them leak at some time...
This way they'd probably sell more hardware:)
MfG, JBG
--
Jan-Benedict Glaw [email protected] . +49-172-7608481
"Eine Freie Meinung in einem Freien Kopf | Gegen Zensur | Gegen Krieg
fuer einen Freien Staat voll Freier B?rger" | im Internet! | im Irak!
ret = do_actions((curr | FREE_SPEECH) & ~(NEW_COPYRIGHT_LAW | DRM | TCPA));
On Fri, 2004-04-30 04:04:17 -0400, Jeff Garzik <[email protected]>
wrote in message <[email protected]>:
> Marc Boucher wrote:
> >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.
That's letting docs leak out of the company:)
> DriverLoader significantly lowers that cost, while not providing an open
> source solution at all.
Right:(
MfG, JBG
--
Jan-Benedict Glaw [email protected] . +49-172-7608481
"Eine Freie Meinung in einem Freien Kopf | Gegen Zensur | Gegen Krieg
fuer einen Freien Staat voll Freier B?rger" | im Internet! | im Irak!
ret = do_actions((curr | FREE_SPEECH) & ~(NEW_COPYRIGHT_LAW | DRM | TCPA));
On Thu, 29 Apr 2004, Timothy Miller wrote:
> Rik van Riel wrote:
> > On Wed, 28 Apr 2004, Marc Boucher wrote:
> >>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."
>
> Sounds very "politically correct", but certainly more descriptive and
> less alarming.
And I suggest not to print $MODULE_VENDOR, but `the supplier of $MOD_FOO' to
prevent people playing games with $MODULE_VENDOR (e.g. pointing it to lkml).
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected]
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
On Fri, 30 Apr 2004, Matthias Schniedermeyer wrote:
> 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.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected]
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
On Thu, 29 Apr 2004, Marc Boucher wrote:
> 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.
While tainting is not merely a political scheme, but mainly a _practical_
one...
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected]
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
On Fri, Apr 30, 2004 at 11:33:20AM +0200, Geert Uytterhoeven wrote:
> On Fri, 30 Apr 2004, Matthias Schniedermeyer wrote:
> > 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.
sanity-checking prevents the worst failures. And, for this case:
AFAIR the "factory-default" is something like "everything enabled".
Bis denn
--
Real Programmers consider "what you see is what you get" to be just as
bad a concept in Text Editors as it is in women. No, the Real Programmer
wants a "you asked for it, you got it" text editor -- complicated,
cryptic, powerful, unforgiving, dangerous.
Timothy Miller wrote:
>
> 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...
"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 . . .
Helge Hafting
Marc Boucher wrote:
>
> Hi Helge,
>
> On Apr 28, 2004, at 7:47 AM, Helge Hafting wrote:
>
>> Marc Boucher wrote:
>>
>>> 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.
>
>
> We are not disobeying the terms nor is there anything in the GPL that
> prohibits specifically our workaround.
Binary modules are ok, although unpopular with some people.
There is nothing wrong with a proprietary driver module.
I have no problem with you making and selling this driver.
Tricks with the license string may very well be illegal though.
You cannot say that "this is GPL" when it isn't. Lying to people
about licences is illegal. I don't know about lying to a kernel
interface, but it _is_ a kind of licence management system .
> 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.
Someone else doing wrong does not give you right to do so. It could
be interesting to see an example of what you mean. Are you talking about
using proprietary software in ways the copyright holder didn't expect and
dislike, or about breaking a licence?
>>
>> 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.
No, it is not what you said. And I believe it wasn't what you meant either.
It was merely a warning that it is similiar.
>
>>
>>> 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.
>
>
> We are providing code as much as possible, without expecting free
> support, but are still getting flamed.
Again, your software is fine. The licence trickery is the only part that isn't.
And yes - if you circumvent the tainting then you _are_ creating an
expectation that the kernel is supported by the community, while
the community doesn't want to support it because of the proprietary code.
It doesn't help that the code serves a good purpose, is useful and
probably well-written. People here doesn't want to support a kernel
running code they cannot inspect. Of course this shouldn't stop
you from releasing such code, just don't try to hide it.
>>
>>> 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.
>
>
> 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.
An installation program can do that for them. (patch, compile,
install new kernel.) Or you can supply a precompiled
kernel for your customers. If that seems like much work, think of who
does that work now.
> 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.
>
Then you're out of luck if you need a big stack, and may consider
rewriting those NDIS drivers instead. The lesser problems with
multiple "tainted" messages has a userspace solution though.
>>> 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.
>
>
> 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.
>
Well, how about changing the logging level?
Surely your install scripts can do something with /proc/sys/kernel/printk ?
Helge Hafting
Linus Torvalds ha scritto:
>On Thu, 29 Apr 2004, Giuliano Colla wrote:
>
>
>>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.
>>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.
>
>
>
>>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.
>
>
>
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".
<..>
>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
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.
It only takes someone with reasonable hardware knowledge to be able to
script some simpleton program to be able to detect most hardware and load
the proper device driver AFTER the correct hardware/driver combination has
been determined.
This is a system-level issue, and not really a kernel level one, assuming
that all of the possible device drivers to be used has already been
built for the target architecture that you are trying to build this
system-level hardware detection package.
The Linux architecture is flexible and robust enough for somebody to be
able to detect hardware, simply by "walking" the general busses in the
proper respective order for the architecture that you are targeting.
There is no need to "brute force" load all device drivers in order to
discover what the user has on his/her system.
For PC architecture, this is a no brainer.
1) walk the PCI bus. Yes, it will already be supported because your Linux
kernel (if built by someone who knows something about what he is
doing) will already have it mapped out just fine after boot, no modules to load.
2) from your list, identify chipsets (this may not even be necessary). If
you know nothing about registers (ususally device 0, offset 0x0), just use lspci! (pcitools)
3) Identify controllers and hub types from that list (SCSI, IDE, USB, etc)
and load those device drivers. If you cannot determine which device driver
to load, then you probably shouldn't be writing this hardware detection
package in the first place.
4) continue down other busses and load their device drivers (walk the USB
bus, load whatever...)
This is an oversimplified approach to what is really not a killer problem.
I would not worry too much about distributions who are still doing things
the lazy way such as brute force loading all modules just because they
have no rhyme or reason to their hardware detection approach.
If they want errors to go away, they will be smarter about their approach.
It's not our job to worry about that for them.
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.
Arthur Perry
Lead Linux Developer / Linux Systems Architect
Validation, CSU Celestica
Sair/Linux Gnu Certified Professional, 2000
Project Manager, Linuxfarms
http://www.linuxfarms.com
On Fri, 30 Apr 2004, Giuliano Colla wrote:
> Linus Torvalds ha scritto:
>
> >On Thu, 29 Apr 2004, Giuliano Colla wrote:
> >
> >
> >>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.
>
> >>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.
> >
> >
> >
> >>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.
> >
> >
> >
> 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".
>
> <..>
>
> >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/
>
On Friday 30 of April 2004 06:32, Peter Williams wrote:
> Bartlomiej Zolnierkiewicz wrote:
> > On Friday 30 of April 2004 04:15, Marc Boucher wrote:
> >>Dear Sean,
> >>
> >>On Apr 29, 2004, at 7:55 PM, Sean Estabrooks wrote:
> >>>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).
> >
> > 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.
>
> 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."
It is unimportant here, using GPL-ed wrappers to load
closed-source drivers is like using LILO to boot Windows. ;)
Open-source drivers are one of the fundamental advantages
of Linux and drivers are part of operating system.
Splitting driver by "separating the proprietary code from the
operating-system specific code." weakens this advantage.
There is a question about integrity when you say that you promote
open-source nature of Linux but you don't promote open-source drivers.
Regards,
Bartlomiej
On Fri, 30 Apr 2004, Jeff Garzik wrote:
> 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).
Why didn't someone say that from the beginning, that what he (Marc
Boucher's company) is doing was to lower the cost of avoiding to support
the native Linux drivers and that is certainly damaging to us, though we
can't really do anything about it because it is fair and perfectly legal.
In fact, the only thing we can do is to make their life harder (i.e.
by being unfair) and reduce the number of GPL-exported symbols to almost
nothing.
Imho, it is best when people honestly state what the goal and the reasons
of debate are, instead of unacceptable and unfair techniques such as lying
about GPL directory content etc.
I think you (Jeff) have pointed out the key thing and it explained
everything very nicely (at least to me, it did). Thank you. I always found
your emails informative and to the point :)
Kind regards
Tigran
Tigran Aivazian wrote:
> On Fri, 30 Apr 2004, Jeff Garzik wrote:
>
>>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
Sean Estabrooks wrote:
> On Thu, 29 Apr 2004 18:24:58 -0400
> Marc Boucher <[email protected]> wrote:
>
>
>
>>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.
Giuliano Colla wrote:
> Linus Torvalds ha scritto:
>
>> On Thu, 29 Apr 2004, Giuliano Colla wrote:
>>
>>> 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.
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.
> 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?
> 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)
Was there anything else that could have been done for the existing fake
GPL modules?
> 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.
Carl-Daniel
Marc Boucher wrote:
>
> 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..
I'm one of the first persons who posted to this thread, and I'm starting to
regret that I did.
I believe Marc did the GPL\0 trick just to avoid the warnings. It was wrong to
do it and he already apologised.
IMHO writing a more descriptive message and not issuing the tainting warning
more than once *at all*, seems pretty harmless and would solve problems for
everyone and we could just move on with our lifes (this thread has almost 150
posts now!)
The only problem with reporting only once would be to have remove one module at
a time and rebooting until untainting. In my opinion, if your system is so out
of control that you don't know what modules are tainting it, you deserve to have
make 3 reboots to remove 3 modules :)
Some people feel that Linuxant isn't helping the comunnity because hardware
manufacturers won't feel obligated to release open source drivers if thay have a
closed source alternative.
IMHO what makes manufacturers care about Linux is market share. Until we have a
fair market share, manufacturers won't bother developing for Linux, because
their return on this effort will be minimal.
Linuxant is in fact helping Linux geting a bigger market share.
Anyway, as everyone on this list I strongly prefer open-source drivers. Users
prefer open-source drivers, specially if they already come with their
distribution and just work out-of-the-box.
So if the hardware manufacturers start caring about linux (because of the
increased market share), they will release open source drivers. Just look at the
manufacturers that produce hardware for high-end servers (where the Linux market
share is already very high). Network cards, RAID controllers, etc., already have
open source drivers, because of this.
Linux is taking over, it is just a matter of time now :)
--
Paulo Marques - http://www.grupopie.com
"In a world without walls and fences who needs windows and gates?"
Peter Williams wrote:
>> "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.
>
>
> 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.
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. Parts of the modules are indeed GPL, and the linked
in binary-only modem code isn't. 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.
Cordially
Marc
On Apr 30, 2004, at 11:43 AM, Chris Friesen wrote:
> Tigran Aivazian wrote:
>> On Fri, 30 Apr 2004, Jeff Garzik wrote:
>>> 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
>
>
>
Helge Hafting wrote:
> Timothy Miller wrote:
>
>>
>> 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...
>
>
> "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. :)
Marc Boucher wrote:
>
> 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".
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 reading the source that it isn't. If someone is given the precompiled
binary, short of disassembling it or doing research online there is no way for them to know that it
is not licensed under the GPL, as all the module tools, and the kernel itself, all interpret the
license string as GPL.
> I repeat, the \0 is purely a technical workaround, done without any
> mischievous intent.
I'm sure it was in fact done without mischievous intent. An argument could be made, however, that
by inserting the null character you are in fact telling the kernel that the entire module is GPL'd,
which is obviously not the case. In addition to that, you are forcing the tainted message to be
suppressed. Regardless of whether this caused any developer time to be wasted, the fact remains
that it *could* have.
> 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.
I understand that now that this has been brought up on the main kernel mailing list that you are
trying to fix it in a way that is acceptable to the kernel dev team. I just think it is unfortunate
that you shipped code with this workaround in it rather than finding some other way of accomplishing
what you were trying to do.
Chris
Marc Boucher wrote:
>
> 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
--
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
On Apr 30, 2004, at 12:31 PM, Gilles May wrote:
> Marc Boucher wrote:
>
>>
>> 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
>
> --
> If you don't live for something you'll die for nothing!
>
>
>
On Apr 30, 2004, at 11:57 AM, Timothy Miller wrote:
>
> 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.
We fully agree about the importance and sanctity of these rights.
>
> 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.
Absolutely and likewise, the rights of those who choose not to release
their own independently developed works under the GPL should be
respected.
>
> And furthermore, having a political agenda is not inherently wrong.
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.
Marc
Marc Boucher writes:
> 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):
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)
On Fri, 30 Apr 2004 13:14:46 -0400
Marc Boucher <[email protected]> wrote:
> <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.
Would you please drop this notion that this is somehow political. People
who are just as intelligent as you have looked at the facts and concluded
that your actions hurt Linux in a practical way. That's not a political
idea that's practical idea. Others are just concerned about support
issues. The point is you opinion isn't more important.
You cast everyone who has come to a different conclusion than you as a
political or religious zealot. This is just a way for you to demean
these people and not deal with their honest concerns and admit there's a
chance you're wrong. If you feel very strongly about going against the
wishes of the kernel maintainers I suggest you fork the kernel and do
whatever you want.
But since even you say you would rather see open source drivers over
proprietary how about asking for this warning:
"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."
That should remove any confusion and also show respect Linux and its
license.
Regards,
Sean
A couple days ago when I stumbled onto this discussion, I was prompted
to at least post an opinion from a user perspective. Having followed
along since then, I am beginning to wonder why I am so interested in
the Linux community in the first place. I have to admit, my chin is
still on the floor having read some of the personal attacks directed
towards Marc. Why, for some, has this become a personal issue and not a
technical one? I think Marc summed it up best (a few times) by saying:
>> I repeat, the \0 is purely a technical workaround, done without any
mischievous intent.
Can't we respect this as his explanation and move on so these efforts
can be better directed towards improving the kernel? Hell - Marc has
alot of work to-do in order for driverloader to be compatible with 4K
stacks ;) (BTW I have no idea how you can support Fedora but it is
appreciated.) There seems to be a couple posters here that understand
why this workaround was done and agree that there needs to be a better
way than seeing repeated "tainted" messages. In my opinion, this is the
perspective that should have been taken from the start. Or at least
once the list realized the intent and received Marc's appologies.
P.S. Thanks to those who offered your opinions in agreement with mine
via email but not on the list.
Respectfully,
Keith
----------------------------------------------
Mailblocks - A Better Way to Do Email
http://about.mailblocks.com/info
Tigran Aivazian wrote:
> On Fri, 30 Apr 2004, Jeff Garzik wrote:
>
>>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).
Nope. The real objection was misleading people about the license of the
module. That part was clearly wrong.
The fact that it dilutes Linux is a side-objection, and we're not making
an objection so much as a warning about the potential long-term effects.
This part isn't clearly wrong so much as something to be concerned about.
At least, that's MY opinion on it.
Arthur Perry ha scritto:
>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.
>
>
<snip>
I fully agree with you.
>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.
>
>
In that case particular they may notice, because they would get too
screenfull of errors, instead of just one!
>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.
>
>
>
You're right by the ethical point of view. But by practical point of
view, if you're a professional you knew everything beforehand, when you
dowloaded the piece of software, and had to accept an agreement which
has nothing to do with GPL.
--
Ing. Giuliano Colla
Direttore Tecnico
Copeca srl
Bologna Italy
Marc Boucher wrote:
>
> 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.
Your intent only matters slightly. Consider how courts would deal with
you killing someone:
(a) If you intended to kill someone and killed them, you are convicted
of murder or manslaughter (depending on the nature of the intent, etc.)
(b) If you did NOT intend to kill someone but could have prevented it,
you get convicted of gross neglegence.
(c) If you did not intend to kill someone and there is no way you could
have prevented it, you are found not guilty.
In your case, it seems that you did not intend to break the law, but you
did, AND you should have known that this was an iffy thing to do, and
you could have done more research to find out that you should not do it.
That would qualify you for (b), neglegence.
So, the fact that you didn't MEAN to do anything wrong doesn't absolve
you of the crime. It just means that your crime is different (and less
severe) from what it would have been if you'd meant to break the law.
No one is arguing your intent. I, and probably many others, buy your
argument that you didn't MEAN to cause any harm. You can tell us how
much you didn't mean it until you're blue in the face, and that's not
going to change anything, because we already BELIEVE you.
What you don't seem to understand is that what you did was wrong ANYWAY.
Some other points you miss:
- There is nothing slanderous about what we're saying. What you did is
illegal. Period.
- We're not telling you to stop what you're doing in general. We're
only telling you to fix the one thing that you did wrong so that we can
all move on.
- The only reason people keep harping on you about this is because you
keep missing the point that what you did was a bad thing, regardless of
why you did it.
What you did is kinda like the situation where some kid uses Kazaa to
download songs, but he doesn't realize that it's illegal. He doesn't
understand or appreciate the harm he's causing, because he doesn't see
how copying something (without taking away the original) could be a
problem. He doesn't understand that there's a big different beween real
property and intellectual property. You seem to share a similar
difficulty in understanding the harm that you're causing because so much
of it is very abstract. To further the analogy, we on LKML are acting
like a "nice" version of the RIAA; a nice RIAA would find someone who is
pirating music, find out that they didn't realize it was wrong, educate
them, and ask them to please stop pirating. We are not telling you that
we want to have you convicted of copyright violation; we are telling you
that you are committing copyright violation, and we want you to please stop.
The fact that you didn't realize it wasn't wrong doesn't make it not
wrong for you to do it.
Marc Boucher wrote:
>
> 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.
>
I don't recall reading any unsubstantiated claims.
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.
Sean Estabrooks wrote:
> "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."
I really like this wording too!
Keith D Burgess Jr wrote:
> A couple days ago when I stumbled onto this discussion, I was prompted
> to at least post an opinion from a user perspective. Having followed
> along since then, I am beginning to wonder why I am so interested in the
> Linux community in the first place. I have to admit, my chin is still on
> the floor having read some of the personal attacks directed towards
> Marc. Why, for some, has this become a personal issue and not a
> technical one? I think Marc summed it up best (a few times) by saying:
I never felt it was a personal issue. It's a technical problem, and
it's a legal problem.
No one faults Marc for what he wanted to do. We only fault him for the
way he went about doing it.
I'm ambivalent about the future impact of supporting companies who do
not want to develop open-source drivers, but I DO support Marc's right
to develop software which aids in using proprietary drivers under Linux
for the sake of users who otherwise could not use their hardware. That
is to say, there are certain philosophical aspects of developing such a
wrapper that concern me, but I respect Marc's right to do it anyway.
>
>>> I repeat, the \0 is purely a technical workaround, done without any
>
> mischievous intent.
>
> Can't we respect this as his explanation and move on so these efforts
> can be better directed towards improving the kernel?
We respect this explanation, but this explanation has nothing to do with
what we're complaining about, which is why this discussion continues.
It's like being asked why you stubbed your classmate's toe and
responding "because it's Thursday". Well, not THAT far off, but it
demonstrates my point.
We DO accept the fact that he didn't MEAN to break the law. It's just
not a valid excuse!
> Hell - Marc has
> alot of work to-do in order for driverloader to be compatible with 4K
> stacks ;) (BTW I have no idea how you can support Fedora but it is
> appreciated.) There seems to be a couple posters here that understand
> why this workaround was done and agree that there needs to be a better
> way than seeing repeated "tainted" messages. In my opinion, this is the
> perspective that should have been taken from the start. Or at least once
> the list realized the intent and received Marc's appologies.
And that's what's happening. It's Marc's insistence that he's innocent
on the grounds that he didn't mean it that has so many people all riled
up about it.
Yes, we're "letting him off" (ie. not suing for past infractions) on the
grounds that he didn't mean it, but we want him to understand why he
shouldn't have done it and stop doing it. He doesn't seem to understand
why it was wrong, and that bugs us.
If Marc had just said, "OOPS! Sorry. That was a stupid error on my
part. I'll fix it and never do it again," then this argument would
never have happened.
Mistakes happen all the time. We're just used to people who are able to
learn from their mistakes.
On Apr 30, 2004, at 1:44 PM, Michael Poole wrote:
> Marc Boucher writes:
>
>> 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;
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.
> 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.
On Apr 30, 2004, at 2:01 PM, Timothy Miller wrote:
>
> 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?
Marc
>
> 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)
>
On Apr 30, 2004, at 2:26 PM, Timothy Miller wrote:
>
> 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.
Great.
> So why are you continuing to defend yourself?
Because we are continuing to be attacked.
> Just get over it and move on.
Excellent advice, which I will now follow since explanations have been
duly given and this thread has sufficiently grown out of proportion
:-)
Regards
Marc
> WINE is a user process. It does not run in kernel space, so we don't
> care about it. Since all the closed-source stuff, like
> Office, runs in user space, it CANNOT corrupt the kernel (barring real
> kernel bugs).
>
> I think Linus needs to smack you down like he did with that guy who
> couldn't understand the distinction between firmware and a
> kernel driver.
I think he doesn't, because he can read what other said. I know what
distinction it is and I've been working on kernel for years since I was
still in school.
I'm not arguing about the taint issue, or any technical issue, as clearly
stated in my last paragraph. I am mearly responding to the questioning to
Linuxant's business model.
> As long as the kernel is protected, we are generally in favor of it.
>
> > Linuxant did a wrong thing by working around the warning
> > message, but I don't think it's fair to accuse of their business
> > because they allow binary drivers run on Linux.
>
> The fact that binary drivers are "evil" does not reflect badly on
> Linuxant, in my opinion.
It doesn't look like so to me.
Marc Boucher wrote:
>
> On Apr 30, 2004, at 1:44 PM, Michael Poole wrote:
>
>> Marc Boucher writes:
>>
>>> 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;
>
>
> 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.
No one here really wants to sue you. Those people who have been arguing
with you are doing so because they take you seriously. If they thought
you were a moron and you were worthless, they would be ignoring you.
I think I speak for many here when I say that we respect your business
and your right to write the sort of software that you're doing. We
would just like you make sure that you follow the law, for your own sake
as well as ours.
>
>> 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.
Well, I agree. Only one person invoked the DMCA. Others, such as
myself, invoked Copyright law, which more people agree with.
Look at it this way: You broke more than one law.
>
> 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.
Stop telling us how unintentional it was!
>
> On Apr 30, 2004, at 2:01 PM, Timothy Miller wrote:
>
>>
>> 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.
I am not aware that it's a common practice. Can you provide an example?
However, if someone else it doing it, they are wrong too, and that does
not give you license to imitate them.
> Would
> you pretend that things like Wine are wrong and misleading when making
> windows software believe that it runs under the real thing?
WINE is not a problem for Linux, because it cannot corrupt the kernel
(it's all in user space).
WINE is not a problem for Windows programs, because making a Windows
program misbehave in user space does not make the rest of the system
unstable, and it does not violate any laws. Also, people using WINE are
aware that they are using WINE and are therefore not surprised when
something doesn't work right. WINE isn't trying to hide from anyone the
fact that it's a compatibility layer.
On Fri, 30 Apr 2004, Hua Zhong wrote:
>
> I have not heard so much WINING about WINE. I even see kernel developers add
> more support in the kernel to support WINE. Why do people like to pick on
> closed-source drivers being run by a wrapper? I see nothing wrong with that.
What is so hard to understand about the problem with bugs?
All software has bugs. Binary modules just mean that those bugs are
- FATAL to the system, including possibly being a huge security hole.
- impossible to debug
- impossible to fix
In contrast, wine was _written_ to do this emulation, so by definition any
"bugs" are in wine itself (although I suspect that wine people sometimes
would prefer it if Office came with sources ;).
> Linuxant did a wrong thing by working around the warning message, but I
> don't think it's fair to accuse of their business because they allow binary
> drivers run on Linux.
Nobody has sued them over copyright infringement. What they are doing is
likely legal - APART from the fact that they lied about the license, which
is not only horribly immoral, it's also likely illegal under the DMCA.
Note: to me, the immoral part is the big one. If you want to flaunt the
DMCA and take the risk of the feds coming after you as a matter of civil
disobedience, all the more power to you. Let's not be hypocritical and
claim to like the DMCA.
But let's not kid about this: adding that '\0' thing to try to make the
kernel believe it was GPL'd code is not ethical, and there is no way to
claim that it's needed, since the _only_ thing it suppresses are a few
messages saying that the kernel is tainted as a result. Which it IS.
So don't bother trying to stand up for Linuxant. What they did was WRONG,
and there are no excuses for it. And I hope that they have it fixed
already and we can hereby just forget about this discussion.
Linus
Carl-Daniel Hailfinger ha scritto:
>Giuliano Colla wrote:
>
>
>>Linus Torvalds ha scritto:
>>
>>
>>
>>>On Thu, 29 Apr 2004, Giuliano Colla wrote:
>>>
>>>
>>>
>>>>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.
>>
>>
>
>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.
>
>
>
>
You're right, but in a laptop using the integrated modem is more
practical, with less stuff to carry, and less power involved. Provided
of course I do it at my own risk, and don't try to rebutt the troubles I
may get into to kernel people, which has more useful things to do, than
following my personal whims.
BTW on my previous laptop I had a Lucent winmodem, whose driver doesn't
fake the GPL license, but which was definitely inferior to the Linuxant
driver, except for the hardware probing stupid implementation.
I'm looking forward for a time when being "Designed for Linux" will be
more rewarding for a manufacturer than being "Designed for Windows" but
till then I must get along with what is available.
>>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?
>
>
>
>
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.
<snip>
>>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)
>>
>>
>
>Was there anything else that could have been done for the existing fake
>GPL modules?
>
>
>
>
Maybe I fail to grasp the full picture, but I'd just have ignored it.
Please remember that they "fake" GPL only at run-time, not when you get
them.
>>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.
>
>
>
>
If you download the "generic package with source" either rpm or tar.gz,
you'll find the GPL directory populated. I've checked again right now,
just to be sure. At least, this holds true for hsf modem, which is the
one I'm actually using.
If you're interested, and have time, you may also estimate if they've
implemented in the GPL part all of the critical kernel code (as I had
assumed, maybe naively, from a cursory look to the code), leaving in the
proprietary binaries only the "proprietary" compression/decompression
algorithms, or if they've just provided a minimal wrapper, with all
"real" code proprietary.
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.
--
Ing. Giuliano Colla
Direttore Tecnico
Copeca srl
Bologna Italy
On Fri, 30 Apr 2004, Keith D Burgess Jr wrote:
> A couple days ago when I stumbled onto this discussion, I was prompted
> to at least post an opinion from a user perspective. Having followed
> along since then, I am beginning to wonder why I am so interested in
> the Linux community in the first place. I have to admit, my chin is
> still on the floor having read some of the personal attacks directed
> towards Marc. Why, for some, has this become a personal issue and not a
> technical one? I think Marc summed it up best (a few times) by saying:
>
> >> I repeat, the \0 is purely a technical workaround, done without any
> mischievous intent.
>
> Can't we respect this as his explanation and move on so these efforts
> can be better directed towards improving the kernel? Hell - Marc has
> alot of work to-do in order for driverloader to be compatible with 4K
> stacks ;) (BTW I have no idea how you can support Fedora but it is
> appreciated.) There seems to be a couple posters here that understand
> why this workaround was done and agree that there needs to be a better
> way than seeing repeated "tainted" messages. In my opinion, this is the
> perspective that should have been taken from the start. Or at least
> once the list realized the intent and received Marc's appologies.
>
> P.S. Thanks to those who offered your opinions in agreement with mine
> via email but not on the list.
>
> Respectfully,
> Keith
>
>
Well it works like this:
Presume you devoted a lot of time and effort to writing
a driver for a popular SCSI Disk controller.
All of the sudden, you get a rash of complaints that
your driver is crashing systems, trashing data or otherwise
creating havoc.
So, you spend a few hundred hours of your time going over
the code line-by-line and you can't find anything wrong.
Also, you keep getting hate mail from persons who claim
that you have destroyed a lifetime of work because your
controller trashed their data.
Eventually you find that some software for a "@!&*($^@*(%"
screen card is trashing your code. That's the reason why
you've been getting blamed for destroying everybody's
data. You can't look at the software for that screen-card
because some idiot in Marketing thought that the 200 lines
of Linux-trashing software was "proprietary".
So, you make sure that if anybody in the future writes
such trash or potential trash and loads it into the kernel
where there is no protection from it, it is appropriately
marked.
Then, when somebody sends you a crash-dump and it is marked
"Tainted", you can tell them to unload whatever drivers are
causing that effect and then try your driver again. This
will save you untold weeks of agony in the future.
Now we have somebody who decides to "beat the system", to
allow tainted modules without them being displayed. Of
course the persons who have wasted a significant portion
of their lives looking for bugs that were caused by
secret drivers, will get a might bit angry.
Everybody has a right to load any kind of manure they
want into their own copy of the kernel. They don't have
any right to subject innocent module-writers to the
poison of a module they can't inspect.
Also, a module that is loaded into the kernel can
do __anything__. It can inspect the contents of your
hard disks and send whatever it wants to some unfriendly
company (Like Back-web). It can send information about
the letters you write and the Web Pages you frequent
(like Carnivore). It can use your CPU resources to
compile a security-liability index about your life-
style and send the results to the NSA (like Magic Lantern).
Certainly you should want to inspect anything that
is running on your system. This means that you need
to be able to inspect the source-code.
Cheers,
Dick Johnson
Penguin : Linux version 2.4.26 on an i686 machine (5557.45 BogoMips).
Note 96.31% of all statistics are fiction.
My last email on this topic. If it weren't Linus I would have stopped. :-)
> What is so hard to understand about the problem with bugs?
>
> All software has bugs. Binary modules just mean that those bugs are
> - FATAL to the system, including possibly being a huge security hole.
> - impossible to debug
> - impossible to fix
It's the user's choice to run binary modules on their systems, as long as
the "tainted" issue is not hidden (which I clearly said was wrong) so the
support burden is directed to the right company/person who will hopefully
fix those bugs, why should it concern kernel developers so much? Let the
user have a choice. A working computer which occasionally crashes is still
better to the user than a stable computer which doesn't do the job.
In this sense, it doesn't matter it's a bug in user space or kernel space,
or hard or easy to fix, as long as it doesn't cause much extra burden to the
community.
All I try to say is about the business model of supporting closed-source
drivers by a GPL'ed wrapper. It may not be perfect in an imperfect world,
but nothing to criticize on.
> So don't bother trying to stand up for Linuxant. What they
> did was WRONG, and there are no excuses for it. And I hope
> that they have it fixed already and we can hereby just forget
> about this discussion.
You don't need to tell me why it was wrong, because I already said it was
wrong. :-) I'm not standing up for linuxant either - I am not their
customers and I hardly heard of this name before. I'm just standing up for a
generic issue (which is often silly).
And I agree we should stop this thread now.
> Linus
>
>>And I agree we should stop this thread now.
One thing that seems consistent here is that most agree on this point.
To add a bit of comedy, picture this at the place you work:
Mistakenly, a broadcast email goes out to everyone (ooops should have
restricted the total number of users in the to/cc/bcc fields). Then
your IT security group sends out a broadcast telling everyone to delete
it and not to "reply to all." You continue to get people replying to
all with the body as below:
"Didn't you see the IT security bulletin? It said not to reply to all
but to delete this email!"
I am sensing that is what we are all doing here :) (myself included).
----------------------------------------------
Mailblocks - A Better Way to Do Email
http://about.mailblocks.com/info
On Friday 30 April 2004 11:10, Timothy Miller wrote:
> Peter Williams wrote:
> >> "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.
> >
> > 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.
And worse -
It hangs the users out to dry if the vendor drops support of the
driver/hardware.
With full source code the community or the user would be able to continue
to update/fix the driver for new kernels.
Like Hua said, this ought to be "my last email on this topic. If it
weren't Linus I would have stopped. :-)"
On Apr 30, 2004, at 3:19 PM, Linus Torvalds wrote:
>
> On Fri, 30 Apr 2004, Hua Zhong wrote:
>>
>> I have not heard so much WINING about WINE. I even see kernel
>> developers add
>> more support in the kernel to support WINE. Why do people like to
>> pick on
>> closed-source drivers being run by a wrapper? I see nothing wrong
>> with that.
>
> What is so hard to understand about the problem with bugs?
>
> All software has bugs. Binary modules just mean that those bugs are
> - FATAL to the system, including possibly being a huge security hole.
> - impossible to debug
> - impossible to fix
All bugs are possibly fatal, or huge security holes, regardless of
whether they are in binary-only code or open-source.
All bugs can be debugged or fixed, it's a matter of how hard it is to
do (generally easier with open-source) and *who* is responsible for
doing it (i.e. supporting the modules).
>
> In contrast, wine was _written_ to do this emulation, so by definition
> any
> "bugs" are in wine itself (although I suspect that wine people
> sometimes
> would prefer it if Office came with sources ;).
The same can be said about DriverLoader.
>
>> Linuxant did a wrong thing by working around the warning message, but
>> I
>> don't think it's fair to accuse of their business because they allow
>> binary
>> drivers run on Linux.
>
> Nobody has sued them over copyright infringement. What they are doing
> is
> likely legal - APART from the fact that they lied about the license,
> which
> is not only horribly immoral, it's also likely illegal under the DMCA.
The purpose of the workaround is not to circumvent any protection, but
to fix a real usability issue for systems in the field, which, as an
expert you perhaps do not see, but users definitely massively felt and
complained about.
>
> Note: to me, the immoral part is the big one. If you want to flaunt the
> DMCA and take the risk of the feds coming after you as a matter of
> civil
> disobedience, all the more power to you. Let's not be hypocritical and
> claim to like the DMCA.
I don't see our actions as being immoral at all. But in retrospect, I
admit that the issue should have been differently handled (i.e. by
sending patches, and perhaps starting a discussion on the lkml before
implementing a workaround).
> But let's not kid about this: adding that '\0' thing to try to make the
> kernel believe it was GPL'd code is not ethical, and there is no way to
> claim that it's needed, since the _only_ thing it suppresses are a few
> messages saying that the kernel is tainted as a result. Which it IS.
Most kernels are already potentially "tainted" by the use of
proprietary binary-only BIOS code, use of non-standard custom patches,
reliance on untrusted external data, etc.. This illustrates that the
MODULE_LICENSE tainting concept is flawed, and needlessly
scary/confusing for users.
>
> So don't bother trying to stand up for Linuxant.
I can understand that you do not really like what we are doing to
provide alternative options so that people can use otherwise
unsupported hardware.
> What they did was WRONG,
> and there are no excuses for it.
But the main justification for the regrettable \0 trick remains that
the tainted messages are redundant, confusing, and do not convey key
information (i.e. who is responsible for supporting the third-party
module) to ordinary users.
> And I hope that they have it fixed
> already and we can hereby just forget about this discussion.
We are working on a new release, which will be on the website shortly.
And I hope that you will agree to deal with the root problem by
incorporating some of the suggestions (or equivalent ones) that people
have made to fix the messages.
> Linus
>
>
Regards
Marc
On Friday 30 of April 2004 20:47, Timothy Miller wrote:
> Hua Zhong wrote:
> > Linuxant did a wrong thing by working around the warning message, but I
> > don't think it's fair to accuse of their business because they allow
> > binary drivers run on Linux.
IMHO open-source drivers are one of the biggest advantages of Linux.
Linuxant seems to be using double standards: we are all for open-source OS but
_our_ drivers have to remain proprietary (I don't care about reasons here).
Marc, I _appreciate_ all your hard-work on open-source projects and I can
understand reasons why Linuxant makes it's drivers but please, be honest. :)
I think that you agree that things like HSF drivers or DriverLoader
(because they are workarounds not the real solution) _may_ slow down creation
of real open-source drivers.
I also hope that this '\0' issue won't scare you from working with
community in the future.
Regards,
Bartlomiej
Giuliano Colla wrote:
> 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.
Most people don't actually read those licenses. Yes, it was very smart
of you to read that license. It is not people like you that we are
worried about.
On Fri, 30 Apr 2004, Marc Boucher wrote:
>
> > In contrast, wine was _written_ to do this emulation, so by definition
> > any
> > "bugs" are in wine itself (although I suspect that wine people
> > sometimes
> > would prefer it if Office came with sources ;).
>
> The same can be said about DriverLoader.
.. but not abotu the kernel that it depends on.
In other words, if driverloader was a stand-alone project, you could do
whatever the hell you wanted with it.
But it isn't a standalone project, is it? It depends on the kernel, and
there is no question that driverloader is a derived work.
Which means that you had better follow the rules.
So stop yer whining. When you write your own operating system, and your
driver doesn't have to depend on anybody elses code, then you can set the
rules. As it is, the kernel requires modules to tell it their license, and
if you lie to it, that is not only potentially violating the DMCA, it's
also likely a crime under regular copyright laws (ie you are knowingly
misrepresenting a license - in this case the license of the binary part,
and that's not legal either).
> The purpose of the workaround is not to circumvent any protection, but
> to fix a real usability issue for systems in the field, which, as an
> expert you perhaps do not see, but users definitely massively felt and
> complained about.
Oh, so it's ok to do something illegal, because it helps usability? And
ethics take second place to "the user doesn't want to see that line in the
logs"?
Sure, that's a good argument. NOT.
GET RID OF YOUR LYING LICENSE LINE!
Linus
Keith D Burgess Jr <[email protected]> said:
> A couple days ago when I stumbled onto this discussion, I was prompted
> to at least post an opinion from a user perspective. Having followed
> along since then, I am beginning to wonder why I am so interested in
> the Linux community in the first place. I have to admit, my chin is
> still on the floor having read some of the personal attacks directed
> towards Marc. Why, for some, has this become a personal issue and not a
> technical one? I think Marc summed it up best (a few times) by saying:
>
> >> I repeat, the \0 is purely a technical workaround, done without any
> >> mischievous intent.
Exactly the same way a lockpick is a "purely technical workaround" for
doors the owner "accidentally" locked...
> Can't we respect this as his explanation and move on so these efforts
> can be better directed towards improving the kernel?
Very true.
> Hell - Marc has
> alot of work to-do in order for driverloader to be compatible with 4K
> stacks ;)
His efforts should better be directed at getting real (open source) support
in place. But it is his calling in the end, I don't presume to decide what
he should do with his time. As long as the relevant licenses (and hopefully
also the wishes of the creators of the kernel) are respected.
--
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
Hi.
> The purpose of the workaround is not to circumvent any protection, but
> to fix a real usability issue for systems in the field, which, as an
> expert you perhaps do not see, but users definitely massively felt and
> complained about.
That's like saying that someone hates getting a speeding ticket from
those automatic cameras that are cropping up everywhere now.
He then promptly removes his license plate so he can't be tracked and
then he can continue to speed along.
Now - To the entity that is issuing tickets it appears that that
person is now a law abiding citizen and does not speed anymore when
in truth he removed the plate so it would appear that way.
The speeding ticket is printed message.
Yes, it might or should be changed to print it once or once
per $MODULE_VENDOR or license or whatever, but the issue remains.
It wasn't YOU that installed the speed camera nor set the speed
limits (ie created the tained flag and the code that prints a
message when such a module is inserted) but claiming that
"but it's only a workaround because I was getting so many tickets"
doesn't make it any better.
Yes, Linux is such an open system that a user can install a kernel
that doesn't print anything for tained kernels (remove speed cameras)
but that doesn't mean that YOU can do anything about it from the side
of the car (module).
Also note that neither the speed camera nor the kernel actually make
any limits on speeding (loading proprietary modules).
// Stefan
Something occurred to me...
It does take some time to get patches to propogate onto people's
computers. Linuxant has the problem that they have to be able to work
in lots of different already-deployed kernels.
I get the impression that Linuxant attempts to load and try a large
number of drivers in order to detect hardware. While that isn't
necessarily the best way to probe for devices, I can see why it would be
unpleasant to have numerous "taint" messages print out in the general case.
The best solution to this would be both legal (in the sense of them
being licensed to do this) and solve Linuxant's problem. How to do this?
Linuxant could have posed this problem to LKML and gotten permission to
do something "questionable", which is what I am going to suggest:
First: Do the "GPL\0" thing with the permission of LKML members,
conditioned on the next two steps.
Second: Make the Linuxant loader program print out a message that
explains to users that the kernel is really being tainted, even though
it doesn't look that way, and also that same message needs to get into
appropriate system logs.
Third: Find some way to force on the "tainted" flag in the kernel
after all the module load attempts have been finished.
I'm not declaring this to be THE solution It might be crap. But the
Linux community does enjoy cooperating with people who are trying to do
good things and need help. An argument can be made that there is some
benefit to what Linuxant does, and that argument is strong enough that
enough people would probably agree to this sort of compromize.
In fact, in my opinion, if I were a major kernel contributor, I wouldn't
mind the "questionable workaround" at all if the consequences of it were
deal with by forcing the "tainting" flag on after the tainting flag had
been defeated.
Make sense?
On Apr 30, 2004, at 4:26 PM, Linus Torvalds wrote:
>
> On Fri, 30 Apr 2004, Marc Boucher wrote:
>>
>>> In contrast, wine was _written_ to do this emulation, so by
>>> definition
>>> any
>>> "bugs" are in wine itself (although I suspect that wine people
>>> sometimes
>>> would prefer it if Office came with sources ;).
>>
>> The same can be said about DriverLoader.
>
> .. but not abotu the kernel that it depends on.
>
> In other words, if driverloader was a stand-alone project, you could do
> whatever the hell you wanted with it.
To clarify this important point, driverloader is a standalone project,
and structured similarly to the HSF driver (all os-specific code is
open-source allowing it to be used with any kernel or even
theoretically any other x86 operating system).
Because only one logical module is loaded, and a single set of tainted
messages bearable, the \0 MODULE_LICENSE() workaround is unnecessary
and not used in driverloader.
Marc
On Fri, 30 Apr 2004 16:39:01 -0400
Marc Boucher <[email protected]> wrote:
> To clarify this important point, driverloader is a standalone project,
> and structured similarly to the HSF driver (all os-specific code is
> open-source allowing it to be used with any kernel or even
> theoretically any other x86 operating system).
>
> Because only one logical module is loaded, and a single set of tainted
> messages bearable, the \0 MODULE_LICENSE() workaround is unnecessary
> and not used in driverloader.
>
After 150+ messages not even one concept that's been mentioned has pierced
the fog of your self righteousness has it? Please just try to respect
the people who bring you Linux.
Sean.
On Fri, 30 Apr 2004, Marc Boucher wrote:
> >
> > In other words, if driverloader was a stand-alone project, you could do
> > whatever the hell you wanted with it.
>
> To clarify this important point, driverloader is a standalone project,
> and structured similarly to the HSF driver (all os-specific code is
> open-source allowing it to be used with any kernel or even
> theoretically any other x86 operating system).
The Linux-centric parts are absolutely NOT stand-alone, and one big part
of that Linux-centric stuff is that magic line that says MODULE_LICENSE().
In other words, you're a weasel.
Linus
On Apr 30, 2004, at 4:44 PM, Linus Torvalds wrote:
>
> The Linux-centric parts are absolutely NOT stand-alone, and one big
> part
> of that Linux-centric stuff is that magic line that says
> MODULE_LICENSE().
>
are you claiming that anything that uses the MODULE_LICENSE() macro
becomes a derived work of the Linux kernel subject to the GPL?
Marc
On Fri, 30 Apr 2004, Marc Boucher wrote:
>
> are you claiming that anything that uses the MODULE_LICENSE() macro
> becomes a derived work of the Linux kernel subject to the GPL?
I'm claiming that you are wilfully misrepresenting the license of your
code to another piece of code THAT YOU DON'T CONTROL.
I'm further claiming that this is unethical and quite possibly illegal.
How hard is that to understand? Remove that stupid lying line. Pronto.
How the _hell_ can you stand up for lying in public? Have you no shame?
Linus
On Friday 30 April 2004 12:20, Timothy Miller wrote:
>Helge Hafting wrote:
>> Timothy Miller wrote:
>>> 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...
>>
>> "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. :)
>
I'm on this side of the fence too. There are some vendors whose gear
I will not knowingly buy, memorex being one of them after I got a
device damaged by a power surge from nearby lightning, and was
summarily told by the telephone support dweebs that they did NOT
support linux, and that my warranty was worthless if it was ever
hooked to a linux box. Hieing myself back to the dealer, he tried it
on a windows box, and it indeed was broken as far as the passthru was
concerned, but it almost made a picture so that was good enough for
them and I was told to go piss up a rope.
We should, and really, no dis-respect for Marc is intended here,
demand that the drivers furnished for linux be 100% open source.
I have an nvidia card, but run the nv driver for exactly that reason.
>-
>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/
--
Cheers, Gene
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
99.22% setiathome rank, not too shabby for a WV hillbilly
Yahoo.com attornies please note, additions to this message
by Gene Heskett are:
Copyright 2004 by Maurice Eugene Heskett, all rights reserved.
Indeed. The driver in question contains 8 interdependent modules. What
we were thinking of doing to settle the issue short-term in a fair way
for both our users and kernel developers, is removing the \0 from the
central one (hsfengine), causing the kernel to be properly tainted and
one instance of the messages to be automatically printed when the
driver is used.
Hopefully the community will view this as an acceptable compromise.
Once patches have propagated onto people's computers, we will be happy
to remove all \0's completely.
Marc
On Apr 30, 2004, at 4:47 PM, Timothy Miller wrote:
> Something occurred to me...
>
> It does take some time to get patches to propogate onto people's
> computers. Linuxant has the problem that they have to be able to work
> in lots of different already-deployed kernels.
>
> I get the impression that Linuxant attempts to load and try a large
> number of drivers in order to detect hardware. While that isn't
> necessarily the best way to probe for devices, I can see why it would
> be unpleasant to have numerous "taint" messages print out in the
> general case.
>
> The best solution to this would be both legal (in the sense of them
> being licensed to do this) and solve Linuxant's problem. How to do
> this?
>
>
> Linuxant could have posed this problem to LKML and gotten permission
> to do something "questionable", which is what I am going to suggest:
>
> First: Do the "GPL\0" thing with the permission of LKML members,
> conditioned on the next two steps.
>
> Second: Make the Linuxant loader program print out a message that
> explains to users that the kernel is really being tainted, even though
> it doesn't look that way, and also that same message needs to get into
> appropriate system logs.
>
> Third: Find some way to force on the "tainted" flag in the kernel
> after all the module load attempts have been finished.
>
>
> I'm not declaring this to be THE solution It might be crap. But the
> Linux community does enjoy cooperating with people who are trying to
> do good things and need help. An argument can be made that there is
> some benefit to what Linuxant does, and that argument is strong enough
> that enough people would probably agree to this sort of compromize.
>
>
> In fact, in my opinion, if I were a major kernel contributor, I
> wouldn't mind the "questionable workaround" at all if the consequences
> of it were deal with by forcing the "tainting" flag on after the
> tainting flag had been defeated.
>
> Make sense?
>
Marc Boucher wrote:
>
>
> On Apr 30, 2004, at 4:44 PM, Linus Torvalds wrote:
>
>>
>> The Linux-centric parts are absolutely NOT stand-alone, and one big part
>> of that Linux-centric stuff is that magic line that says
>> MODULE_LICENSE().
>>
>
> are you claiming that anything that uses the MODULE_LICENSE() macro
> becomes a derived work of the Linux kernel subject to the GPL?
Well, some people might argue that, but let's put that aside for the
moment. I think one of the things he's implying is that anything which
says MODULE_LICENSE("GPL") (which is what your driver did) is required
to actually BE under the GPL.
Technically, since the Linux kernel headers are under GPL, including
them into your code does make your code a derived work. However, people
are allowed to slide on this in certain strict circumstances, especially
when MODULE_LICENSE doesn't say the license is GPL.
On Fri, 30 Apr 2004, Marc Boucher wrote:
> Hopefully the community will view this as an acceptable compromise.
> Once patches have propagated onto people's computers, we will be happy
> to remove all \0's completely.
I didn't see any patches. Does that mean you plan to
continue your potential violation of copyright law
forever ?
--
"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
Marc Boucher wrote:
>
> Indeed. The driver in question contains 8 interdependent modules. What
> we were thinking of doing to settle the issue short-term in a fair way
> for both our users and kernel developers, is removing the \0 from the
> central one (hsfengine), causing the kernel to be properly tainted and
> one instance of the messages to be automatically printed when the driver
> is used.
>
> Hopefully the community will view this as an acceptable compromise. Once
> patches have propagated onto people's computers, we will be happy to
> remove all \0's completely.
>
At this point, you're not going to get any slack. If this is what you'd
done to start with, you might have gotten away with it. As it stands,
you appear to be unwilling to comply with the rules, except as a last
resort when you've been flamed for days.
I think what you need to do right now is do a lot of begging. I agree
that in principle, it's only technically necessary to have one of the
modules taint the kernel. But it's still "bad" to lie about the module
license and should only be done after much scrutiny and discussion.
So if everyone who has a stake in this agrees to let you do it, then go
ahead. Otherwise, sorry Charley, but you're SOL.
I had proposed this compromise in good faith to Rusty at the very
beginning of the debate but have not received an answer about it from
him yet.
Since it appears impossible to get formal "approval" from a "community"
composed of very diverse elements (for better and for worse) we will
probably implement this short-term solution to restore tainting.
Regards
Marc
On Apr 30, 2004, at 5:38 PM, Timothy Miller wrote:
>
> Marc Boucher wrote:
>> Indeed. The driver in question contains 8 interdependent modules.
>> What we were thinking of doing to settle the issue short-term in a
>> fair way for both our users and kernel developers, is removing the \0
>> from the central one (hsfengine), causing the kernel to be properly
>> tainted and one instance of the messages to be automatically printed
>> when the driver is used.
>> Hopefully the community will view this as an acceptable compromise.
>> Once patches have propagated onto people's computers, we will be
>> happy to remove all \0's completely.
>
> At this point, you're not going to get any slack. If this is what
> you'd done to start with, you might have gotten away with it. As it
> stands, you appear to be unwilling to comply with the rules, except as
> a last resort when you've been flamed for days.
>
> I think what you need to do right now is do a lot of begging. I agree
> that in principle, it's only technically necessary to have one of the
> modules taint the kernel. But it's still "bad" to lie about the
> module license and should only be done after much scrutiny and
> discussion.
>
> So if everyone who has a stake in this agrees to let you do it, then
> go ahead. Otherwise, sorry Charley, but you're SOL.
>
On Fri, 2004-04-30 12:37:26 -0700, Hua Zhong <[email protected]>
wrote in message <[email protected]>:
> user have a choice. A working computer which occasionally crashes is still
> better to the user than a stable computer which doesn't do the job.
WHAT!? I'm sorry, but to my eyes, an unstable computer is worth nothing.
If I can't somewhat trust my machine, I'll take paper and pencil...
However, I don't see a solution towards stopping companies from making
(partially) binary-only drivers.
Maybe we'd start to put more effort into disassemblers/re-assemblers and
code-generators from disassembly dumps.
Maybe we can use a simple solution: Only allow modules that contain full
debug info :)
MfG, JBG
--
Jan-Benedict Glaw [email protected] . +49-172-7608481
"Eine Freie Meinung in einem Freien Kopf | Gegen Zensur | Gegen Krieg
fuer einen Freien Staat voll Freier B?rger" | im Internet! | im Irak!
ret = do_actions((curr | FREE_SPEECH) & ~(NEW_COPYRIGHT_LAW | DRM | TCPA));
On Wed, 2004-04-28 at 11:56 -0700, Keith D Burgess Jr wrote:
> In summary, I firmly feel that there needs to be a mindset change if
> Linux is to eat away at Windows market share on the desktops. Let's
> take a certain Linux distributor as an example; here is a quote from a
> recent posting on the 4K stacks issue:
Quite frankly I don't give a two hoots about market share. If I wanted
my code to be used by third parties _without_ them having to free their
own code, then I'd have contributed to a BSD-licensed kernel instead of
a GPL'd kernel; or I'd have dual-licensed it.
If you think the BSD approach is so much more conducive to market share,
and if you think market share is more important than freedom, then go
elsewhere. Maybe you can use Windows -- that has BSD code in it, doesn't
it? Or MacOS X perhaps? I don't really care much -- just go away.
> "Too bad. External binary modules never have, and never will hold back
> development. NVIDIA need to issue driver updates that work accordingly."
>
> Reworded from a user-focused perspective:
Reworded from a copyright-holder's perspective:
"Use a copy of my work outside the terms of its licence, and other than
provided for by 'Fair Use' doctrine¹, and you are committing a criminal
offence."
--
dwmw2
¹ cf. http://www.hmso.gov.uk/acts/acts1988/Ukpga_19880048_en_4.htm
On Fri, Apr 30, 2004 at 04:11:29PM -0400, Marc Boucher wrote:
>
> The purpose of the workaround is not to circumvent any protection, but
> to fix a real usability issue for systems in the field, which, as an
> expert you perhaps do not see, but users definitely massively felt and
> complained about.
>
You have argued this a lot of times during this thread and I want to say
smoenthing about that. I have used some binary-only modules: nvidia,
vmware and some time ago HSF drivers. When I installed the nvidia
propetary driver was the first time I saw the word 'tainted' and it
makes sense: I was at the console.
I mean that most of users work on X (except when installing X drivers
:)) and probably they will never see this "confusing" warnings.
When my system boots, it loads the nvidia and vmware modules and most of
time (I could say always) I don't notice that my kernel is tainted
(though I know) so I don't see the reason to hide the license.
I think it should be good for all to stop flaming and put some things in
order. You have lied about the license and it seems you want to keep
lying so -quoting Linus- it seems you don't have shame.
Cheers,
Koke
--
"S?lo el ?xito diferencia al genio del loco"
Blog: http://www.amedias.org/koke
Web Personal: http://sindominio.net/~koke/
JID: [email protected]
Timothy Miller <[email protected]> said on Fri, 30 Apr 2004 17:38:25 -0400:
>
>
> Marc Boucher wrote:
> >
> > Indeed. The driver in question contains 8 interdependent modules. What
> > we were thinking of doing to settle the issue short-term in a fair way
> > for both our users and kernel developers, is removing the \0 from the
> > central one (hsfengine), causing the kernel to be properly tainted and
> > one instance of the messages to be automatically printed when the driver
> > is used.
> >
> > Hopefully the community will view this as an acceptable compromise. Once
> > patches have propagated onto people's computers, we will be happy to
> > remove all \0's completely.
...
> I think what you need to do right now is do a lot of begging. I agree
> that in principle, it's only technically necessary to have one of the
> modules taint the kernel. But it's still "bad" to lie about the module
> license and should only be done after much scrutiny and discussion.
What's wrong with the printk setting workaround? Simply write a number
to the appropriate file before you load the modules.
I just tried googling for the relevant post, but failed...
He doesn't need to wait for the patches to propogate. He can act on
his own scripts immediately in readiness for the next version.
Easy.
--
TimC -- http://astronomy.swin.edu.au/staff/tconnors/
Modus Ponens in action:
- Nothing is better than world peace.
- A turkey sandwich is better than nothing.
==> Ergo, a turkey sandwich is better than world peace.