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

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

[Hua Zhong]

> WINE is a user process.  It does not run in kernel space, so we don't 
> care about it.  Since all the closed-source stuff, like 
> Office, runs in user space, it CANNOT corrupt the kernel (barring real 
> kernel bugs).
> 
> I think Linus needs to smack you down like he did with that guy who 
> couldn't understand the distinction between firmware and a 
> kernel driver.

I think he doesn't, because he can read what other said. I know what
distinction it is and I've been working on kernel for years since I was
still in school.

I'm not arguing about the taint issue, or any technical issue, as clearly
stated in my last paragraph. I am mearly responding to the questioning to
Linuxant's business model.

> As long as the kernel is protected, we are generally in favor of it.
>
> > Linuxant did a wrong thing by working around the warning 
> > message, but I don't think it's fair to accuse of their business 
> > because they allow binary drivers run on Linux.
> 
> The fact that binary drivers are "evil" does not reflect badly on 
> Linuxant, in my opinion.

It doesn't look like so to me.

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

[Bartlomiej Zolnierkiewicz]

On Friday 30 of April 2004 20:47, Timothy Miller wrote:
> Hua Zhong wrote:
> > Linuxant did a wrong thing by working around the warning message, but I
> > don't think it's fair to accuse of their business because they allow
> > binary drivers run on Linux.

IMHO open-source drivers are one of the biggest advantages of Linux.

Linuxant seems to be using double standards: we are all for open-source OS but
_our_ drivers have to remain proprietary (I don't care about reasons here).

Marc, I _appreciate_ all your hard-work on open-source projects and I can
understand reasons why Linuxant makes it's drivers but please, be honest. :)
I think that you agree that things like HSF drivers or DriverLoader
(because they are workarounds not the real solution) _may_ slow down creation
of real open-source drivers.

I also hope that this '\0' issue won't scare you from working with
community in the future.

Regards,
Bartlomiej

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

[Linus Torvalds]

On Fri, 30 Apr 2004, Hua Zhong wrote:
> 
> I have not heard so much WINING about WINE. I even see kernel developers add
> more support in the kernel to support WINE. Why do people like to pick on
> closed-source drivers being run by a wrapper? I see nothing wrong with that.

What is so hard to understand about the problem with bugs?

All software has bugs. Binary modules just mean that those bugs are
 - FATAL to the system, including possibly being a huge security hole.
 - impossible to debug
 - impossible to fix

In contrast, wine was _written_ to do this emulation, so by definition any
"bugs" are in wine itself (although I suspect that wine people sometimes
would prefer it if Office came with sources ;).

> Linuxant did a wrong thing by working around the warning message, but I
> don't think it's fair to accuse of their business because they allow binary
> drivers run on Linux.

Nobody has sued them over copyright infringement. What they are doing is 
likely legal - APART from the fact that they lied about the license, which 
is not only horribly immoral, it's also likely illegal under the DMCA.

Note: to me, the immoral part is the big one. If you want to flaunt the
DMCA and take the risk of the feds coming after you as a matter of civil
disobedience, all the more power to you. Let's not be hypocritical and
claim to like the DMCA.

But let's not kid about this: adding that '\0' thing to try to make the
kernel believe it was GPL'd code is not ethical, and there is no way to
claim that it's needed, since the _only_ thing it suppresses are a few
messages saying that the kernel is tainted as a result. Which it IS.

So don't bother trying to stand up for Linuxant. What they did was WRONG,
and there are no excuses for it. And I hope that they have it fixed
already and we can hereby just forget about this discussion.

		Linus

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

[Hua Zhong]

My last email on this topic. If it weren't Linus I would have stopped. :-)

> What is so hard to understand about the problem with bugs?
> 
> All software has bugs. Binary modules just mean that those bugs are
>  - FATAL to the system, including possibly being a huge security hole.
>  - impossible to debug
>  - impossible to fix

It's the user's choice to run binary modules on their systems, as long as
the "tainted" issue is not hidden (which I clearly said was wrong) so the
support burden is directed to the right company/person who will hopefully
fix those bugs, why should it concern kernel developers so much? Let the
user have a choice. A working computer which occasionally crashes is still
better to the user than a stable computer which doesn't do the job.

In this sense, it doesn't matter it's a bug in user space or kernel space,
or hard or easy to fix, as long as it doesn't cause much extra burden to the
community.

All I try to say is about the business model of supporting closed-source
drivers by a GPL'ed wrapper. It may not be perfect in an imperfect world,
but nothing to criticize on.

> So don't bother trying to stand up for Linuxant. What they 
> did was WRONG, and there are no excuses for it. And I hope 
> that they have it fixed already and we can hereby just forget 
> about this discussion.

You don't need to tell me why it was wrong, because I already said it was
wrong. :-) I'm not standing up for linuxant either - I am not their
customers and I hardly heard of this name before. I'm just standing up for a
generic issue (which is often silly).

And I agree we should stop this thread now.

> 		Linus
> 

Allowing only "-g" compiled modules! (was: [PATCH] Blacklist binary-only modules lying about their license)

[Jan-Benedict Glaw]

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

On Fri, 2004-04-30 12:37:26 -0700, Hua Zhong <hzhong@cisco.com>
wrote in message <00b201c42eea$916f6c40$ca41cb3f@amer.cisco.com>:

> user have a choice. A working computer which occasionally crashes is still
> better to the user than a stable computer which doesn't do the job.

WHAT!? I'm sorry, but to my eyes, an unstable computer is worth nothing.
If I can't somewhat trust my machine, I'll take paper and pencil...

However, I don't see a solution towards stopping companies from making
(partially) binary-only drivers.

Maybe we'd start to put more effort into disassemblers/re-assemblers and
code-generators from disassembly dumps.

Maybe we can use a simple solution: Only allow modules that contain full
debug info :)

MfG, JBG

-- 
   Jan-Benedict Glaw       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

[Marc Boucher]

Like Hua said, this ought to be "my last email on this topic. If it 
weren't Linus I would have stopped. :-)"

On Apr 30, 2004, at 3:19 PM, Linus Torvalds wrote:
>
> On Fri, 30 Apr 2004, Hua Zhong wrote:
>>
>> I have not heard so much WINING about WINE. I even see kernel 
>> developers add
>> more support in the kernel to support WINE. Why do people like to 
>> pick on
>> closed-source drivers being run by a wrapper? I see nothing wrong 
>> with that.
>
> What is so hard to understand about the problem with bugs?
>
> All software has bugs. Binary modules just mean that those bugs are
>  - FATAL to the system, including possibly being a huge security hole.
>  - impossible to debug
>  - impossible to fix

All bugs are possibly fatal, or huge security holes, regardless of 
whether they are in binary-only code or open-source.
All bugs can be debugged or fixed, it's a matter of how hard it is to 
do (generally easier with open-source) and *who* is responsible for 
doing it (i.e. supporting the modules).

>
> In contrast, wine was _written_ to do this emulation, so by definition 
> any
> "bugs" are in wine itself (although I suspect that wine people 
> sometimes
> would prefer it if Office came with sources ;).

The same can be said about DriverLoader.

>
>> Linuxant did a wrong thing by working around the warning message, but 
>> I
>> don't think it's fair to accuse of their business because they allow 
>> binary
>> drivers run on Linux.
>
> Nobody has sued them over copyright infringement. What they are doing 
> is
> likely legal - APART from the fact that they lied about the license, 
> which
> is not only horribly immoral, it's also likely illegal under the DMCA.

The purpose of the workaround is not to circumvent any protection, but 
to fix a real usability issue for systems in the field, which, as an 
expert you perhaps do not see, but users definitely massively felt and 
complained about.

>
> Note: to me, the immoral part is the big one. If you want to flaunt the
> DMCA and take the risk of the feds coming after you as a matter of 
> civil
> disobedience, all the more power to you. Let's not be hypocritical and
> claim to like the DMCA.

I don't see our actions as being immoral at all. But in retrospect, I 
admit that the issue should have been differently handled (i.e. by 
sending patches, and perhaps starting a discussion on the lkml before 
implementing a workaround).

> But let's not kid about this: adding that '\0' thing to try to make the
> kernel believe it was GPL'd code is not ethical, and there is no way to
> claim that it's needed, since the _only_ thing it suppresses are a few
> messages saying that the kernel is tainted as a result. Which it IS.

Most kernels are already potentially "tainted" by the use of 
proprietary binary-only BIOS code, use of non-standard custom patches, 
reliance on untrusted external data, etc.. This illustrates that the 
MODULE_LICENSE tainting concept is flawed, and needlessly 
scary/confusing for users.

>
> So don't bother trying to stand up for Linuxant.

I can understand that you do not really like what we are doing to 
provide alternative options so that people can use otherwise 
unsupported hardware.

> What they did was WRONG,
> and there are no excuses for it.

But the main justification for the regrettable \0 trick remains that 
the tainted messages are redundant, confusing, and do not convey key 
information (i.e. who is responsible for supporting the third-party 
module) to ordinary users.

> And I hope that they have it fixed
> already and we can hereby just forget about this discussion.

We are working on a new release, which will be on the website shortly.

And I hope that you will agree to deal with the root problem by 
incorporating some of the suggestions (or equivalent ones) that people 
have made to fix the messages.

> 		Linus
>
>

Regards
Marc

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

[Linus Torvalds]

On Fri, 30 Apr 2004, Marc Boucher wrote:
>
> > In contrast, wine was _written_ to do this emulation, so by definition 
> > any
> > "bugs" are in wine itself (although I suspect that wine people 
> > sometimes
> > would prefer it if Office came with sources ;).
> 
> The same can be said about DriverLoader.

.. but not abotu the kernel that it depends on.

In other words, if driverloader was a stand-alone project, you could do 
whatever the hell you wanted with it.

But it isn't a standalone project, is it? It depends on the kernel, and 
there is no question that driverloader is a derived work.

Which means that you had better follow the rules.

