[PATCH] Blacklist binary-only modules lying about their license

[PATCH] Blacklist binary-only modules lying about their license

[Carl-Daniel Hailfinger]

[-- Attachment #1: Type: text/plain, Size: 728 bytes --]

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
-- 
http://www.hailfinger.org/

[-- Attachment #2: module_blacklist.diff --]
[-- Type: text/plain, Size: 1808 bytes --]

--- 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,

Re: [PATCH] Blacklist binary-only modules lying about their license

[Gilles May]

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!

Re: [PATCH] Blacklist binary-only modules lying about their license

[Zwane Mwaikambo]

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.

Re: [PATCH] Blacklist binary-only modules lying about their license

[Carl-Daniel Hailfinger]

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/

Re: [PATCH] Blacklist binary-only modules lying about their license

[Linus Torvalds]

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

Re: [PATCH] Blacklist binary-only modules lying about their license

[Rusty Russell]

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

Re: [PATCH] Blacklist binary-only modules lying about their license

[Jan-Benedict Glaw]

[-- Attachment #1: Type: text/plain, Size: 2033 bytes --]

On Tue, 2004-04-27 16:04:06 +1000, Rusty Russell <rusty@rustcorp.com.au>
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       jbglaw@lug-owl.de    . +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));

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [PATCH] Blacklist binary-only modules lying about their license

[Carl-Daniel Hailfinger]

Jan-Benedict Glaw wrote:
> On Tue, 2004-04-27 16:04:06 +1000, Rusty Russell <rusty@rustcorp.com.au>
> 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/

Re: [PATCH] Blacklist binary-only modules lying about their license

[Paulo Marques]

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 - www.grupopie.com
"In a world without walls and fences who needs windows and gates?"

Re: [PATCH] Blacklist binary-only modules lying about their license (-> possible GPL violation :)

[Jan-Benedict Glaw]

[-- Attachment #1: Type: text/plain, Size: 922 bytes --]

On Tue, 2004-04-27 13:59:48 +0100, Paulo Marques <pmarques@grupopie.com>
wrote in message <408E5944.8090807@grupopie.com>:
> 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       jbglaw@lug-owl.de    . +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));

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [PATCH] Blacklist binary-only modules lying about their license (-> possible GPL violation :)

[Tim Connors]

Jan-Benedict Glaw <jbglaw@lug-owl.de> 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 <pmarques@grupopie.com>
> wrote in message <408E5944.8090807@grupopie.com>:
> > 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.

Re: [PATCH] Blacklist binary-only modules lying about their license

[Juergen E. Fischer]

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

Re: [PATCH] Blacklist binary-only modules lying about their license

[Pavel Machek]

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         

Re: [PATCH] Blacklist binary-only modules lying about their license

[Timothy Miller]

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.

Re: [PATCH] Blacklist binary-only modules lying about their license

[Junio C Hamano]

>>>>> "PM" == Paulo Marques <pmarques@grupopie.com> 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 :).

Re: [PATCH] Blacklist binary-only modules lying about their license

[Valdis.Kletnieks]

[-- Attachment #1: Type: text/plain, Size: 602 bytes --]

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....



[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]

Re: [PATCH] Blacklist binary-only modules lying about their license

[Rik van Riel]

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

Re: [PATCH] Blacklist binary-only modules lying about their license

[Pavel Machek]

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         

Re: [PATCH] Blacklist binary-only modules lying about their license

[Willy Tarreau]

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 "support_XXX@author.com" 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

Re: [PATCH] Blacklist binary-only modules lying about their license

[Grzegorz Piotr Jaskiewicz]

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 "support_XXX@author.com" 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 linux-kernek@vger.kernel(.org) there :-)
You never know...

--
GJ

Re: [hsflinux] [PATCH] Blacklist binary-only modules lying about their license

[Giuliano Colla]

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

Re: [hsflinux] [PATCH] Blacklist binary-only modules lying about their license

[viro]

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.

