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

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