So stop yer whining. When you write your own operating system, and your 
driver doesn't have to depend on anybody elses code, then you can set the 
rules. As it is, the kernel requires modules to tell it their license, and 
if you lie to it, that is not only potentially violating the DMCA, it's 
also likely a crime under regular copyright laws (ie you are knowingly 
misrepresenting a license - in this case the license of the binary part, 
and that's not legal either).

> The purpose of the workaround is not to circumvent any protection, but 
> to fix a real usability issue for systems in the field, which, as an 
> expert you perhaps do not see, but users definitely massively felt and 
> complained about.

Oh, so it's ok to do something illegal, because it helps usability? And 
ethics take second place to "the user doesn't want to see that line in the 
logs"?

Sure, that's a good argument. NOT.

GET RID OF YOUR LYING LICENSE LINE!

		Linus

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

[Marc Boucher]

On Apr 30, 2004, at 4:26 PM, Linus Torvalds wrote:
>
> On Fri, 30 Apr 2004, Marc Boucher wrote:
>>
>>> In contrast, wine was _written_ to do this emulation, so by 
>>> definition
>>> any
>>> "bugs" are in wine itself (although I suspect that wine people
>>> sometimes
>>> would prefer it if Office came with sources ;).
>>
>> The same can be said about DriverLoader.
>
> .. but not abotu the kernel that it depends on.
>
> In other words, if driverloader was a stand-alone project, you could do
> whatever the hell you wanted with it.

To clarify this important point, driverloader is a standalone project, 
and structured similarly to the HSF driver (all os-specific code is 
open-source allowing it to be used with any kernel or even 
theoretically any other x86 operating system).

Because only one logical module is loaded, and a single set of tainted 
messages bearable, the \0 MODULE_LICENSE() workaround is unnecessary 
and not used in driverloader.

Marc

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

[Linus Torvalds]

On Fri, 30 Apr 2004, Marc Boucher wrote:
> >
> > In other words, if driverloader was a stand-alone project, you could do
> > whatever the hell you wanted with it.
> 
> To clarify this important point, driverloader is a standalone project, 
> and structured similarly to the HSF driver (all os-specific code is 
> open-source allowing it to be used with any kernel or even 
> theoretically any other x86 operating system).

The Linux-centric parts are absolutely NOT stand-alone, and one big part
of that Linux-centric stuff is that magic line that says MODULE_LICENSE().

In other words, you're a weasel.

			Linus

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

[Marc Boucher]

On Apr 30, 2004, at 4:44 PM, Linus Torvalds wrote:
>
> The Linux-centric parts are absolutely NOT stand-alone, and one big 
> part
> of that Linux-centric stuff is that magic line that says 
> MODULE_LICENSE().
>

are you claiming that anything that uses the MODULE_LICENSE() macro 
becomes a derived work of the Linux kernel subject to the GPL?

Marc

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

[Linus Torvalds]

On Fri, 30 Apr 2004, Marc Boucher wrote:
> 
> are you claiming that anything that uses the MODULE_LICENSE() macro 
> becomes a derived work of the Linux kernel subject to the GPL?

I'm claiming that you are wilfully misrepresenting the license of your 
code to another piece of code THAT YOU DON'T CONTROL.

I'm further claiming that this is unethical and quite possibly illegal.

How hard is that to understand? Remove that stupid lying line. Pronto.

How the _hell_ can you stand up for lying in public? Have you no shame?

		Linus

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

[Timothy Miller]

Marc Boucher wrote:
> 
> 
> On Apr 30, 2004, at 4:44 PM, Linus Torvalds wrote:
> 
>>
>> The Linux-centric parts are absolutely NOT stand-alone, and one big part
>> of that Linux-centric stuff is that magic line that says 
>> MODULE_LICENSE().
>>
> 
> are you claiming that anything that uses the MODULE_LICENSE() macro 
> becomes a derived work of the Linux kernel subject to the GPL?


Well, some people might argue that, but let's put that aside for the 
moment.  I think one of the things he's implying is that anything which 
says MODULE_LICENSE("GPL") (which is what your driver did) is required 
to actually BE under the GPL.


Technically, since the Linux kernel headers are under GPL, including 
them into your code does make your code a derived work.  However, people 
are allowed to slide on this in certain strict circumstances, especially 
when MODULE_LICENSE doesn't say the license is GPL.

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

[Sean Estabrooks]

On Fri, 30 Apr 2004 16:39:01 -0400
Marc Boucher <marc@linuxant.com> wrote:

> To clarify this important point, driverloader is a standalone project, 
> and structured similarly to the HSF driver (all os-specific code is 
> open-source allowing it to be used with any kernel or even 
> theoretically any other x86 operating system).
> 
> Because only one logical module is loaded, and a single set of tainted 
> messages bearable, the \0 MODULE_LICENSE() workaround is unnecessary 
> and not used in driverloader.
> 

After 150+ messages not even one concept that's been mentioned has pierced
the fog of your self righteousness has it?   Please just try to respect
the people who bring you Linux.

Sean.

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

[Stefan Smietanowski]

Hi.

> The purpose of the workaround is not to circumvent any protection, but 
> to fix a real usability issue for systems in the field, which, as an 
> expert you perhaps do not see, but users definitely massively felt and 
> complained about.

That's like saying that someone hates getting a speeding ticket from
those automatic cameras that are cropping up everywhere now.

He then promptly removes his license plate so he can't be tracked and
then he can continue to speed along.

Now - To the entity that is issuing tickets it appears that that
person is now a law abiding citizen and does not speed anymore when
in truth he removed the plate so it would appear that way.

The speeding ticket is printed message.

Yes, it might or should be changed to print it once or once
per $MODULE_VENDOR or license or whatever, but the issue remains.

It wasn't YOU that installed the speed camera nor set the speed
limits (ie created the tained flag and the code that prints a
message when such a module is inserted) but claiming that
"but it's only a workaround because I was getting so many tickets"
doesn't make it any better.

Yes, Linux is such an open system that a user can install a kernel
that doesn't print anything for tained kernels (remove speed cameras)
but that doesn't mean that YOU can do anything about it from the side
of the car (module).

Also note that neither the speed camera nor the kernel actually make
any limits on speeding (loading proprietary modules).

// Stefan

A compromise that could have been reached. Re: [PATCH] Blacklist binary-only modules lying about their license

[Timothy Miller]

Something occurred to me...

It does take some time to get patches to propogate onto people's 
computers.  Linuxant has the problem that they have to be able to work 
in lots of different already-deployed kernels.

I get the impression that Linuxant attempts to load and try a large 
number of drivers in order to detect hardware.  While that isn't 
necessarily the best way to probe for devices, I can see why it would be 
unpleasant to have numerous "taint" messages print out in the general case.

The best solution to this would be both legal (in the sense of them 
being licensed to do this) and solve Linuxant's problem.  How to do this?


Linuxant could have posed this problem to LKML and gotten permission to 
do something "questionable", which is what I am going to suggest:

First:   Do the "GPL\0" thing with the permission of LKML members, 
conditioned on the next two steps.

Second:  Make the Linuxant loader program print out a message that 
explains to users that the kernel is really being tainted, even though 
it doesn't look that way, and also that same message needs to get into 
appropriate system logs.

Third:   Find some way to force on the "tainted" flag in the kernel 
after all the module load attempts have been finished.


I'm not declaring this to be THE solution   It might be crap.  But the 
Linux community does enjoy cooperating with people who are trying to do 
good things and need help.  An argument can be made that there is some 
benefit to what Linuxant does, and that argument is strong enough that 
enough people would probably agree to this sort of compromize.


In fact, in my opinion, if I were a major kernel contributor, I wouldn't 
mind the "questionable workaround" at all if the consequences of it were 
deal with by forcing the "tainting" flag on after the tainting flag had 
been defeated.

Make sense?

Re: A compromise that could have been reached. Re: [PATCH] Blacklist binary-only modules lying about their license

[Marc Boucher]

Indeed. The driver in question contains 8 interdependent modules. What 
we were thinking of doing to settle the issue short-term in a fair way 
for both our users and kernel developers, is removing the \0 from the 
central one (hsfengine), causing the kernel to be properly tainted and 
one instance of the messages to be automatically printed when the 
driver is used.

Hopefully the community will view this as an acceptable compromise. 
Once patches have propagated onto people's computers, we will be happy 
to remove all \0's completely.

Marc

On Apr 30, 2004, at 4:47 PM, Timothy Miller wrote:

> Something occurred to me...
>
> It does take some time to get patches to propogate onto people's 
> computers.  Linuxant has the problem that they have to be able to work 
> in lots of different already-deployed kernels.
>
> I get the impression that Linuxant attempts to load and try a large 
> number of drivers in order to detect hardware.  While that isn't 
> necessarily the best way to probe for devices, I can see why it would 
> be unpleasant to have numerous "taint" messages print out in the 
> general case.
>
> The best solution to this would be both legal (in the sense of them 
> being licensed to do this) and solve Linuxant's problem.  How to do 
> this?
>
>
> Linuxant could have posed this problem to LKML and gotten permission 
> to do something "questionable", which is what I am going to suggest:
>
> First:   Do the "GPL\0" thing with the permission of LKML members, 
> conditioned on the next two steps.
>
> Second:  Make the Linuxant loader program print out a message that 
> explains to users that the kernel is really being tainted, even though 
> it doesn't look that way, and also that same message needs to get into 
> appropriate system logs.
>
> Third:   Find some way to force on the "tainted" flag in the kernel 
> after all the module load attempts have been finished.
>
>
> I'm not declaring this to be THE solution   It might be crap.  But the 
> Linux community does enjoy cooperating with people who are trying to 
> do good things and need help.  An argument can be made that there is 
> some benefit to what Linuxant does, and that argument is strong enough 
> that enough people would probably agree to this sort of compromize.
>
>
> In fact, in my opinion, if I were a major kernel contributor, I 
> wouldn't mind the "questionable workaround" at all if the consequences 
> of it were deal with by forcing the "tainting" flag on after the 
> tainting flag had been defeated.
>
> Make sense?
>

Re: A compromise that could have been reached. Re: [PATCH] Blacklist binary-only modules lying about their license

[Rik van Riel]

On Fri, 30 Apr 2004, Marc Boucher wrote:

> Hopefully the community will view this as an acceptable compromise. 
> Once patches have propagated onto people's computers, we will be happy 
> to remove all \0's completely.

I didn't see any patches.  Does that mean you plan to
continue your potential violation of copyright law
forever ?

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

Re: A compromise that could have been reached. Re: [PATCH] Blacklist binary-only modules lying about their license

[Timothy Miller]

Marc Boucher wrote:
> 
> Indeed. The driver in question contains 8 interdependent modules. What 
> we were thinking of doing to settle the issue short-term in a fair way 
> for both our users and kernel developers, is removing the \0 from the 
> central one (hsfengine), causing the kernel to be properly tainted and 
> one instance of the messages to be automatically printed when the driver 
> is used.
> 
> Hopefully the community will view this as an acceptable compromise. Once 
> patches have propagated onto people's computers, we will be happy to 
> remove all \0's completely.
> 

At this point, you're not going to get any slack.  If this is what you'd 
done to start with, you might have gotten away with it.  As it stands, 
you appear to be unwilling to comply with the rules, except as a last 
resort when you've been flamed for days.

I think what you need to do right now is do a lot of begging.  I agree 
that in principle, it's only technically necessary to have one of the 
modules taint the kernel.  But it's still "bad" to lie about the module 
license and should only be done after much scrutiny and discussion.

So if everyone who has a stake in this agrees to let you do it, then go 
ahead.  Otherwise, sorry Charley, but you're SOL.

Re: A compromise that could have been reached. Re: [PATCH] Blacklist binary-only modules lying about their license

[Marc Boucher]

I had proposed this compromise in good faith to Rusty at the very 
beginning of the debate but have not received an answer about it from 
him yet.

Since it appears impossible to get formal "approval" from a "community" 
composed of very diverse elements (for better and for worse) we will 
probably implement this short-term solution to restore tainting.

Regards
Marc

On Apr 30, 2004, at 5:38 PM, Timothy Miller wrote:
>
> Marc Boucher wrote:
>> Indeed. The driver in question contains 8 interdependent modules. 
>> What we were thinking of doing to settle the issue short-term in a 
>> fair way for both our users and kernel developers, is removing the \0 
>> from the central one (hsfengine), causing the kernel to be properly 
>> tainted and one instance of the messages to be automatically printed 
>> when the driver is used.
>> Hopefully the community will view this as an acceptable compromise. 
>> Once patches have propagated onto people's computers, we will be 
>> happy to remove all \0's completely.
>
> At this point, you're not going to get any slack.  If this is what 
> you'd done to start with, you might have gotten away with it.  As it 
> stands, you appear to be unwilling to comply with the rules, except as 
> a last resort when you've been flamed for days.
>
> I think what you need to do right now is do a lot of begging.  I agree 
> that in principle, it's only technically necessary to have one of the 
> modules taint the kernel.  But it's still "bad" to lie about the 
> module license and should only be done after much scrutiny and 
> discussion.
>
> So if everyone who has a stake in this agrees to let you do it, then 
> go ahead.  Otherwise, sorry Charley, but you're SOL.
>

Re: A compromise that could have been reached. Re: [PATCH] Blacklist binary-only modules lying about their license

[Tim Connors]

Timothy Miller <miller@techsource.com> said on Fri, 30 Apr 2004 17:38:25 -0400:
> 
> 
> Marc Boucher wrote:
> > 
> > Indeed. The driver in question contains 8 interdependent modules. What 
> > we were thinking of doing to settle the issue short-term in a fair way 
> > for both our users and kernel developers, is removing the \0 from the 
> > central one (hsfengine), causing the kernel to be properly tainted and 
> > one instance of the messages to be automatically printed when the driver 
> > is used.
> > 
> > Hopefully the community will view this as an acceptable compromise. Once 
> > patches have propagated onto people's computers, we will be happy to 
> > remove all \0's completely.
...
> I think what you need to do right now is do a lot of begging.  I agree 
> that in principle, it's only technically necessary to have one of the 
> modules taint the kernel.  But it's still "bad" to lie about the module 
> license and should only be done after much scrutiny and discussion.

What's wrong with the printk setting workaround? Simply write a number
to the appropriate file before you load the modules.

I just tried googling for the relevant post, but failed...

He doesn't need to wait for the patches to propogate. He can act on
his own scripts immediately in readiness for the next version.

Easy.

-- 
TimC -- http://astronomy.swin.edu.au/staff/tconnors/
Modus Ponens in action:
- Nothing is better than world peace. 
- A turkey sandwich is better than nothing. 
  ==>  Ergo, a turkey sandwich is better than world peace. 

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

[Jorge Bernal]

On Fri, Apr 30, 2004 at 04:11:29PM -0400, Marc Boucher wrote:
> 
> The purpose of the workaround is not to circumvent any protection, but 
> to fix a real usability issue for systems in the field, which, as an 
> expert you perhaps do not see, but users definitely massively felt and 
> complained about.
> 

You have argued this a lot of times during this thread and I want to say
smoenthing about that. I have used some binary-only modules: nvidia,
vmware and some time ago HSF drivers. When I installed the nvidia
propetary driver was the first time I saw the word 'tainted' and it
makes sense: I was at the console.

I mean that most of users work on X (except when installing X drivers
:)) and probably they will never see this "confusing" warnings.

When my system boots, it loads the nvidia and vmware modules and most of
time (I could say always) I don't notice that my kernel is tainted
(though I know) so I don't see the reason to hide the license.