Re: [hsflinux] [PATCH] Blacklist binary-only modules lying about their license

[Måns Rullgård]

viro@parcelfarce.linux.theplanet.co.uk writes:

> 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.

But they could make just as big a mess if they released the source
code, right?  And it would be just as hard to know which driver to
blame.  IF you manage to isolate the fault to one driver, it's
probably easier to see what it's doing, and possibly fix it if the
code is open.  Some driver code I've seen is so messy that it doesn't
really make a difference if you have the code or not.

Don't get me wrong now.  I much prefer open source drivers.  Those can
be compiled on any architecture (unless stupid bugs prevent that,
which I've seen many cases of) and with the newest kernel releases.

-- 
Måns Rullgård
mru@kth.se

Re: [hsflinux] [PATCH] Blacklist binary-only modules lying about their license

[Timothy Miller]

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.)

Re: [PATCH] Blacklist binary-only modules lying about their license

[Marc Boucher]

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

Re: [PATCH] Blacklist binary-only modules lying about their license

[Timothy Miller]

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.

Re: [PATCH] Blacklist binary-only modules lying about their license

[Marc Boucher]

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

Re: [PATCH] Blacklist binary-only modules lying about their license

[Timothy Miller]

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?

Re: [PATCH] Blacklist binary-only modules lying about their license

[Matthias Schniedermeyer]

> 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.

Symbios and BIOS (was: Re: [PATCH] Blacklist binary-only modules lying about their license)

[Geert Uytterhoeven]

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 -- geert@linux-m68k.org

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

Re: Symbios and BIOS (was: Re: [PATCH] Blacklist binary-only modules lying about their license)

[Matthias Schniedermeyer]

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.

Re: [PATCH] Blacklist binary-only modules lying about their license

[Pavel Machek]

Hi!

> > 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? ;-)

Well, it only does so if you try to do fast scrolling or palette
operations... which most people won't do.

Actually separate taint flag for this might make sense... and when
buggy vesa bios appears we'll probably add it.
								Pavel
-- 
When do you have heart between your knees?

Re: [hsflinux] [PATCH] Blacklist binary-only modules lying about their license

[Linus Torvalds]

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

Re: [hsflinux] [PATCH] Blacklist binary-only modules lying about their license

[viro]

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)

Re: [hsflinux] [PATCH] Blacklist binary-only modules lying about their license

[Giuliano Colla]

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

Re: [hsflinux] [PATCH] Blacklist binary-only modules lying about their license

[Arthur Perry]

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 majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
>

Re: [hsflinux] [PATCH] Blacklist binary-only modules lying about their license

[Giuliano Colla]

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 

Re: [hsflinux] [PATCH] Blacklist binary-only modules lying about their license

[Carl-Daniel Hailfinger]

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

Re: [hsflinux] [PATCH] Blacklist binary-only modules lying about their license

[Giuliano Colla]

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

Re: [hsflinux] [PATCH] Blacklist binary-only modules lying about their license

[Timothy Miller]

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.

Re: [hsflinux] [PATCH] Blacklist binary-only modules lying about their license

[Geert Uytterhoeven]

On Fri, 30 Apr 2004, Giuliano Colla wrote:
> It may make sense not to have anything left in the GPL directory in a
> binary only .rpm package, because once linked GPL parts cannot be told
> apart from non-GPL ones.

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

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

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

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

Re: [hsflinux] [PATCH] Blacklist binary-only modules lying about their license

[Giuliano Colla]

Geert Uytterhoeven ha scritto:

>On Fri, 30 Apr 2004, Giuliano Colla wrote:
>  
>
>>It may make sense not to have anything left in the GPL directory in a
>>binary only .rpm package, because once linked GPL parts cannot be told
>>apart from non-GPL ones.
>>    
>>
>
>When speaking about loadable kernel modules: yes they can! That's what
>modinfo(8) is for!
>
>Oh wait, someone played tricks with a \0 character...
>
>Gr{oetje,eeting}s,
>
>  
>
What I mean is that in a binary rpm you have binaries which link 
together GPL and non GPL code. There's not such a thing as a GPL 
binaries to put in the GPL directory. This holds true whether they play 
tricks or not. If you want to see the GPL'd code you must download the
source package.
You may blame them for playing tricks with \0 character, but you can't 
blame them for an empty GPL directory in the binary package, when you 
find it properly populated in the source package.