I think it should be good for all to stop flaming and put some things in
order. You have lied about the license and it seems you want to keep
lying so -quoting Linus- it seems you don't have shame.

Cheers,
	Koke

-- 
"Sólo el éxito diferencia al genio del loco"

Blog: http://www.amedias.org/koke
Web Personal: http://sindominio.net/~koke/
JID: koke@zgzjabber.ath.cx

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

[Martin J. Bligh]

> All bugs can be debugged or fixed, it's a matter of how hard it is 
> to do (generally easier with open-source) and *who* is responsible 
> for doing it (i.e. supporting the modules).

Yes, exactly. The tainted mechanism is there to tell us that it's not 
*our* problem to support it. And you deliberately screwed that up,
which is why everybody is pissed at you.

M.

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

[Marc Boucher]

On May 1, 2004, at 1:07 AM, Martin J. Bligh wrote:

>> All bugs can be debugged or fixed, it's a matter of how hard it is
>> to do (generally easier with open-source) and *who* is responsible
>> for doing it (i.e. supporting the modules).
>
> Yes, exactly. The tainted mechanism is there to tell us that it's not
> *our* problem to support it. And you deliberately screwed that up,
> which is why everybody is pissed at you.

It was already screwed up, and causing unnecessary support burdens
both on the community ("help! what does tainted mean") and vendors.
This thread and previous ones have shown ample evidence of that.
Let's deal with the root problem and fix the messages, as Rik van Riel
has suggested.

Most third-party module suppliers have been confronted with the same 
issue
and forced to work around it (in other imperfect and sometimes clumsy 
ways).
One of them redirects the messages to a separate file and appends
the following notice:

 > ********************************************************************
 > * You can safely ignore the above message about tainting the kernel.
 > * It is completely political and means just that the maintainers of
 > * of modutils package dislike software that is not distributed under
 > * an open source license.
 > ********************************************************************

On Apr 30, 2004, at 10:36 PM, Tim Connors wrote:
>
> What's wrong with the printk setting workaround? Simply write a number
> to the appropriate file before you load the modules.
>
> I just tried googling for the relevant post, but failed...
>
> He doesn't need to wait for the patches to propogate. He can act on
> his own scripts immediately in readiness for the next version.
>
> Easy.

Not. We don't use a script to systematically load the modules,
because they are large and not always required, nor want to
interfere with the system's normal logging.

Manipulating printk settings or redirecting the superfluous
messages elsewhere are also ugly hacks, which can
potentially also divert/hide important messages.

Marc

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

[Davide Libenzi]

On Sat, 1 May 2004, Marc Boucher wrote:

> One of them redirects the messages to a separate file and appends
> the following notice:
> 
>  > ********************************************************************
>  > * You can safely ignore the above message about tainting the kernel.
>  > * It is completely political and means just that the maintainers of
>  > * of modutils package dislike software that is not distributed under
>  > * an open source license.
>  > ********************************************************************

Right that you're there, you might want also to add something like:

*************************************************************************
* Do not even try to report your problems with the Linux kernel to software
* maintainers at linux-kernel@vger.kernel.org since they cannot do anything
* about modules they do not have the source of. Reports your problems at:
*
* LIST-OF-BINARY-MODULES-DROPPERS-EMAIL-ADDRESSES
*************************************************************************

#define MODULE_CONTACT(...)



- Davide

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

[Zwane Mwaikambo]

On Sat, 1 May 2004, Marc Boucher wrote:

> Most third-party module suppliers have been confronted with the same
> issue
> and forced to work around it (in other imperfect and sometimes clumsy
> ways).
> One of them redirects the messages to a separate file and appends
> the following notice:
>
>  > ********************************************************************
>  > * You can safely ignore the above message about tainting the kernel.
>  > * It is completely political and means just that the maintainers of
>  > * of modutils package dislike software that is not distributed under
>  > * an open source license.
>  > ********************************************************************

What's the difference between that and the dialog box Microsoft Windows
gives when you try and install an unsigned or non WHQL driver? In fact
they make a much greater deal about it than our one printk.

	Zwane

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

[Sean Estabrooks]

On Sat, 1 May 2004 15:12:18 -0400
Marc Boucher <marc@linuxant.com> wrote:

> It was already screwed up, and causing unnecessary support burdens
> both on the community ("help! what does tainted mean") and vendors.
> This thread and previous ones have shown ample evidence of that.

Tainting is working just like it is supposed to work.   The reduced
support burden for senior Linux maintainers has been a benefit.

> Let's deal with the root problem and fix the messages, as Rik van Riel
> has suggested.

The kernel maintainers will decide what's best for Linux.   They're the
ones responsible for overseeing Linux.    But if we're going to change
the message i'd prefer something along the lines of:

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

> Most third-party module suppliers have been confronted with the same 
> issue and forced to work around it (in other imperfect and sometimes
> clumsy ways). One of them redirects the messages to a separate file and
> appends the following notice:
> 
>  > ********************************************************************
>  > * You can safely ignore the above message about tainting the kernel.
>  > * It is completely political and means just that the maintainers of
>  > * of modutils package dislike software that is not distributed under
>  > * an open source license.
>  > ********************************************************************

Tough.   Why don't you understand that LINUX IS AN OPEN SOURCE
OPERATING SYSTEM?   Linux is about open source; accommodating
closed source modules is way way down the list of priorities.

> > What's wrong with the printk setting workaround? Simply write a number
> > to the appropriate file before you load the modules.
> >
> > I just tried googling for the relevant post, but failed...
> >
> > He doesn't need to wait for the patches to propogate. He can act on
> > his own scripts immediately in readiness for the next version.
> >
> > Easy.
> 
> Not. We don't use a script to systematically load the modules,
> because they are large and not always required, nor want to
> interfere with the system's normal logging.
>
> Manipulating printk settings or redirecting the superfluous
> messages elsewhere are also ugly hacks, which can
> potentially also divert/hide important messages.

Good.

Regards,
Sean.

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

[Randy.Dunlap]

On Sat, 1 May 2004 15:33:19 -0400 Sean Estabrooks <seanlkml@rogers.com> wrote:

| On Sat, 1 May 2004 15:12:18 -0400
| Marc Boucher <marc@linuxant.com> wrote:
| 
| > It was already screwed up, and causing unnecessary support burdens
| > both on the community ("help! what does tainted mean") and vendors.
| > This thread and previous ones have shown ample evidence of that.
| 
| Tainting is working just like it is supposed to work.   The reduced
| support burden for senior Linux maintainers has been a benefit.
| 
| > Let's deal with the root problem and fix the messages, as Rik van Riel
| > has suggested.
| 
| The kernel maintainers will decide what's best for Linux.   They're the
| ones responsible for overseeing Linux.    But if we're going to change
| the message i'd prefer something along the lines of:
| 
| "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 agree, this is better than the Aunt Tillie message.
(Second sentence could be omitted.  I agree with it,
but it's not in the right setting IMO.)

[snip]

| > > What's wrong with the printk setting workaround? Simply write a number
| > > to the appropriate file before you load the modules.
| > >
| > > I just tried googling for the relevant post, but failed...
| > >
| > > He doesn't need to wait for the patches to propogate. He can act on
| > > his own scripts immediately in readiness for the next version.
| > >
| > > Easy.
| > 
| > Not. We don't use a script to systematically load the modules,
| > because they are large and not always required, nor want to
| > interfere with the system's normal logging.
| >
| > Manipulating printk settings or redirecting the superfluous
| > messages elsewhere are also ugly hacks, which can
| > potentially also divert/hide important messages.

So why is the tainted message to be different?

--
~Randy

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

[Nicolas Pitre]

On Sat, 1 May 2004, Marc Boucher wrote:

> Let's deal with the root problem and fix the messages, as Rik van Riel
> has suggested.

Please do yourself and the rest of us a favor.  Stop waiting and _do_ submit
a patch yourself for precisely that root problem.

That's what you should have done in the first place instead of being lazy,
but it's not too late for Linuxant people to show they care about resolving
this issue, and about the community they rely upon, as much as they care
about their customers.


Nicolas

[PATCH] clarify message and give support contact for non-GPL modules

[Marc Boucher]

On Sat, May 01, 2004 at 03:47:15PM -0400, Nicolas Pitre wrote:
> On Sat, 1 May 2004, Marc Boucher wrote:
> 
> > Let's deal with the root problem and fix the messages, as Rik van Riel
> > has suggested.
> 
> Please do yourself and the rest of us a favor.  Stop waiting and _do_ submit
> a patch yourself for precisely that root problem.
> 
> That's what you should have done in the first place instead of being lazy,
> but it's not too late for Linuxant people to show they care about resolving
> this issue, and about the community they rely upon, as much as they care
> about their customers.

ok, please see tentative patch for 2.6 below, incorporating Rusty's change
to only emit the warning once, and Rik's suggestion to explicitly direct users
to the party responsible for support, if specified as
MODULE_AUTHOR("NAME <EMAIL>").

Constructive comments/improvements welcome.

Marc

-- 
Marc Boucher
Linuxant inc.

--- linux-2.6.6-rc3-bk3/kernel/module.c	2004-05-01 16:06:46.769778360 -0400
+++ linux-2.6.6-rc3-bk3-mb/kernel/module.c	2004-05-01 16:38:02.563614352 -0400
@@ -1125,15 +1125,18 @@
 		|| 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";
 
 	mod->license_gplok = license_is_gpl_compatible(license);
-	if (!mod->license_gplok) {
-		printk(KERN_WARNING "%s: module license '%s' taints kernel.\n",
-		       mod->name, license);
+	if (!mod->license_gplok && !(tainted & TAINT_PROPRIETARY_MODULE)) {
+		printk(KERN_INFO "%s: module has non-GPL license (%s).\n", mod->name, license);
+		if(author)
+			printk(KERN_INFO "%s: for any support issues, please contact %s\n", mod->name, author);
+		else
+			printk(KERN_INFO "%s: the Linux kernel community cannot resolve problems you may encounter when using this module.\n", mod->name);
 		tainted |= TAINT_PROPRIETARY_MODULE;
 	}
 }
@@ -1470,7 +1473,9 @@
 	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] clarify message and give support contact for non-GPL modules

[Sean Estabrooks]

On Sat, 1 May 2004 16:53:36 -0400
Marc Boucher <marc@linuxant.com> wrote:

> Constructive comments/improvements welcome.

I think the following patch is more respectful of the Linux license.  
It also explains to the user why their kernel is now tainted so they
won't be confused when they see "tainted" messages elsewhere.
Also it may encourage more open source drivers which you agree
are better Marc:

--- linux-2.6.6-rc3-bk3/kernel/module.c	2004-05-01 16:06:46.769778360 -0400
+++ linux-2.6.6-rc3-bk3-mb/kernel/module.c	2004-05-01 16:38:02.563614352 -0400
@@ -1125,15 +1125,19 @@
 		|| 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";
 
 	mod->license_gplok = license_is_gpl_compatible(license);
-	if (!mod->license_gplok) {
-		printk(KERN_WARNING "%s: module license '%s' taints kernel.\n",
-		       mod->name, license);
+	if (!mod->license_gplok && !(tainted & TAINT_PROPRIETARY_MODULE)) {
+		printk(KERN_INFO "%s: module has non-GPL license (%s).\n", mod->name, license);
+		printk(KERN_INFO "%s: Please consider supporting vendors that provide open source drivers\n", mod->name);
+		if(author)
+			printk(KERN_INFO "%s: kernel now tainted, for all support contact: %s\n", mod->name, author);
+		else
+			printk(KERN_INFO "%s: kernel now tainted, for all support contact author of this driver\n", mod->name);
 		tainted |= TAINT_PROPRIETARY_MODULE;
 	}
 }
@@ -1470,7 +1473,9 @@
 	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] clarify message and give support contact for non-GPL modules

[Marc Boucher]

Sean,

I think that your wording is problematic, because:

- A module with non-GPL license could be distributed in source form.
- Its author can also be an individual or organization, not necessarily 
a vendor.
- The word "tainted" is confusing and needlessly scary for average 
users.

Marc

On May 1, 2004, at 5:34 PM, Sean Estabrooks wrote:

> On Sat, 1 May 2004 16:53:36 -0400
> Marc Boucher <marc@linuxant.com> wrote:
>
>> Constructive comments/improvements welcome.
>
> I think the following patch is more respectful of the Linux license.
> It also explains to the user why their kernel is now tainted so they
> won't be confused when they see "tainted" messages elsewhere.
> Also it may encourage more open source drivers which you agree
> are better Marc:
>
> --- linux-2.6.6-rc3-bk3/kernel/module.c	2004-05-01 16:06:46.769778360 
> -0400
> +++ linux-2.6.6-rc3-bk3-mb/kernel/module.c	2004-05-01 
> 16:38:02.563614352 -0400
> @@ -1125,15 +1125,19 @@
>  		|| 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";
>
>  	mod->license_gplok = license_is_gpl_compatible(license);
> -	if (!mod->license_gplok) {
> -		printk(KERN_WARNING "%s: module license '%s' taints kernel.\n",
> -		       mod->name, license);
> +	if (!mod->license_gplok && !(tainted & TAINT_PROPRIETARY_MODULE)) {
> +		printk(KERN_INFO "%s: module has non-GPL license (%s).\n", 
> mod->name, license);
> +		printk(KERN_INFO "%s: Please consider supporting vendors that 
> provide open source drivers\n", mod->name);
> +		if(author)
> +			printk(KERN_INFO "%s: kernel now tainted, for all support contact: 
> %s\n", mod->name, author);
> +		else
> +			printk(KERN_INFO "%s: kernel now tainted, for all support contact 
> author of this driver\n", mod->name);
>  		tainted |= TAINT_PROPRIETARY_MODULE;
>  	}
>  }
> @@ -1470,7 +1473,9 @@
>  	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] clarify message and give support contact for non-GPL modules

[Sean Estabrooks]

On Sat, 1 May 2004 17:48:14 -0400
Marc Boucher <marc@linuxant.com> wrote:

> Sean,
> 
> I think that your wording is problematic, because:
> 
> - A module with non-GPL license could be distributed in source form.

That's not a problem.   Feel free to add other checks to suppress this
message for other licenses.

> - Its author can also be an individual or organization, not necessarily 
> a vendor.

Please suggest a better word than vendor so I can update the patch.

> - The word "tainted" is confusing and needlessly scary for average 
> users.

The FACT is the kernel is TAINTED.  It's important that the user
understand why so that when they see TAINTED message in OOPS 
they are not confused.

Re: [PATCH] clarify message and give support contact for non-GPL modules

[Sean Estabrooks]

On Sat, 1 May 2004 17:48:14 -0400
Marc Boucher <marc@linuxant.com> wrote:

> Sean,
> 
> I think that your wording is problematic, because:
> 
> - A module with non-GPL license could be distributed in source form.
> - Its author can also be an individual or organization, not necessarily 
> a vendor.

Patch below attempts to address these concerns.

> - The word "tainted" is confusing and needlessly scary for average 
> users.
> 

Please stop your political agenda of subverting the open source nature of
Linux.   The average user SHOULD find it a scary to run modules
that don't conform to her choice of  OPEN SOURCE OPERATING SYSTEM.    
If the average user wanted to run closed source code she would have picked 
a closed source operating system right?  Lets not let closed source code sneak 
in without putting up big red flags for the user.   Lets make sure that the
USER IS NOT CONFUSED about the nature of the module they're loading.


--- linux-2.6.6-rc3-bk3/kernel/module.c	2004-05-01 16:06:46.769778360 -0400
+++ linux-2.6.6-rc3-bk3-mb/kernel/module.c	2004-05-01 16:38:02.563614352 -0400
@@ -1125,15 +1125,19 @@
 		|| 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";
 
 	mod->license_gplok = license_is_gpl_compatible(license);
-	if (!mod->license_gplok) {
-		printk(KERN_WARNING "%s: module license '%s' taints kernel.\n",
-		       mod->name, license);
+	if (!mod->license_gplok && !(tainted & TAINT_PROPRIETARY_MODULE)) {
+		printk(KERN_INFO "%s: module has non-GPL license (%s) kernel is now tainted.\n", mod->name, license);
+		printk(KERN_INFO "%s: Please consider supporting those who provide GPL licensed drivers\n", mod->name);
+		if(author)
+			printk(KERN_INFO "%s: tainted kernel means all support must come from: %s\n", mod->name, author);
+		else
+			printk(KERN_INFO "%s: tainted kernel means all support must come from driver author\n", mod->name);
 		tainted |= TAINT_PROPRIETARY_MODULE;
 	}
 }
@@ -1470,7 +1473,9 @@
 	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] clarify message and give support contact for non-GPL modules

[Marc Boucher]

On May 1, 2004, at 6:22 PM, Sean Estabrooks wrote:

>
>> - The word "tainted" is confusing and needlessly scary for average
>> users.
>>
>
> Please stop your political agenda of subverting the open source nature 
> of
> Linux.   The average user SHOULD find it a scary to run modules
> that don't conform to her choice of  OPEN SOURCE OPERATING SYSTEM.
> If the average user wanted to run closed source code she would have 
> picked
> a closed source operating system right?  Lets not let closed source 
> code sneak
> in without putting up big red flags for the user.   Lets make sure 
> that the
> USER IS NOT CONFUSED about the nature of the module they're loading.

Everyone has an agenda.

Ours is to find reasonable compromise between corporate and community 
interests so that Linux users are able to use widespread hardware for 
which open-source drivers are otherwise not available or not adequate. 
There are several types of devices, like softmodems, for which there is 
currently no other alternative method. We believe that this is a 
legitimate business, and beneficial to the linux community. Our goal is 
not to harm open-source, to the contrary, help it spread by removing 
some of the obstacles. Likewise, we help vendors bring their technology 
to Linux. We encourage them to fully open-source it when possible and 
economically feasible (like in the case of Conexant's riptide driver or 
ethernet chipsets for which we have obtained and shared full source 
with the community). Otherwise, we try deliver mixed-binary/source 
drivers in the most convenient form for users.

Regards
Marc

Re: [PATCH] clarify message and give support contact for non-GPL modules

[viro]

On Sat, May 01, 2004 at 06:53:55PM -0400, Marc Boucher wrote:
 
> Everyone has an agenda.

Care to offer proof or apologies?

Re: [PATCH] clarify message and give support contact for non-GPL modules

[Xavier Bestel]

On Sun, 2004-05-02 at 01:10, viro@parcelfarce.linux.theplanet.co.uk
wrote:
> On Sat, May 01, 2004 at 06:53:55PM -0400, Marc Boucher wrote:
>  
> > Everyone has an agenda.
> 
> Care to offer proof or apologies?

Well, he vehemently contradicted himself just before:

> > I swear to god, there was no other intent nor purpose.

You could take that as a proof someone's got no agenda :)

	Xav

Re: [PATCH] clarify message and give support contact for non-GPL modules

[Timothy Miller]

viro@parcelfarce.linux.theplanet.co.uk wrote:
> On Sat, May 01, 2004 at 06:53:55PM -0400, Marc Boucher wrote:
>  
> 
>>Everyone has an agenda.
> 
> 
> Care to offer proof or apologies?


My agenda is to have fun while advancing science and intellectual commons.

Re: [PATCH] clarify message and give support contact for non-GPL modules

[Linus Torvalds]

On Sat, 1 May 2004, Marc Boucher wrote:
> 
> I think that your wording is problematic, because:

No. 

You seem to believe that you can get something for nothing.

Wrong.

You offer nothing to the open-source community, you get nothing back. That 
means very much that people don't support what you're doing, and you 
should realize that as far as the rest of the kernel is concerned, you 
ARE tainting it. 

The GPL is about a symbiotic relationship, where people help each other. 
In contrast, a binary module is a parasite - giving nothing back to the 
community. 

So live with that fact. Don't try to make it look like anything else.

		Linus

Re: [PATCH] clarify message and give support contact for non-GPL modules

[Marc Boucher]

Linus,

As  previously mentioned, I have offered many patches and a lot of 
source to the community throughout the last 15 years. Either personally 
or via Linuxant, under various licenses (including the GPL) depending 
on the constraints imposed by each situation, and continue doing so. In 
the workaround case, we should have admittedly sent a patch earlier 
instead of putting in the \0 and I sincerely apologized for that.

The modules in question are not binary-only, but mixed source/binary. 
With the submitted patch, we are also offering to take as much support 
burden off the community by clarifying the messages to explicitly 
direct users to where they should go for help when using third-party 
modules.

With all due respect, your claims that we are offering nothing / not 
giving back are not factual and you should not take position based on 
either incorrect information or a very narrow / alarmist interpretation 
of what we are doing.

Regards
Marc

On May 1, 2004, at 6:48 PM, Linus Torvalds wrote:
>
> On Sat, 1 May 2004, Marc Boucher wrote:
>>
>> I think that your wording is problematic, because:
>
> No.
>
> You seem to believe that you can get something for nothing.
>
> Wrong.
>
> You offer nothing to the open-source community, you get nothing back. 
> That
> means very much that people don't support what you're doing, and you
> should realize that as far as the rest of the kernel is concerned, you
> ARE tainting it.
>
> The GPL is about a symbiotic relationship, where people help each 
> other.
> In contrast, a binary module is a parasite - giving nothing back to the
> community.
>
> So live with that fact. Don't try to make it look like anything else.
>
> 		Linus
>

Re: [PATCH] clarify message and give support contact for non-GPL modules

[Linus Torvalds]

On Sat, 1 May 2004, Marc Boucher wrote:
> 
> As  previously mentioned, I have offered many patches and a lot of 
> source to the community throughout the last 15 years. Either personally 
> or via Linuxant, under various licenses (including the GPL) depending 
> on the constraints imposed by each situation, and continue doing so.

Marc, this is not anything person about you.

Think of it this way: what if _I_ were to make a binary-only module, and 
I'd claim that because I've given a lot to Linux, that binary-only module 
would be somehow ok, because while that module itself doesn't help other 
developers, I've done so using other means?

Would that make sense? Hell no. That would be equally wrong as if any 
all-binary-never-released-source person would do it.

So I'm not claiming that _you_ don't give anything back. It's purely about 
the module, which is not giving anything back to developers, and as such 
you shouldn't expect us to respect it.

> The modules in question are not binary-only, but mixed source/binary. 
> With the submitted patch, we are also offering to take as much support 
> burden off the community by clarifying the messages to explicitly 
> direct users to where they should go for help when using third-party 
> modules.

Yes, I think that patch in general makes sense. But I literally _do_ want 
people to be alarmed about tainting, because it's a DAMN BIG issue. 
Suddenly you go from a system that is openly supported by a lot of 
individuals and a number of companies, to one that is not. It's literally 
the difference between "open" and "proprietary", and that is an IMPORTANT 
difference. 

So I don't see how you can really try to minimize that HUGE difference, 
without effectively saying that you don't respect the work and the ethics 
that have gone into Linux in the first place.

See what I'm saying? A proprietary module is more a fundamental issue than
you seem to give it credit for being, and users should be told in big 
blinking neon letters about it.

			Linus

Re: [PATCH] clarify message and give support contact for non-GPL modules

[Marc Boucher]

On May 1, 2004, at 8:22 PM, Linus Torvalds wrote:
>
> So I'm not claiming that _you_ don't give anything back. It's purely 
> about
> the module, which is not giving anything back to developers, and as 
> such
> you shouldn't expect us to respect it.

The HSF modules give back what they can right now, which is all 
operating system source, in an attempt to strike a reasonable 
compromise.

>
>> The modules in question are not binary-only, but mixed source/binary.
>> With the submitted patch, we are also offering to take as much support
>> burden off the community by clarifying the messages to explicitly
>> direct users to where they should go for help when using third-party
>> modules.
>
> Yes, I think that patch in general makes sense.

ok

> But I literally _do_ want
> people to be alarmed about tainting, because it's a DAMN BIG issue.
> Suddenly you go from a system that is openly supported by a lot of
> individuals and a number of companies, to one that is not. It's 
> literally
> the difference between "open" and "proprietary", and that is an 
> IMPORTANT
> difference.

Understood. So perhaps we should call it "open" and "proprietary" which 
are clear, well known words. "tainted" is honestly confusing/hard to 
understand for many ordinary users, especially international/non-native 
speakers who do not encounter the word that often (thankfully ;-).

>
> So I don't see how you can really try to minimize that HUGE difference,
> without effectively saying that you don't respect the work and the 
> ethics
> that have gone into Linux in the first place.
>
> See what I'm saying? A proprietary module is more a fundamental issue 
> than
> you seem to give it credit for being, and users should be told in big
> blinking neon letters about it.

Yes, I see what you are saying and agree that the user should be told 
*once* about the proprietary module, but I don't know how you will 
manage to make it look like blinking neon from within the kernel ;-)

Marc

>
> 			Linus
>

Re: [PATCH] clarify message and give support contact for non-GPL modules

[Sean Estabrooks]

On Sat, 1 May 2004 21:02:20 -0400
Marc Boucher <marc@linuxant.com> wrote:

> Understood. So perhaps we should call it "open" and "proprietary" which 
> are clear, well known words. "tainted" is honestly confusing/hard to 
> understand for many ordinary users, especially international/non-native 
> speakers who do not encounter the word that often (thankfully ;-).