Groetje,
-----
Giuliano Colla

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

Re: [hsflinux] [PATCH] Blacklist binary-only modules lying about their license

[David Lang]

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

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

David Lang


On Mon, 3 May 2004, Giuliano Colla wrote:

> Date: Mon, 03 May 2004 00:26:13 +0200
> From: Giuliano Colla <copeca@copeca.dsnet.it>
> To: Geert Uytterhoeven <geert@linux-m68k.org>
> Cc: Carl-Daniel Hailfinger <c-d.hailfinger.kernel.2004@gmx.net>,
>      Linus Torvalds <torvalds@osdl.org>, hsflinux@lists.mbsi.ca,
>      Rusty Russell <rusty@rustcorp.com.au>, Andrew Morton <akpm@osdl.org>,
>      Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
> Subject: Re: [hsflinux] [PATCH] Blacklist binary-only modules lying about
>     their license
>
> Geert Uytterhoeven ha scritto:
>
> >On Fri, 30 Apr 2004, Giuliano Colla wrote:
> >
> >
> >>It may make sense not to have anything left in the GPL directory in a
> >>binary only .rpm package, because once linked GPL parts cannot be told
> >>apart from non-GPL ones.
> >>
> >>
> >
> >When speaking about loadable kernel modules: yes they can! That's what
> >modinfo(8) is for!
> >
> >Oh wait, someone played tricks with a \0 character...
> >
> >Gr{oetje,eeting}s,
> >
> >
> >
> What I mean is that in a binary rpm you have binaries which link
> together GPL and non GPL code. There's not such a thing as a GPL
> binaries to put in the GPL directory. This holds true whether they play
> tricks or not. If you want to see the GPL'd code you must download the
> source package.
> You may blame them for playing tricks with \0 character, but you can't
> blame them for an empty GPL directory in the binary package, when you
> find it properly populated in the source package.
>
> Groetje,
> -----
> Giuliano Colla
>
> Whenever people agree with me, I always feel I must be wrong (O. Wilde)
>
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
>

-- 
"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

Re: [hsflinux] [PATCH] Blacklist binary-only modules lying about their license

[Timothy Miller]

David Lang wrote:
> except that this brings up the issue of if the GPL will allow this
> linking to take place at all.
> 
> my understanding of what RMS and the FSF have said is that they don't
> believe that this is allowed at all.
> 


It's allowed if the code under GPL was written by Marc and he licenses 
it as such, such as "it's my license, unless you copy it, then it's GPL."

Re: [PATCH] Blacklist binary-only modules lying about their license

[Albert Cahalan]

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.

Re: [PATCH] Blacklist binary-only modules lying about their license

[Jon]