No.  It's tainted.  And hopefully if the user is concerned or confused about this
word they will educate themself on the issues involved.    They might even
then support hardware companies that support open source development.
Nobody is forcing anything on them, and the module will still load and run.

Linux is an open source operating system.  There is nothing wrong with
promoting and protecting the code and license.

I've been looking at the latest version of the patch and thinking that it is really
wrong for any message to be displayed only once.   If the user is unfortunate 
enough to be loading two or more closed-source modules, the second
module should not be hidden by the first.   The author of the second module
should not have their name hidden just because another module was loaded
first.

So here is another attempt at the patch.   I think it addresses everything
that has been criticized.  It  makes sure the author of all non-GPL modules 
are shown and returns the message to be a warning instead of info:

--- linux-2.6.6-rc3-bk3/kernel/module.c	2004-05-01 16:06:46.769778360 -0400
+++ linux-2.6.6-rc3-bk3-mb/kernel/module.c	2004-05-01 16:38:02.563614352 -0400
@@ -1125,15 +1125,19 @@
 		|| 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";
 
 	mod->license_gplok = license_is_gpl_compatible(license);
-	if (!mod->license_gplok) {
-		printk(KERN_WARNING "%s: module license '%s' taints kernel.\n",
-		       mod->name, license);
+	if (!mod->license_gplok) {
+		printk(KERN_WARNING "%s: module has non-GPL license (%s) **KERNEL IS NOW TAINTED**.\n", mod->name, license);
+		printk(KERN_WARNING "%s: Please consider supporting those who provide GPL licensed drivers\n", mod->name);
+		if(author)
+			printk(KERN_WARNING "%s: Tainted kernel means support is only available from: %s\n", mod->name, author);
+		else
+			printk(KERN_WARNING "%s: Tainted kernel means support is only available from the author of this driver\n", mod->name);
 		tainted |= TAINT_PROPRIETARY_MODULE;
 	}
 }
@@ -1470,7 +1473,9 @@
 	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] clarify message and give support contact for non-GPL modules

[Paul Rolland]

Hello,

I'm definitely no native English speaker, but I wanted to give my pov
on this topic...

> > Understood. So perhaps we should call it "open" and 
> "proprietary" which 
> > are clear, well known words. "tainted" is honestly 
> confusing/hard to 
> > understand for many ordinary users, especially 
> international/non-native 
> > speakers who do not encounter the word that often (thankfully ;-).
> 
> No.  It's tainted.  And hopefully if the user is concerned or 

Agreed. Once you have loaded such a module, your kernel is really
"tainted" by something that cannot really be controlled.
Proprietary is too much neutral and doesn't reflect what you are
now running : some piece of code which may by bloated without anyone
being able to control it.

> Linux is an open source operating system.  There is nothing wrong with
> promoting and protecting the code and license.
Correct.
 
> I've been looking at the latest version of the patch and 
> thinking that it is really
> wrong for any message to be displayed only once.   If the 
> user is unfortunate 
> enough to be loading two or more closed-source modules, the second
> module should not be hidden by the first.   The author of the 
> second module
> should not have their name hidden just because another module 
> was loaded first.

Agreed too.

This patch should make its way in the kernel, so that people are
aware they are using closed-source code.

I simply hope that some "vendors" will not alter kernel code before
building to remove such a warning if they include closed source
module in their distro.

Regards,
Paul

Paul Rolland, rol(at)as2917.net
ex-AS2917 Network administrator and Peering Coordinator

--

Please no HTML, I'm not a browser - Pas d'HTML, je ne suis pas un navigateur

"Some people dream of success... while others wake up and work hard at it" 

Re: [PATCH] clarify message and give support contact for non-GPL modules

[Marc Boucher]

On May 2, 2004, at 9:05 AM, Paul Rolland wrote:
>
> Agreed. Once you have loaded such a module, your kernel is really
> "tainted" by something that cannot really be controlled.
> Proprietary is too much neutral and doesn't reflect what you are
> now running : some piece of code which may by bloated without anyone
> being able to control it.

There will always be things in life that cannot be controlled. The 
kernel already depends on (by being called by, or itself calling) 
uncontrolled proprietary code in many environments without telling 
users about it. Informing people about this is perfectly ok,  
unnecessarily scaring or confusing them is not.

> I simply hope that some "vendors" will not alter kernel code before
> building to remove such a warning if they include closed source
> module in their distro.

Very good point. You can make things as negative-sounding, politically 
hostile as you want, but Linux distribution vendors would be perfectly 
free under the GPL to modify the kernel to remove or attenuate 
exaggerated messages and any other hostile measures if necessary.

If the messages are reasonable and clear, no-one will want/try to 
remove or avoid them, and people will be properly informed.

Marc

Re: [PATCH] clarify message and give support contact for non-GPL modules

[Sean Estabrooks]

On Sun, 2 May 2004 11:35:37 -0400
Marc Boucher <marc@linuxant.com> wrote:

> There will always be things in life that cannot be controlled. The 
> kernel already depends on (by being called by, or itself calling) 
> uncontrolled proprietary code in many environments without telling 
> users about it. Informing people about this is perfectly ok,  
> unnecessarily scaring or confusing them is not.

Agreed.

> Very good point. You can make things as negative-sounding, politically 
> hostile as you want, but Linux distribution vendors would be perfectly 
> free under the GPL to modify the kernel to remove or attenuate 
> exaggerated messages and any other hostile measures if necessary.

Yes.  You're right.

> If the messages are reasonable and clear, no-one will want/try to 
> remove or avoid them, and people will be properly informed.

That is what the latest patch attempts to do while still making sure 
that users are not fooled into thinking they're running an open 
source operating system.

Cheers,
Sean

Re: [PATCH] clarify message and give support contact for non-GPL modules

[Timothy Miller]

Marc Boucher wrote:
> 
> Linus,
> 
> As  previously mentioned, I have offered many patches and a lot of 
> source to the community throughout the last 15 years. Either personally 
> or via Linuxant, under various licenses (including the GPL) depending on 
> the constraints imposed by each situation, and continue doing so. In the 
> workaround case, we should have admittedly sent a patch earlier instead 
> of putting in the \0 and I sincerely apologized for that.
> 
> The modules in question are not binary-only, but mixed source/binary. 
> With the submitted patch, we are also offering to take as much support 
> burden off the community by clarifying the messages to explicitly direct 
> users to where they should go for help when using third-party modules.
> 
> With all due respect, your claims that we are offering nothing / not 
> giving back are not factual and you should not take position based on 
> either incorrect information or a very narrow / alarmist interpretation 
> of what we are doing.
> 
> Regards
> Marc
> 


Marc,

Everything you say betrays the fact that the Free Software mentality is 
not a consideration in your thinking.  You clearly think it is, but it 
is clearly not.  This argument you're speaking one language, and you're 
speaking another.  Before you can get along with us, you have to learn 
to think like us.

Until you grok the Free Software mentality, you will continue to get flamed.

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

[Martin J. Bligh]

>>> All bugs can be debugged or fixed, it's a matter of how hard it is
>>> to do (generally easier with open-source) and *who* is responsible
>>> for doing it (i.e. supporting the modules).
>> 
>> Yes, exactly. The tainted mechanism is there to tell us that it's not
>> *our* problem to support it. And you deliberately screwed that up,
>> which is why everybody is pissed at you.
> 
> It was already screwed up, and causing unnecessary support burdens
> both on the community ("help! what does tainted mean") and vendors.
> This thread and previous ones have shown ample evidence of that.
> Let's deal with the root problem and fix the messages, as Rik van Riel
> has suggested.
> 
> Most third-party module suppliers have been confronted with the same issue
> and forced to work around it (in other imperfect and sometimes clumsy ways).

Odd that none of them just submitted a patch to fix the "real problem" then.
Sorry, I don't believe that was your only intent.

> One of them redirects the messages to a separate file and appends
> the following notice:
>
>  > ********************************************************************
>  > * You can safely ignore the above message about tainting the kernel.
>  > * It is completely political and means just that the maintainers of
>  > * of modutils package dislike software that is not distributed under
>  > * an open source license.
>  > ********************************************************************

Which is bullshit - It's not political, it's a matter of support. Problems
that appeared to be VM issues, or other things, turned out to be binary
driver issues, which we can't fix, and is a total waste of our time. 
Whether you agree with what we chose to support or not is completely
immaterial - it's not your call.

M.

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

[Marc Boucher]

On May 1, 2004, at 4:47 PM, Martin J. Bligh wrote:

>>>> All bugs can be debugged or fixed, it's a matter of how hard it is
>>>> to do (generally easier with open-source) and *who* is responsible
>>>> for doing it (i.e. supporting the modules).
>>>
>>> Yes, exactly. The tainted mechanism is there to tell us that it's not
>>> *our* problem to support it. And you deliberately screwed that up,
>>> which is why everybody is pissed at you.
>>
>> It was already screwed up, and causing unnecessary support burdens
>> both on the community ("help! what does tainted mean") and vendors.
>> This thread and previous ones have shown ample evidence of that.
>> Let's deal with the root problem and fix the messages, as Rik van Riel
>> has suggested.
>>
>> Most third-party module suppliers have been confronted with the same 
>> issue
>> and forced to work around it (in other imperfect and sometimes clumsy 
>> ways).
>
> Odd that none of them just submitted a patch to fix the "real problem" 
> then.
> Sorry, I don't believe that was your only intent.

So what do you think it was? I swear to god, there was no other intent 
nor purpose.

We have just submitted a patch to address the issue. Hopefully it (or 
something
similar) will make it in and the matter will become history.

Marc

--
Marc Boucher
Linuxant inc.

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

[Horst von Brand]

Marc Boucher <marc@linuxant.com> said:
> On May 1, 2004, at 1:07 AM, Martin J. Bligh wrote:
> 
> >> All bugs can be debugged or fixed, it's a matter of how hard it is
> >> to do (generally easier with open-source) and *who* is responsible
> >> for doing it (i.e. supporting the modules).
> >
> > Yes, exactly. The tainted mechanism is there to tell us that it's not
> > *our* problem to support it. And you deliberately screwed that up,
> > which is why everybody is pissed at you.
> 
> It was already screwed up, and causing unnecessary support burdens
> both on the community ("help! what does tainted mean")

A minor annoyance, no head hacker did ever respond to that on LKML.

>                                                        and vendors.

... got what was comming to them. A-OK.

> This thread and previous ones have shown ample evidence of that.

Of your stubborness, clearly.

> Let's deal with the root problem and fix the messages, as Rik van Riel
> has suggested.

Your help is welcome.
-- 
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

[Keith D Burgess Jr]

>>And I agree we should stop this thread now.

One thing that seems consistent here is that most agree on this point. 
To add a bit of comedy, picture this at the place you work:

Mistakenly, a broadcast email goes out to everyone (ooops should have 
restricted the total number of users in the to/cc/bcc fields). Then 
your IT security group sends out a broadcast telling everyone to delete 
it and not to "reply to all." You continue to get people replying to 
all with the body as below:

"Didn't you see the IT security bulletin? It said not to reply to all 
but to delete this email!"

I am sensing that is what we are all doing here :) (myself included).



----------------------------------------------
Mailblocks - A Better Way to Do Email
http://about.mailblocks.com/info

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

[Keith D Burgess Jr]

A couple days ago when I stumbled onto this discussion, I was prompted 
to at least post an opinion from a user perspective. Having followed 
along since then, I am beginning to wonder why I am so interested in 
the Linux community in the first place. I have to admit, my chin is 
still on the floor having read some of the personal attacks directed 
towards Marc. Why, for some, has this become a personal issue and not a 
technical one? I think Marc summed it up best (a few times) by saying:

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

Can't we respect this as his explanation and move on so these efforts 
can be better directed towards improving the kernel? Hell - Marc has 
alot of work to-do in order for driverloader to be compatible with 4K 
stacks ;)  (BTW I have no idea how you can support Fedora but it is 
appreciated.) There seems to be a couple posters here that understand 
why this workaround was done and agree that there needs to be a better 
way than seeing repeated "tainted" messages. In my opinion, this is the 
perspective that should have been taken from the start. Or at least 
once the list realized the intent and received Marc's appologies.

P.S. Thanks to those who offered your opinions in agreement with mine 
via email but not on the list.

Respectfully,
Keith


----------------------------------------------
Mailblocks - A Better Way to Do Email
http://about.mailblocks.com/info

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

[Timothy Miller]

Keith D Burgess Jr wrote:
> A couple days ago when I stumbled onto this discussion, I was prompted 
> to at least post an opinion from a user perspective. Having followed 
> along since then, I am beginning to wonder why I am so interested in the 
> Linux community in the first place. I have to admit, my chin is still on 
> the floor having read some of the personal attacks directed towards 
> Marc. Why, for some, has this become a personal issue and not a 
> technical one? I think Marc summed it up best (a few times) by saying:

I never felt it was a personal issue.  It's a technical problem, and 
it's a legal problem.

No one faults Marc for what he wanted to do.  We only fault him for the 
way he went about doing it.

I'm ambivalent about the future impact of supporting companies who do 
not want to develop open-source drivers, but I DO support Marc's right 
to develop software which aids in using proprietary drivers under Linux 
for the sake of users who otherwise could not use their hardware.  That 
is to say, there are certain philosophical aspects of developing such a 
wrapper that concern me, but I respect Marc's right to do it anyway.

> 
>>> I repeat, the \0 is purely a technical workaround, done without any 
> 
> mischievous intent.
> 
> Can't we respect this as his explanation and move on so these efforts 
> can be better directed towards improving the kernel? 

We respect this explanation, but this explanation has nothing to do with 
what we're complaining about, which is why this discussion continues.

It's like being asked why you stubbed your classmate's toe and 
responding "because it's Thursday".  Well, not THAT far off, but it 
demonstrates my point.

We DO accept the fact that he didn't MEAN to break the law.  It's just 
not a valid excuse!

> Hell - Marc has 
> alot of work to-do in order for driverloader to be compatible with 4K 
> stacks ;)  (BTW I have no idea how you can support Fedora but it is 
> appreciated.) There seems to be a couple posters here that understand 
> why this workaround was done and agree that there needs to be a better 
> way than seeing repeated "tainted" messages. In my opinion, this is the 
> perspective that should have been taken from the start. Or at least once 
> the list realized the intent and received Marc's appologies.

And that's what's happening.  It's Marc's insistence that he's innocent 
on the grounds that he didn't mean it that has so many people all riled 
up about it.

Yes, we're "letting him off" (ie. not suing for past infractions) on the 
grounds that he didn't mean it, but we want him to understand why he 
shouldn't have done it and stop doing it.  He doesn't seem to understand 
why it was wrong, and that bugs us.

If Marc had just said, "OOPS!  Sorry.  That was a stupid error on my 
part.  I'll fix it and never do it again," then this argument would 
never have happened.

Mistakes happen all the time.  We're just used to people who are able to 
learn from their mistakes.

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

[Richard B. Johnson]

On Fri, 30 Apr 2004, Keith D Burgess Jr wrote:

> A couple days ago when I stumbled onto this discussion, I was prompted
> to at least post an opinion from a user perspective. Having followed
> along since then, I am beginning to wonder why I am so interested in
> the Linux community in the first place. I have to admit, my chin is
> still on the floor having read some of the personal attacks directed
> towards Marc. Why, for some, has this become a personal issue and not a
> technical one? I think Marc summed it up best (a few times) by saying:
>
> >> I repeat, the \0 is purely a technical workaround, done without any
> mischievous intent.
>
> Can't we respect this as his explanation and move on so these efforts
> can be better directed towards improving the kernel? Hell - Marc has
> alot of work to-do in order for driverloader to be compatible with 4K
> stacks ;)  (BTW I have no idea how you can support Fedora but it is
> appreciated.) There seems to be a couple posters here that understand
> why this workaround was done and agree that there needs to be a better
> way than seeing repeated "tainted" messages. In my opinion, this is the
> perspective that should have been taken from the start. Or at least
> once the list realized the intent and received Marc's appologies.
>
> P.S. Thanks to those who offered your opinions in agreement with mine
> via email but not on the list.
>
> Respectfully,
> Keith
>
>

Well it works like this:

Presume you devoted a lot of time and effort to writing
a driver for a popular SCSI Disk controller.

All of the sudden, you get a rash of complaints that
your driver is crashing systems, trashing data or otherwise
creating havoc.

So, you spend a few hundred hours of your time going over
the code line-by-line and you can't find anything wrong.
Also, you keep getting hate mail from persons who claim
that you have destroyed a lifetime of work because your
controller trashed their data.

Eventually you find that some software for a "@!&*($^@*(%"
screen card is trashing your code. That's the reason why
you've been getting blamed for destroying everybody's
data. You can't look at the software for that screen-card
because some idiot in Marketing thought that the 200 lines
of Linux-trashing software was "proprietary".

So, you make sure that if anybody in the future writes
such trash or potential trash and loads it into the kernel
where there is no protection from it, it is appropriately
marked.

Then, when somebody sends you a crash-dump and it is marked
"Tainted", you can tell them to unload whatever drivers are
causing that effect and then try your driver again. This
will save you untold weeks of agony in the future.

Now we have somebody who decides to "beat the system", to
allow tainted modules without them being displayed. Of
course the persons who have wasted a significant portion
of their lives looking for bugs that were caused by
secret drivers, will get a might bit angry.

Everybody has a right to load any kind of manure they
want into their own copy of the kernel. They don't have
any right to subject innocent module-writers to the
poison of a module they can't inspect.

Also, a module that is loaded into the kernel can
do __anything__. It can inspect the contents of your
hard disks and send whatever it wants to some unfriendly
company (Like Back-web). It can send information about
the letters you write and the Web Pages you frequent
(like Carnivore). It can use your CPU resources to
compile a security-liability index about your life-
style and send the results to the NSA (like Magic Lantern).

Certainly you should want to inspect anything that
is running on your system. This means that you need
to be able to inspect the source-code.

Cheers,
Dick Johnson
Penguin : Linux version 2.4.26 on an i686 machine (5557.45 BogoMips).
            Note 96.31% of all statistics are fiction.

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

[Horst von Brand]

Keith D Burgess Jr <kburgessjr@mailblocks.com> said:
> A couple days ago when I stumbled onto this discussion, I was prompted 
> to at least post an opinion from a user perspective. Having followed 
> along since then, I am beginning to wonder why I am so interested in 
> the Linux community in the first place. I have to admit, my chin is 
> still on the floor having read some of the personal attacks directed 
> towards Marc. Why, for some, has this become a personal issue and not a 
> technical one? I think Marc summed it up best (a few times) by saying:
> 
> >> I repeat, the \0 is purely a technical workaround, done without any 
> >> mischievous intent.

Exactly the same way a lockpick is a "purely technical workaround" for
doors the owner "accidentally" locked...

> Can't we respect this as his explanation and move on so these efforts 
> can be better directed towards improving the kernel?

Very true.

>                                                      Hell - Marc has 
> alot of work to-do in order for driverloader to be compatible with 4K 
> stacks ;)

His efforts should better be directed at getting real (open source) support
in place. But it is his calling in the end, I don't presume to decide what
he should do with his time. As long as the relevant licenses (and hopefully
also the wishes of the creators of the kernel) are respected.
-- 
Dr. Horst H. von Brand                   User #22616 counter.li.org
Departamento de Informatica                     Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria              +56 32 654239
Casilla 110-V, Valparaiso, Chile                Fax:  +56 32 797513

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

[Rick Zeman]

On 4/28/04 at 8:02 PM (GMT-0400), Rik van Riel <riel@redhat.com> wrote:

>I wouldn't be averse to changing the text the kernel prints
>when loading a module with an incompatible license. If the
>text "$MOD_FOO: module license '$BLAH' taints kernel." upsets
>the users, it's easy enough to change it.
>
>How about the following?
>
>"Due to $MOD_FOO's license ($BLAH), the Linux kernel community
>cannot resolve problems you may encounter. Please contact
>$MODULE_VENDOR for support issues."

That's too sensible:  Linux wouldn't be Linux without incomprehensible
messages like:

$ sudo urpmi /home/rzeman/kernel-smp-2.4.25.4mdk-1-1mdk.i586.rpm 

installing /home/rzeman/kernel-smp-2.4.25.4mdk-1-1mdk.i586.rpm
Preparing...
##################################################
   1:kernel-smp-2.4.25.4mdk
##################################################
look like there was a problem, the default vmlinuz version is not the same 
of the initrd which mean you have a mdk kernel and not a mdk initrd you may
go in trouble

or doing a menuconfig on a new 2.4.26 kernel and having it nicely tell me
that my choice HAD to be a module, not built in, because it depends upon
something else already selected as a module--without bothering to deign to
say what the dependency was so I had to play grand guessing games.

/this week's irritations.

--
Mac OS X: Because making UNIX user-friendly was easier than fixing Windows.

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

[Keith D Burgess Jr]

Marc -

Wanted to take a moment to thank you for the incredible job you and 
Linuxant have done supporting the Linux community. I have been 
following the threads on the lkml and must say that I am appalled at 
the way you are being <personally> treated. If it were not for 
Linuxant, owners of the "linux unfriendly" chipsets would be SOL. I for 
one was pis**d when I found out my 2100b wireless card in my brand 
spanking new X31 was not supported; until of course, I stumbled upon 
driverloader. While there are other "free" alternatives out there and 
also the ipw2100 project, I for one do not want to go through the 
effort of compiling, modifying kernel parameters etc. For me, the $20 
spent on driverloader was well worth it and allowed me to scrap XP for 
Linux. And how about support? I surely appreciated the personal 
support, and hours, you spent on my laptop hanging issue. Would I 
recieve that from the other project's community members?

With that said, I must admit that I was one of those confused users 
when I first saw the tainted kernel message(s). I have used Linux (I 
repeat, <<used>> Linux) since about 96 or so. I don't claim to be an 
expert or a developer but by no means am a Linux newbie. Just because I 
am more interested in applications, window managers and graphical 
environments such as gnome and kde, then meaningless (to the user) 
kernel messages, does not make me a stupid user. However, not fully 
understanding the kernel message, I thought something was wrong the 
first time I noticed it (VMware modules as I recall.)

The Kernel developers should be focused on bringing Linux to the 
attention of EVERY desktop user, not just those who are knowledgeable 
of kernel messages, configuration, APIs and the GPL. Why do you think 
that distributions such as Xandros have become so popular to users 
switching to Linux? It seems rather simple to me; the product just 
plain works! Is the diamond of their OS, the file manager, released 
under the GPL? Of course not, and the users do not care! They just want 
to be able to integrate into existing Windows environments, 
authenticate against their NT/AD domains and be able to map to existing 
Windows network resources - all seamlessly.

In summary, I firmly feel that there needs to be a mindset change if 
Linux is to eat away at Windows market share on the desktops. Let's 
take a certain Linux distributor as an example; here is a quote from a 
recent posting on the 4K stacks issue:

"Too bad. External binary modules never have, and never will hold back 
development. NVIDIA need to issue driver updates that work accordingly."

Reworded from a user-focused perspective:

"External binary modules shouldn't hold back development. Although 
NVIDIA needs to issue driver updates that work accordingly, <> 
understands that our users are the number one priority. Therefore, 
until new modules are released, we will offer a workaround for users 
who are effected."

Sincerely,
Keith


----------------------------------------------
Mailblocks - A Better Way to Do Email
http://about.mailblocks.com/info

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

[Tim Connors]

Keith D Burgess Jr <kburgessjr@mailblocks.com> said on Wed, 28 Apr 2004 11:56:38 -0700:
> The Kernel developers should be focused on bringing Linux to the 
> attention of EVERY desktop user, not just those who are knowledgeable 
> of kernel messages, configuration, APIs and the GPL. Why do you think 

Um, I don't think you presonally know why most linux kernel developers
are working. Some work to make a technically superior OS. Some work
for idealogical reasons.

I suspect not many are "focused on bringing Linux to the attention of
EVERY desktop user" because they are not interested in that. That's a
job for someone in suits. And just because you think they shoudl be
focussed on that doesn't mean they should be.

-- 
TimC -- http://astronomy.swin.edu.au/staff/tconnors/
Brown's Theorem (Physics III student, Usyd):
"The only thing that behaves like a billiard 
ball, is a billiard ball"

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

[David Woodhouse]

On Wed, 2004-04-28 at 11:56 -0700, Keith D Burgess Jr wrote:
> In summary, I firmly feel that there needs to be a mindset change if 
> Linux is to eat away at Windows market share on the desktops. Let's 
> take a certain Linux distributor as an example; here is a quote from a 
> recent posting on the 4K stacks issue:

Quite frankly I don't give a two hoots about market share. If I wanted
my code to be used by third parties _without_ them having to free their
own code, then I'd have contributed to a BSD-licensed kernel instead of
a GPL'd kernel; or I'd have dual-licensed it.

If you think the BSD approach is so much more conducive to market share,
and if you think market share is more important than freedom, then go
elsewhere. Maybe you can use Windows -- that has BSD code in it, doesn't
it? Or MacOS X perhaps? I don't really care much -- just go away.

> "Too bad. External binary modules never have, and never will hold back 
> development. NVIDIA need to issue driver updates that work accordingly."
> 
> Reworded from a user-focused perspective:

Reworded from a copyright-holder's perspective:

"Use a copy of my work outside the terms of its licence, and other than
provided for by 'Fair Use' doctrine¹, and you are committing a criminal
offence."

-- 
dwmw2

¹ cf. http://www.hmso.gov.uk/acts/acts1988/Ukpga_19880048_en_4.htm

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

[Robert M. Stockmann]

On Tue, 27 Apr 2004, Tim Hockin wrote:

> On Wed, Apr 28, 2004 at 02:56:16AM +0200, Robert M. Stockmann wrote:
> > > Care to show me where they use unnamed structures, and how it has anything
> > > to do with binary modules?
> > 
> > fasttrak.h :
> > #define ft3xx {							\
> > 	next: NULL,						\
> 	...
> > } 
> > #endif
> 
> > This header file is needed to be able to link ft3xx.o . In which way binary 
> > incompatibility is introduced, inside this case is hard to tell. We
> > will never know i guess , since the type and size of the above components
> > is hidden inside the binary only part :
> 
> Do you know C, or just pretend to?

I am no kernel coder, if its that what you mean. 

> 
> Those are structure initializers, not unnamed types.  They've provided a
> macro to use to initialize instances of some structure.
> 
> fasttrak.c:890 shows
> 	static Scsi_Host_Template driver_template = ft3xx;
> 
> The structure definition for 'Scsi_Host_Template' is in
> /usr/src/linux/drivers/scsi/hosts.h which is included in fasttrak.c.

Ok you got me there. I would suggest to change fasttrak.h like this
to obtain better readability :

#ifndef _ft3xx_h
#define _ft3xx_h

#include <linux/version.h>
#include "/usr/src/linux/drivers/scsi/hosts.h"

#if LINUX_VERSION_CODE >= KERNEL_VERSION(2,4,0)
#define ft3xx {                                                 \
        next: NULL,                                             \
	...
};

> 
> If you run it thru the preprocessor, you'd see
> 	static Scsi_Host_Template driver_template = {
> 		next: NULL,
> 		...
> 	};
> 
> No opaque structs.  No unnamed types.  No magic.  It's not pretty, and
> it's bound to break on any non-standard rig, but it's NOT what you claim
> it is.
> 
> The initializer style (foo:  value) is probably why gcc-2.95 blows up, but
> I don't have it here to verify.

It does, which awakened me all up in arms. certainly if gcc-2.95.3
is still mentioned as recommended gcc version for the ia32 platform 
inside /usr/src/linux/Documentation/Changes. It pissed me off not
being able to use gcc-2.95.3 when using that fasttrak driver.

> 
> You really should know what you're talking about before you launch a
> crusade against something.
> 

I agree the fasttrak partial-source kit is not the all defining example.
Still i believe nasty stuff is possible.

Robert
-- 
Robert M. Stockmann - RHCE
Network Engineer - UNIX/Linux Specialist
crashrecovery.org  stock@stokkie.net

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

[Robert M. Stockmann]

On Tue, 27 Apr 2004, Tim Hockin wrote:

> On Wed, Apr 28, 2004 at 02:18:59AM +0200, Robert M. Stockmann wrote:
> > > This is possible with any structure, named or unnamed.  It's called an
> > > ABI, and it's one of the reasons that binary modules suck.  It doesn't
> > > have *anything* to do with unnamed structures.  At all.  And if you think
> > > so, show me code.
> > 
> > here's a example :
> > 
> > http://www.promise.com/support/file/driver/1_fasttrak_tx4000_partial_source_1.00.0.19.zip
> 
> Care to show me where they use unnamed structures, and how it has anything
> to do with binary modules?

fasttrak.h :

/********************************************************************* 
  
   fasttrak.h -- PROMISE FastTrak Controllers device driver for Linux.

   Copyright (C) 2002-2005 PROMISE Technology, Inc.

   This program is free software; you can redistribute it and/or modify
   it under the terms of the GNU General Public License as published by
   the Free Software Foundation; version 2 of the License.

   Bugs/Comments/Suggestions should be mailed to:                            
   support@promise.com.tw

   For more information, goto:
   http://www.promise.com

*********************************************************************/

#ifndef _ft3xx_h
#define _ft3xx_h

#include <linux/version.h>

#if LINUX_VERSION_CODE >= KERNEL_VERSION(2,4,0)
#define ft3xx {							\
	next: NULL,						\
	proc_dir: NULL, 					\
	proc_info: NULL,    				        \
	name: "ft3xx",						\
	detect: ft3xx_detect,					\
	release: ft3xx_release,					\
	ioctl: ft3xx_ioctl,					\
	info: NULL,					        \
	command: NULL,						\
	queuecommand: ft3xx_queuecommand,			\
	eh_abort_handler : ft3xx_abort_eh,			\
	eh_device_reset_handler : ft3xx_reset_eh,		\
	abort: ft3xx_abort,					\
	reset: ft3xx_reset,					\
	slave_attach: NULL,					\
	bios_param: ft3xx_bios_param,				\
	can_queue: Can_Queue,	/* max simultaneous cmds      */\
	this_id: 7,		/* scsi id of host adapter    */\
	sg_tablesize: Max_SG_Table - 2,/* max scatter-gather cmds    */\
	cmd_per_lun: 1,		/* cmds per lun (linked cmds) */\
	present: 0,						\
	unchecked_isa_dma: 0,	/* no memory DMA restrictions */\
	use_clustering: 0,					\
        use_new_eh_code: 0, 	/* enable this field next time*/\
        emulated: 0, 						\
        proc_name: "ft3xx" 					\
} 
#else
#define ft3xx {							\
	next: NULL,						\
	proc_dir: NULL, 					\
	proc_info: NULL,    				        \
	name: "ft3xx",						\
	detect: ft3xx_detect,					\
	release: ft3xx_release,					\
	ioctl: ft3xx_ioctl,					\
	info: NULL,					        \
	command: NULL,						\
	queuecommand: ft3xx_queuecommand,			\
	eh_abort_handler : ft3xx_abort_eh,			\
	eh_device_reset_handler : ft3xx_reset_eh,		\
	abort: ft3xx_abort,					\
	reset: ft3xx_reset,					\
	slave_attach: NULL,					\
	bios_param: ft3xx_bios_param,				\
	can_queue: Can_Queue,	/* max simultaneous cmds      */\
	this_id: 7,		/* scsi id of host adapter    */\
	sg_tablesize: Max_SG_Table - 2,	/* max scatter-gather cmds    */\
	cmd_per_lun: 1,		/* cmds per lun (linked cmds) */\
	present: 0,						\
	unchecked_isa_dma: 0,	/* no memory DMA restrictions */\
	use_clustering: 0,					\
        use_new_eh_code: 0, 	/* enable this field next time*/\
        emulated: 0, 						\
} 
#endif


#endif /* _ft3xx_h */ 


This header file is needed to be able to link ft3xx.o . In which way binary 
incompatibility is introduced, inside this case is hard to tell. We
will never know i guess , since the type and size of the above components
is hidden inside the binary only part :

-rw-r--r--    1 stock    stock      227757 Oct 13  2003 ftlib.o

Well it works, with gcc-3.x, but not with gcc-2.95.3

> 
> > Opaque types should be no problem. However the complete definition must reside
> > somewhere _inside_ the complete source. Opaque types is even a bless, i agree.
> 
> If you're open, then yes.  If you're not open, you could have the
> definition of the opaque type inside your own closed code, and things will
> still work.  In fact, that's the sane way to do closed structures.
> 

Hardware which uses these things inside its linux drivers, is hardware
i would never run Linux on.

Robert
-- 
Robert M. Stockmann - RHCE
Network Engineer - UNIX/Linux Specialist
crashrecovery.org  stock@stokkie.net

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

[Robert M. Stockmann]

On Tue, 27 Apr 2004, Tim Hockin wrote:

> On Wed, Apr 28, 2004 at 01:59:08AM +0200, Robert M. Stockmann wrote:
> > > What the hell are you going on about?  Unnamed structures are a
> > > syntactical construct and have ZILCH to do with runtime.
> > 
> > I thought so too, until your semi open-source link kit is linked to that
> > brand-new linux kernel source tree, and at the same time the binary
> > components of your link-kit have become incompatible with that newer kernel. 
> 
> This is possible with any structure, named or unnamed.  It's called an
> ABI, and it's one of the reasons that binary modules suck.  It doesn't
> have *anything* to do with unnamed structures.  At all.  And if you think
> so, show me code.

here's a example :

http://www.promise.com/support/file/driver/1_fasttrak_tx4000_partial_source_1.00.0.19.zip

> 
> > > Opaque types have been available FOREVER.
> > 
> > sure, but can one qualify that as Open Source?
> 
> If used properly (and they are used in Linux, I believe) they can be very
> handy.  It's a non-sequiter.  no coding technique, no matter how
> incoherent, is incompatible with open source.

Opaque types should be no problem. However the complete definition must reside
somewhere _inside_ the complete source. Opaque types is even a bless, i agree.
It summarizes code to only reflect what is essential, instead of repeating
tedious and long struct types and defines. However if Opaque types are used
inside a partial_source tree, where the complete definition is hidden
inside the binary only closed source parts, then its the complete opposite
of what i would call a bless.

Robert
-- 
Robert M. Stockmann - RHCE
Network Engineer - UNIX/Linux Specialist
crashrecovery.org  stock@stokkie.net

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

[Robert M. Stockmann]

On Tue, 27 Apr 2004, Michael Poole wrote:

> "Robert M. Stockmann" <stock@stokkie.net> writes:
> 
> [snip]
> > To be more specific about what i am complaining about, here's a 
> > error message i get when doing ./configure inside ntfsprogs-1.8.4 :
> >
> > checking version of gcc... 2.95.3, bad
> > configure: error: Please upgrade your gcc compiler to gcc-2.96+ or gcc-3+ 
> > version! Earlier compiler versions will NOT work as these do not support 
> > unnamed/annonymous structures and unions which are used heavily in linux-ntfs.
> > [jackson:stock]:(~/src/ntfsprogs-1.8.4)$
> >
> > Aha, unnamed/annonymous structures and unions .....
> 
> Please keep rants about applications' coding style where they belong:
> off the linux-kernel list.  If you bothered to READ what Linus wrote,
> you would see that the structure being defined has a name -- in fact,
> gcc requires that, since the structure would be defined at file scope
> rather than inside another structure or union.
> 
> Michael

Hi Michael,

look i have made complaints about gcc-3.x some time ago, on the gcc
mailinglist. Also there they put my opinions aside, with arguments
like any powerfull feature can be used in a bad and in a good way. 
The powerfull feature here is the C99 coding style, which allows for 
unnamed and anonymous structures and unions. Don't kill our C99 cause it
can do bad things. Of course not.

However when dealing with OEM hardware vendors, which have signed contracts
with Microsoft about windows drivers, i think we cannot allow these same
OEM hardware vendors to introduce binary only drivers of unknown quality into
the linux kernel. Its exactly these events which give the Linux kernel, or
even Linux in general, give a bad reputation. Think about rants like this  :

"The Promise FastTrak TX4000 IDE-RAID controller works perfect inside Windows,
 but inside Linux i even lost my data."

The Promise Fasttrak issue i discussed here :

http://gcc.gnu.org/ml/gcc/2004-02/msg00293.html

If every major hardware vendor (like e.g. Adaptec, LSI Logic) will change
its policy, to implement its drivers as semi- binary only kernel modules, like
Promise did with its FastTrak line of controllers, like in the example above,
the Open Source lable of the linux kernel can be placed into the computer
museum. Isn't that exactly what a certain Redmond software company wants
to achieve?

Cheers,

Robert
-- 
Robert M. Stockmann - RHCE
Network Engineer - UNIX/Linux Specialist
crashrecovery.org  stock@stokkie.net

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

[Tim Hockin]

On Wed, Apr 28, 2004 at 12:59:23AM +0200, Robert M. Stockmann wrote:
> look i have made complaints about gcc-3.x some time ago, on the gcc
> mailinglist. Also there they put my opinions aside, with arguments
> like any powerfull feature can be used in a bad and in a good way. 
> The powerfull feature here is the C99 coding style, which allows for 
> unnamed and anonymous structures and unions. Don't kill our C99 cause it
> can do bad things. Of course not.

> If every major hardware vendor (like e.g. Adaptec, LSI Logic) will change
> its policy, to implement its drivers as semi- binary only kernel modules, like
> Promise did with its FastTrak line of controllers, like in the example above,
> the Open Source lable of the linux kernel can be placed into the computer
> museum. Isn't that exactly what a certain Redmond software company wants
> to achieve?

What the hell do these two paragraphs have to do with each other?

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