[-- Attachment #1: Type: text/plain, Size: 650 bytes --]

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.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [PATCH] Blacklist binary-only modules lying about their license

[Marc Boucher]

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 "support_XXX@author.com" 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

Re: [PATCH] Blacklist binary-only modules lying about their license

[Adam Jaskiewicz]

>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

Re: [PATCH] Blacklist binary-only modules lying about their license

[Marc Boucher]

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
>

Re: [PATCH] Blacklist binary-only modules lying about their license

[Chris Friesen]

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

Re: [PATCH] Blacklist binary-only modules lying about their license

[Grzegorz Kulewski]

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

Re: [PATCH] Blacklist binary-only modules lying about their license

[Chris Friesen]

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

Re: [PATCH] Blacklist binary-only modules lying about their license

[Timothy Miller]

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.

Re: [PATCH] Blacklist binary-only modules lying about their license

[Grzegorz Kulewski]

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

Re: [PATCH] Blacklist binary-only modules lying about their license

[Valdis.Kletnieks]

[-- Attachment #1: Type: text/plain, Size: 411 bytes --]

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.


[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]

Re: [PATCH] Blacklist binary-only modules lying about their license

[Jorge Bernal (Koke)]

On Martes, 27 de Abril de 2004 20:54, Valdis.Kletnieks@vt.edu 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.

Re: [PATCH] Blacklist binary-only modules lying about their license

[Grzegorz Kulewski]

On Tue, 27 Apr 2004, Jorge Bernal (Koke) wrote:
> On Martes, 27 de Abril de 2004 20:54, Valdis.Kletnieks@vt.edu 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

Re: [PATCH] Blacklist binary-only modules lying about their license

[Jorge Bernal (Koke)]

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"

Re: [PATCH] Blacklist binary-only modules lying about their license

[Valdis.Kletnieks]

[-- Attachment #1: Type: text/plain, Size: 1156 bytes --]

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;
 	}



[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]

Re: [PATCH] Blacklist binary-only modules lying about their license

[Helge Hafting]

Valdis.Kletnieks@vt.edu 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

Re: [PATCH] Blacklist binary-only modules lying about their license

[Marc Boucher]

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

Re: [PATCH] Blacklist binary-only modules lying about their license

[Chris Friesen]

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

Re: [PATCH] Blacklist binary-only modules lying about their license

[Timothy Miller]

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.

Re: [PATCH] Blacklist binary-only modules lying about their license

[Carl-Daniel Hailfinger]

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/

Re: [PATCH] Blacklist binary-only modules lying about their license

[Tigran Aivazian]

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

Re: [PATCH] Blacklist binary-only modules lying about their license

[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

Re: [PATCH] Blacklist binary-only modules lying about their license

[Rusty Russell]

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

Re: [PATCH] Blacklist binary-only modules lying about their license

[Marc Boucher]

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

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
>

Re: [PATCH] Blacklist binary-only modules lying about their license

[David Gibson]

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

Re: [PATCH] Blacklist binary-only modules lying about their license

[Marc Boucher]

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
>

Re: [PATCH] Blacklist binary-only modules lying about their license

[Horst von Brand]

Marc Boucher <marc@linuxant.com> 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

Re: [PATCH] Blacklist binary-only modules lying about their license

[Marc Boucher]

On Apr 27, 2004, at 11:23 PM, Horst von Brand wrote:

> Marc Boucher <marc@linuxant.com> 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 majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
>

Re: [PATCH] Blacklist binary-only modules lying about their license

[Horst von Brand]

Marc Boucher <marc@linuxant.com> said:
> On Apr 27, 2004, at 11:23 PM, Horst von Brand wrote:
> > Marc Boucher <marc@linuxant.com> 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

Re: [PATCH] Blacklist binary-only modules lying about their license

[Timothy Miller]

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.

Re: [PATCH] Blacklist binary-only modules lying about their license

[Marc Boucher]

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.
>

Re: [PATCH] Blacklist binary-only modules lying about their license

[Timothy Miller]

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.

Re: [PATCH] Blacklist binary-only modules lying about their license

[Rik van Riel]

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

Re: [PATCH] Blacklist binary-only modules lying about their license

[Nick Piggin]

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.

Re: [PATCH] Blacklist binary-only modules lying about their license

[Kenneth Aafløy]

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.

Re: [PATCH] Blacklist binary-only modules lying about their license

[Marc Boucher]

Hi Rik,

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

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
>

Re: [PATCH] Blacklist binary-only modules lying about their license

[Ian Stirling]

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.

Re: [PATCH] Blacklist binary-only modules lying about their license

[Rik van Riel]

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

Re: [PATCH] Blacklist binary-only modules lying about their license

[Ian Stirling]

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.

Re: [PATCH] Blacklist binary-only modules lying about their license

[Kenneth Aafløy]

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

Re: [PATCH] Blacklist binary-only modules lying about their license

[Denis Vlasenko]

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

Re: [PATCH] Blacklist binary-only modules lying about their license

[Paulo Marques]

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 - www.grupopie.com
"In a world without walls and fences who needs windows and gates?"

Re: [PATCH] Blacklist binary-only modules lying about their license

[Timothy Miller]

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.

Re: [PATCH] Blacklist binary-only modules lying about their license

[Rik van Riel]

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

Re: [PATCH] Blacklist binary-only modules lying about their license

[Paul Wagland]

[-- Attachment #1: Type: text/plain, Size: 840 bytes --]


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

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 186 bytes --]

Re: [PATCH] Blacklist binary-only modules lying about their license

[Timothy Miller]

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...

Re: [PATCH] Blacklist binary-only modules lying about their license

[viro]

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"

Re: [PATCH] Blacklist binary-only modules lying about their license

[Jorge Bernal (Koke)]

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
koke@amedias.org // koke@sindominio.net
JID: koke@zgzjabber.ath.cx

Re: [PATCH] Blacklist binary-only modules lying about their license

[Marc Boucher]

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
> koke@amedias.org // koke@sindominio.net
> JID: koke@zgzjabber.ath.cx
>

Re: [PATCH] Blacklist binary-only modules lying about their license

[Tim Hockin]

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.

Re: [PATCH] Blacklist binary-only modules lying about their license

[Marc Boucher]

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.
>

Re: [PATCH] Blacklist binary-only modules lying about their license

[viro]

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.

Re: [PATCH] Blacklist binary-only modules lying about their license

[Sean Estabrooks]

On Thu, 29 Apr 2004 18:24:58 -0400
Marc Boucher <marc@linuxant.com> 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.

Re: [PATCH] Blacklist binary-only modules lying about their license

[Marc Boucher]

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 
marc@mbsi.ca & marc@cam.org 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.

Re: [PATCH] Blacklist binary-only modules lying about their license

[Bartlomiej Zolnierkiewicz]

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
> marc@mbsi.ca & marc@cam.org 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

Re: [PATCH] Blacklist binary-only modules lying about their license

[Peter Williams]

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
>>marc@mbsi.ca & marc@cam.org 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                peterw@aurema.com
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

Re: [PATCH] Blacklist binary-only modules lying about their license

[Bartlomiej Zolnierkiewicz]

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
> >>marc@mbsi.ca & marc@cam.org 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

Re: [PATCH] Blacklist binary-only modules lying about their license

[Timothy Miller]

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.

Re: [PATCH] Blacklist binary-only modules lying about their license

[Jesse Pollard]

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.

Re: [PATCH] Blacklist binary-only modules lying about their license

[Sean Estabrooks]

On Thu, 29 Apr 2004 22:15:19 -0400
Marc Boucher <marc@linuxant.com> 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.

Re: [PATCH] Blacklist binary-only modules lying about their license

[Marc Boucher]

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

Re: [PATCH] Blacklist binary-only modules lying about their license

[Sean Estabrooks]

On Fri, 30 Apr 2004 01:44:24 -0400
Marc Boucher <marc@linuxant.com> 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.

Re: [PATCH] Blacklist binary-only modules lying about their license

[Jeff Garzik]

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

Re: [PATCH] Blacklist binary-only modules lying about their license

[Jan-Benedict Glaw]

[-- Attachment #1: Type: text/plain, Size: 856 bytes --]

On Fri, 2004-04-30 04:04:17 -0400, Jeff Garzik <jgarzik@pobox.com>
wrote in message <40920881.6070300@pobox.com>:
> 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       jbglaw@lug-owl.de    . +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));

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [PATCH] Blacklist binary-only modules lying about their license

[Tigran Aivazian]

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

Re: [PATCH] Blacklist binary-only modules lying about their license

[Chris Friesen]

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

Re: [PATCH] Blacklist binary-only modules lying about their license

[Marc Boucher]

Chris,

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

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
>
>
>

Re: [PATCH] Blacklist binary-only modules lying about their license

[Chris Friesen]

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

Re: [PATCH] Blacklist binary-only modules lying about their license

[Rogier Wolff]

On Fri, Apr 30, 2004 at 12:30:25PM -0400, Chris Friesen 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".
> 
> The C string library considers a null to terminate the string.  You added a 
> null after the "GPL". It appears to me that this is telling the kernel that 
> the module is licensed as "GPL", even though it is obvious to a person 

How about the following:

The MODULE_LICENCE macro is a technical way of indicating the licence
to the kernel. There are various ways of putting "comments and remarks"
about the licence in the source code, but techically, if 
	strcmp (MODULE_LICENCE, "GPL") == 0
then the module is licenced under GPL.  (*)

For example, I like the following licence:

	MODULE_LICENCE ("GPL"); 
	/* The GPL licence allows you to distribute changes yourself, 
	   but in fact I would prefer if you contact me with your 
	   patches */

Now it might be that some vendors have written aditional comments
in such a way that they make it into the binary. Fine. 

If some vendor tells the kernel that it's licence is "GPL" then 
that's fine. The kernel then has the right to point the users to their
rights. 

So I would support that new kernels to do something like: 

	if (module_is_probably_lying ()) {
		printk (KERN_WARN "Loading module XXX, which indicates "
			"that it has a GPL licence. This gives YOU\n");
		printf (KERN_WARN "(the user) certain rights. Read "
			"about those rights at: www.fsf.org/.....\n");
		printf (KERN_WARN "and www.kernel.org/linux-gpl-modules.html\n"); 
	}

The linux-gpl-modules.html URL would explain that some vendors 
are telling the kernel that their module is under GPL, but are 
refusing to release source code. The users should be urged to politely
ask the vendor for the source.

		Roger. 

(*) There could be bugs in code. For example, 

	errorcode = somefunction (....);
	if (errorcode = ERR_FILE_NOT_FOUND) {
		/* Handle the not found case */

	}

is perfectly clear to humans what was meant, but the computer understands
otherwise. It is quite possible that the vendors involved in this case
will claim they might have had a bug in their code. 

-- 
** R.E.Wolff@BitWizard.nl ** http://www.BitWizard.nl/ ** +31-15-2600998 **
*-- BitWizard writes Linux device drivers for any device you may have! --*
**** "Linux is like a wigwam -  no windows, no gates, apache inside!" ****

Re: [PATCH] Blacklist binary-only modules lying about their license

[Måns Rullgård]

Rogier Wolff <R.E.Wolff@BitWizard.nl> writes:

> On Fri, Apr 30, 2004 at 12:30:25PM -0400, Chris Friesen 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".
>> 
>> The C string library considers a null to terminate the string.  You added a 
>> null after the "GPL". It appears to me that this is telling the kernel that 
>> the module is licensed as "GPL", even though it is obvious to a person 
>
> How about the following:
>
> The MODULE_LICENCE macro is a technical way of indicating the licence
> to the kernel. There are various ways of putting "comments and remarks"
> about the licence in the source code, but techically, if 
> 	strcmp (MODULE_LICENCE, "GPL") == 0
> then the module is licenced under GPL.  (*)

What if my module is licensed under the Grand Proprietary License (GPL)?

-- 
Måns Rullgård
mru@kth.se

Re: [PATCH] Blacklist binary-only modules lying about their license

[Gilles May]

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!

Re: [PATCH] Blacklist binary-only modules lying about their license

[Marc Boucher]

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

Marc

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!
>
>
>

Re: [PATCH] Blacklist binary-only modules lying about their license

[Michael Poole]

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)

Re: [PATCH] Blacklist binary-only modules lying about their license

[Marc Boucher]

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)
>

Re: [PATCH] Blacklist binary-only modules lying about their license

[Timothy Miller]

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.

Re: [PATCH] Blacklist binary-only modules lying about their license

[Timothy Miller]

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.

Re: [PATCH] Blacklist binary-only modules lying about their license

[Marc Boucher]

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

Re: [PATCH] Blacklist binary-only modules lying about their license

[Timothy Miller]

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.

Re: [PATCH] Blacklist binary-only modules lying about their license

[Timothy Miller]

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.

Re: [PATCH] Blacklist binary-only modules lying about their license

[Jan-Benedict Glaw]

[-- Attachment #1: Type: text/plain, Size: 2208 bytes --]

On Fri, 2004-04-30 01:44:24 -0400, Marc Boucher <marc@linuxant.com>
wrote in message <6FD0ADAF-9A69-11D8-B83D-000A95BCAC26@linuxant.com>:

> 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       jbglaw@lug-owl.de    . +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));

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [PATCH] Blacklist binary-only modules lying about their license

[Geert Uytterhoeven]

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 -- geert@linux-m68k.org

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

Re: [PATCH] Blacklist binary-only modules lying about their license

[Timothy Miller]

Sean Estabrooks wrote:
> On Thu, 29 Apr 2004 18:24:58 -0400
> Marc Boucher <marc@linuxant.com> 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.