[Robert M. Stockmann]

On Tue, 27 Apr 2004, Tim Hockin wrote:

> On Wed, Apr 28, 2004 at 12:59:23AM +0200, Robert M. Stockmann wrote:
> > look i have made complaints about gcc-3.x some time ago, on the gcc
> > mailinglist. Also there they put my opinions aside, with arguments
> > like any powerfull feature can be used in a bad and in a good way. 
> > The powerfull feature here is the C99 coding style, which allows for 
> > unnamed and anonymous structures and unions. Don't kill our C99 cause it
> > can do bad things. Of course not.
> 
> > If every major hardware vendor (like e.g. Adaptec, LSI Logic) will change
> > its policy, to implement its drivers as semi- binary only kernel modules, like
> > Promise did with its FastTrak line of controllers, like in the example above,
> > the Open Source lable of the linux kernel can be placed into the computer
> > museum. Isn't that exactly what a certain Redmond software company wants
> > to achieve?
> 
> What the hell do these two paragraphs have to do with each other?
> 

C99 coding style, more specific the use of unnamed and anonymous structures
and unions, allows the kernel programmer to interface, read glue, binary only
driver modules to interface with any linux kernel source tree.

Using this feature one can link and merge any binary only module.o to any
kernel source version of your choice. In this way, typically, a OEM vendor,
releases a semi open-source link kit, which also contains binary only
components, once. This semi open source link-kit will then work with any 2.6.x
or 2.4.2x kernel source tree.

The needed header files, which need to be read by the gcc compiler, contain
unnamed and annonymizes structures and unions. In the worst case scenario,
only the name of used variables are given and no info about variable type or
size are inside these headers files. gcc-2.95.3 fails to succesfully link these
semi open-source link-kits, and gcc-3.x (which supports C99) of course has
no problems doing this.

Robert
-- 
Robert M. Stockmann - RHCE
Network Engineer - UNIX/Linux Specialist
crashrecovery.org  stock@stokkie.net

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

[Tim Hockin]

On Wed, Apr 28, 2004 at 01:30:58AM +0200, Robert M. Stockmann wrote:
> > What the hell do these two paragraphs have to do with each other?
> 
> C99 coding style, more specific the use of unnamed and anonymous structures
> and unions, allows the kernel programmer to interface, read glue, binary only
> driver modules to interface with any linux kernel source tree.

What the hell are you going on about?  Unnamed structures are a
syntactical construct and have ZILCH to do with runtime.

> The needed header files, which need to be read by the gcc compiler, contain
> unnamed and annonymizes structures and unions. In the worst case scenario,
> only the name of used variables are given and no info about variable type or
> size are inside these headers files. gcc-2.95.3 fails to succesfully link these

Opaque types have been available FOREVER.

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

[Robert M. Stockmann]

On Tue, 27 Apr 2004, Tim Hockin wrote:

> On Wed, Apr 28, 2004 at 01:30:58AM +0200, Robert M. Stockmann wrote:
> > > What the hell do these two paragraphs have to do with each other?
> > 
> > C99 coding style, more specific the use of unnamed and anonymous structures
> > and unions, allows the kernel programmer to interface, read glue, binary only
> > driver modules to interface with any linux kernel source tree.
> 
> What the hell are you going on about?  Unnamed structures are a
> syntactical construct and have ZILCH to do with runtime.

I thought so too, until your semi open-source link kit is linked to that
brand-new linux kernel source tree, and at the same time the binary
components of your link-kit have become incompatible with that newer kernel. 

Result? one might even loose its data, upon booting that newly build
kernel and modules, in case your storage-controller has a binary only
link-kit as its driver.

> > The needed header files, which need to be read by the gcc compiler, contain
> > unnamed and annonymizes structures and unions. In the worst case scenario,
> > only the name of used variables are given and no info about variable type or
> > size are inside these headers files. gcc-2.95.3 fails to succesfully link these
> 
> Opaque types have been available FOREVER.

sure, but can one qualify that as Open Source?

Robert
-- 
Robert M. Stockmann - RHCE
Network Engineer - UNIX/Linux Specialist
crashrecovery.org  stock@stokkie.net

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

[Tomas Szepe]

On Apr-28 2004, Wed, 01:59 +0200
Robert M. Stockmann <stock@stokkie.net> wrote:

> > > The needed header files, which need to be read by the gcc compiler, contain
> > > unnamed and annonymizes structures and unions. In the worst case scenario,
> > > only the name of used variables are given and no info about variable type or
> > > size are inside these headers files. gcc-2.95.3 fails to succesfully link these
> > 
> > Opaque types have been available FOREVER.
> 
> sure, but can one qualify that as Open Source?

Are you familiar with my friend "void *"?

-- 
Tomas Szepe <szepe@pinerecords.com>

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

[Nick Warne]

Sad state of affairs.

I don't know anything on the guru's side of coding and stuff in the 
kernel, but I do know enough to say the module in question WAS coded 
to give a false impression (or true, if you like) to the kernel so 
that it supressed the 'tainted' kernel warnings.

But surely in an open source project [any project], tainted code 
needs to be highlighted?  What else is in there, or not?  A GNU/Linux 
platform needs to be told when a unknown and unvetted binary loads  - 
who can prove what it does otherwise, and therefore the onus is on 
the user?

Maybe binary suppliers need to speak to kernel crew first on what 
they need to do to get around these issues legally before it is 
'discovered' and appears to be an attempt get around safeguards in 
place.

Nick

-- 
"When you're chewing on life's gristle,
Don't grumble, Give a whistle..."

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

[Robert M. Stockmann]

On Mon, 26 Apr 2004, Linus Torvalds wrote:

> On Tue, 27 Apr 2004, Carl-Daniel Hailfinger wrote:
> > 
> > LinuxAnt offers binary only modules without any sources. To circumvent our
> > MODULE_LICENSE checks LinuxAnt has inserted a "\0" into their declaration:
> > 
> > MODULE_LICENSE("GPL\0for files in the \"GPL\" directory; for others, only
> > LICENSE file applies");
> 
> Hey, that is interesting in itself, since playing the above kinds of games
> makes it pretty clear to everybody that any infringement was done
> wilfully. They should be talking to their lawyers about things like that.
> 
> Anyway, I suspect that rather than blacklist bad people, I'd much prefer
> to have the module tags be done as counted strings instead. It should be
> easy enough to do by just having the macro prepend a "sizeof(xxxx)" 
> thing or something.
> 
> Hmm. At least with -sdt=c99 it should be trivial, with something like
> 
> #define __MODULE_INFO(tag, name, info) \
> static struct { int len; const char value[] } \
> __module_cat(name,__LINE__) __attribute_used__ \
> __attribute__((section(".modinfo"),unused)) = \
> { sizeof(__stringify(tag) "=" info), \
> __stringify(tag) "=" info }
> 
> doing the job.
> 
> That should make it pretty easy to parse the .modinfo section too.
> 
> Linus

Its a joke anyway gcc3.x allows this to happen. As i posted on the
gcc mailinglist some time ago :

"Re: C Code mutilation by using gcc-3.3.x"
http://gcc.gnu.org/ml/gcc/2004-02/msg00313.html :
-------------------------------------------------
"
> 
> On Feb 4, 2004, at 12:01, Robert M. Stockmann wrote:
> > Whats going on here?
> 
> gcc 3.x supports C99 style of initializing of structors which was not 
> supported in 2.95.3.

To be more specific about what i am complaining about, here's a 
error message i get when doing ./configure inside ntfsprogs-1.8.4 :

checking version of gcc... 2.95.3, bad
configure: error: Please upgrade your gcc compiler to gcc-2.96+ or gcc-3+ 
version! Earlier compiler versions will NOT work as these do not support 
unnamed/annonymous structures and unions which are used heavily in linux-ntfs.
[jackson:stock]:(~/src/ntfsprogs-1.8.4)$

Aha, unnamed/annonymous structures and unions .....

Well thats briljant... in 2 years time all Open Source code will be unnamed
and anonymous in the form of propiatary .o modules, and Linus will still
be happy to deliver his /usr/src/linux/kernel subtree of the Linux
kernel source. Quite funny to see Open Source evolving by implementing
"modern" C compilers like gcc-3.x.

BTW. inside the Linux kernel source the Changes file explicitly states :

"The recommended compiler for the kernel is gcc 2.95.x (x >= 3), and it
should be used when you need absolute stability. You may use gcc 3.0.x
instead if you wish, although it may cause problems. Later versions of gcc
have not received much testing for Linux kernel compilation, and there are
almost certainly bugs (mainly, but not exclusively, in the kernel) that
will need to be fixed in order to use these compilers. In any case, using
pgcc instead of egcs or plain gcc is just asking for trouble."
-------------------------------------------------------------------------

It surely looks like the unnamed and annonymous powers of gcc-3.x finally
have reached the linux-kernel list. If you allow trash into your
gcc compilers, the resulting code and binary's are in the same
way affected. 

regards,

Robert
-- 
Robert M. Stockmann - RHCE
Network Engineer - UNIX/Linux Specialist
crashrecovery.org  stock@stokkie.net

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

[Tomas Szepe]

On Apr-27 2004, Tue, 23:34 +0200
Robert M. Stockmann <stock@stokkie.net> wrote:

> > Hmm. At least with -sdt=c99 it should be trivial, with something like
> > 
> > #define __MODULE_INFO(tag, name, info) \
> > static struct { int len; const char value[] } \
> > __module_cat(name,__LINE__) __attribute_used__ \
> > __attribute__((section(".modinfo"),unused)) = \
> > { sizeof(__stringify(tag) "=" info), \
> > __stringify(tag) "=" info }
> > 
> > doing the job.
> > 
> > That should make it pretty easy to parse the .modinfo section too.
> > 
> > Linus
> 
> Its a joke anyway gcc3.x allows this to happen.

Why?  Initializing a char pointer to a byte stream that contains a NUL
is perfectly legal C.

> As i posted on the gcc mailinglist some time ago :
[snip]
> checking version of gcc... 2.95.3, bad
> configure: error: Please upgrade your gcc compiler to gcc-2.96+ or gcc-3+ 
> version! Earlier compiler versions will NOT work as these do not support 
> unnamed/annonymous structures and unions which are used heavily in linux-ntfs.
> [jackson:stock]:(~/src/ntfsprogs-1.8.4)$
> 
> Aha, unnamed/annonymous structures and unions .....
> 
> Well thats briljant... in 2 years time all Open Source code will be unnamed
> and anonymous in the form of propiatary .o modules, and Linus will still
> be happy to deliver his /usr/src/linux/kernel subtree of the Linux
[snip]

Well, what was the GCC folks' response?  I'd place my bet on
"Do you even know what an unnamed structure/union is?"

-- 
Tomas Szepe <szepe@pinerecords.com>

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

[Steve Lee]

Instead of printing module taint messages to the screen, why couldn't
they just
be written to syslog?  Then it wouldn't matter if there were several
taint
messages.  For example, I know my nVidia driver taints the kernel, I
don't need
to see that message over and over again.

Marc Boucher <marc () linuxant ! com> wrote:

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

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

[Tigran Aivazian]

On Tue, 27 Apr 2004, Steve Lee wrote:

> Instead of printing module taint messages to the screen, why couldn't
> they just
> be written to syslog?  Then it wouldn't matter if there were several
> taint
> messages.  For example, I know my nVidia driver taints the kernel, I
> don't need
> to see that message over and over again.

Yes, that is exactly what it was a few years ago when I checked (and
probably still is) --- a bug in modutils which needs to be fixed as those
messages are too annoying and aggressive. It should be changed to be made
possible to disable them via /etc/syslog.conf because a normal user
wouldn't have a clue how to disable them otherwise.

Those kind of "kernel messages" should not be seen except when a user
wants to prepare a bug report and send it to linux-kernel. Then he ought
to check dmesg and discover that he is in fact running binary only modules
and also he will discover the support email address and send his report
there instead of here.

Generally, breaking Unix philosophy with such aggressive messages
bypassing standard interfaces is what normally happens in commercial
Unix-es, which are driven by "market requirements" i.e. dictated by people
who have no clue what proper Unix is or should be. So, this part of
modutils is, ironically, very much anti-Linux and "commercial Unix"-like,
although it tries to look precisely opposite. It should be fixed, imho.

I even think that the whole "EXPORT_SYMBOL" vs "EXPORT_SYMBOL_GPL" thing
is moot and anti-freedom because it violates ability of hackers (even if
they happen to work for companies producing binary-only modules, that's
irrelevant) to make proper technical design decisions and instead obey
some person's idea of what is a "good" or "bad" caller of his API. But so
be it, since that's the way Linus and others prefers Linux to be.

Kind regards
Tigran

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

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

[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

[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