Re: [PATCH] Blacklist binary-only modules lying about their license

[Marc Boucher]

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

Re: [PATCH] Blacklist binary-only modules lying about their license

[Sean Estabrooks]

On Fri, 30 Apr 2004 13:14:46 -0400
Marc Boucher <marc@linuxant.com> 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

Re: [PATCH] Blacklist binary-only modules lying about their license

[Timothy Miller]

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!

Re: [PATCH] Blacklist binary-only modules lying about their license

[Helge Hafting]

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

Re: [PATCH] Blacklist binary-only modules lying about their license

[Timothy Miller]

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.  :)

Re: [PATCH] Blacklist binary-only modules lying about their license

[Gene Heskett]

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 majordomo@vger.kernel.org
>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.

Re: [PATCH] Blacklist binary-only modules lying about their license

[Geert Uytterhoeven]

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 -- geert@linux-m68k.org

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

Re: [PATCH] Blacklist binary-only modules lying about their license

[Rik van Riel]

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

Re: [PATCH] Blacklist binary-only modules lying about their license

[Rusty Russell]

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

Re: [PATCH] Blacklist binary-only modules lying about their license

[Marc Boucher]

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
>

Re: [PATCH] Blacklist binary-only modules lying about their license

[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

Re: [PATCH] Blacklist binary-only modules lying about their license

[Marc Boucher]

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
>

Re: [PATCH] Blacklist binary-only modules lying about their license

[Timothy Miller]

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.

Re: [PATCH] Blacklist binary-only modules lying about their license

[Marc Boucher]

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.

Re: [PATCH] Blacklist binary-only modules lying about their license

[Denis Vlasenko]

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

Re: [PATCH] Blacklist binary-only modules lying about their license

[Timothy Miller]

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.

Re: [PATCH] Blacklist binary-only modules lying about their license

[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

Re: [PATCH] Blacklist binary-only modules lying about their license

[Tom Sightler]

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

Re: [PATCH] Blacklist binary-only modules lying about their license

[Marc Boucher]

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
>
>

Re: [PATCH] Blacklist binary-only modules lying about their license

[Stephen Hemminger]

On Wed, 28 Apr 2004 12:40:43 -0400
Marc Boucher <marc@linuxant.com> 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).

Re: [PATCH] Blacklist binary-only modules lying about their license

[Timothy Miller]

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.

Re: [PATCH] Blacklist binary-only modules lying about their license

[Rik van Riel]

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

Re: [PATCH] Blacklist binary-only modules lying about their license

[Carl-Daniel Hailfinger]

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 "support_XXX@author.com" 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/

Re: [PATCH] Blacklist binary-only modules lying about their license

[Horst von Brand]

Marc Boucher <marc@linuxant.com> 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