Tainted Modules Help Notices

Tainted Modules Help Notices

[Morgan Collins [Ax0n]]

    After compiling 2.4.11 I noticed modprobe picking up some of the tainted modules that
 were marked in the update.

    What surprised me was the PPP compression modules, I didn't use PPP in 2.4.10 so maybe
the notice was there in 2.4.10, but I didn't use them so I didn't see it. I shouldn't have
been surprised, but I was. BSD compression, BSD license... doh... :>

    I do however at times use the nls modules, and I see a great deal of them are BSD-NAC
licensed. It's also nice to have ipchains_core laying around for compatibility at times as
well. If I had known this at compile time I would have opted not to compile them, as
modules or otherwise. Knowing now that there are modules in the kernel build tree that are
not GPLed, and since I don't know which ones, I will grep for MODULE_LICENSE first from
now on.

    After this discovery, I would like to ask opinions on including licensing terms in
item/module help files. It would be very convient if under dpt_i2o help it said that it
was licensed under BSD-NAC.

-- 
Morgan Collins [Ax0n] http://sirmorcant.morcant.org
Software is something like a machine, and something like mathematics, and something like
language, and something like thought, and art, and information.... but software is not in
fact any of those other things.

Re: Tainted Modules Help Notices

[David Woodhouse]

sirmorcant@morcant.org said:
>     After compiling 2.4.11 I noticed modprobe picking up some of the
> tainted modules that were marked in the update.

>     What surprised me was the PPP compression modules, I didn't use
> PPP in 2.4.10 so maybe the notice was there in 2.4.10, but I didn't
> use them so I didn't see it. I shouldn't have been surprised, but I
> was. BSD compression, BSD license... doh... :> 

BSD-licensed modules shouldn't mark the kernel as tainted. If they do, 
that's surely a bug.

Any code which is distributed as part of the kernel source tree has a 
sane, if not 100% compatible, licence and shouldn't taint your kernel.

--
dwmw2

Re: Tainted Modules Help Notices

[Morgan Collins [Ax0n]]

> 
> 
>sirmorcant@morcant.org said:
>>     After compiling 2.4.11 I noticed modprobe picking up some of the
>> tainted modules that were marked in the update.
> 
>>     What surprised me was the PPP compression modules, I didn't use
>> PPP in 2.4.10 so maybe the notice was there in 2.4.10, but I didn't use them so I
>> didn't see it. I shouldn't have been surprised, but I was. BSD compression, BSD
>> license... doh... :> 
> 
> BSD-licensed modules shouldn't mark the kernel as tainted. If they do,  that's surely
> a bug.
> 
> Any code which is distributed as part of the kernel source tree has a  sane, if not
> 100% compatible, licence and shouldn't taint your kernel.
> 
> --
> dwmw2

fs/nls/nls_cp737.c:MODULE_LICENSE("BSD without advertising clause");

Warning: loading /lib/modules/2.4.11/kernel/fs/nls/nls_cp737.o will taint the kernel:
non-GPL license - BSD without advertising clause

# cat /proc/sys/kernel/tainted 
1



-- 
Morgan Collins [Ax0n] http://sirmorcant.morcant.org
Software is something like a machine, and something like mathematics, and something like
language, and something like thought, and art, and information.... but software is not in
fact any of those other things.

Re: Tainted Modules Help Notices

[David Woodhouse]

sirmorcant@morcant.org said:
> fs/nls/nls_cp737.c:MODULE_LICENSE("BSD without advertising clause");

> Warning: loading /lib/modules/2.4.11/kernel/fs/nls/nls_cp737.o will taint the kernel: 
> non-GPL license - BSD without advertising clause

> # cat /proc/sys/kernel/tainted  1 

Yes, that's a bug. Either that text needs to be added to the list of 
acceptable licences, or changed to "Dual BSD/GPL".

The warning should probably read 'Incompatible licence' instead of 'non-GPL',
too.

--
dwmw2

Re: Tainted Modules Help Notices

[Keith Owens]

On Wed, 10 Oct 2001 09:20:58 +0100, 
David Woodhouse <dwmw2@infradead.org> wrote:
>BSD-licensed modules shouldn't mark the kernel as tainted. If they do, 
>that's surely a bug.

Any license not listed in include/linux/module.h is not GPL compatible.
That list is currently (2.4.11)

"GPL"                           [GNU Public License v2 or later]
"GPL and additional rights"     [GNU Public License v2 rights and more]
"Dual BSD/GPL"                  [GNU Public License v2 or BSD license choice]
"Dual MPL/GPL"                  [GNU Public License v2 or Mozilla license choice]

>The warning should probably read 'Incompatible licence' instead of 'non-GPL',
>too.

No.  Any license text not approved as GPL compatible is, by definition,
incompatible.

Re: Tainted Modules Help Notices

[Alexander Viro]

On Wed, 10 Oct 2001, Keith Owens wrote:

> On Wed, 10 Oct 2001 09:20:58 +0100, 
> David Woodhouse <dwmw2@infradead.org> wrote:
> >BSD-licensed modules shouldn't mark the kernel as tainted. If they do, 
> >that's surely a bug.
> 
> Any license not listed in include/linux/module.h is not GPL compatible.
> That list is currently (2.4.11)
> 
> "GPL"                           [GNU Public License v2 or later]
> "GPL and additional rights"     [GNU Public License v2 rights and more]
> "Dual BSD/GPL"                  [GNU Public License v2 or BSD license choice]
> "Dual MPL/GPL"                  [GNU Public License v2 or Mozilla license choice]

What the hell?  BSD without advertisement clause had always been
GPL-compatible.

Re: Tainted Modules Help Notices

[Keith Owens]

On Wed, 10 Oct 2001 09:59:01 -0400 (EDT), 
Alexander Viro <viro@math.psu.edu> wrote:
>On Wed, 10 Oct 2001, Keith Owens wrote:
>> Any license not listed in include/linux/module.h is not GPL compatible.
>> That list is currently (2.4.11)
>> 
>> "GPL"                           [GNU Public License v2 or later]
>> "GPL and additional rights"     [GNU Public License v2 rights and more]
>> "Dual BSD/GPL"                  [GNU Public License v2 or BSD license choice]
>> "Dual MPL/GPL"                  [GNU Public License v2 or Mozilla license choice]
>
>What the hell?  BSD without advertisement clause had always been
>GPL-compatible.

Take it up with AC, modutils is just following his list in module.h.

Re: Tainted Modules Help Notices

[Alan Cox]

> What the hell?  BSD without advertisement clause had always been
> GPL-compatible.

Subject to patent holdings. If you hold a patent on the BSD code you can't
GPL it nor is it GPL compatible. 

The problem we have is that "BSD without advertisment" can be claimed by
almost any binary only module whose author doesnt include source or let
it out fo their company ever

Re: Tainted Modules Help Notices

[David Woodhouse]

alan@lxorguk.ukuu.org.uk said:
>  Subject to patent holdings. If you hold a patent on the BSD code you
> can't GPL it

That's not wonderfully clear. They don't have to _restrict_ your rights -
just neglect to grant you the right to use the algorithm in question, which
you didn't have in the first place anyway.

> nor is it GPL compatible. 

I believe that statement is as true as the assertion that nobody, even in
the Free World, can write GPL'd code which use the algorithms covered by 
the patent.

Either way, I didn't think that a political stance against patents was the 
point of the kernel tainting code - I thought it was about maintainability.

>  The problem we have is that "BSD without advertisment" can be claimed
> by almost any binary only module whose author doesnt include source or
> let it out fo their company ever 

GPL can also be claimed by a module whose author doesn't publish either the
source or the binary, or who charges lots and lots of money for shipping the
binary and ships the source with it with a 'request' that the recipient
doesn't then give it away for free.

But if we're not going to allow BSD-licensed modules to be loaded without 
tainting the kernel, we shouldn't mark any of the code distributed with the 
kernel as BSD-licensed - we should make it all "Dual BSD/GPL" instead.

It might also be useful to have a 'Dual GPL/Other' option, for covering the 
other randomly dual-licensed code (like JFFS2). 

--
dwmw2

Re: Tainted Modules Help Notices

[Concerned Programmer]

    I was under the same impression about the module licensing tagging.  I
had read that it was suppose to be for maintainability (.i.e. source
available so kernel gods can debug) and not to enforce ideological
conformity.  Now I read that anything not licensed under the GPL, including
BSD or simply public domain source code, will taint my kernel and modprobe
complains about non-GPL stuff including parport_pc which apparently did not
have a license.  Should I expect a Linux kernel KGB to show up next?

    Furthermore I have to agree with the previous poster.  Any module could
easily lie to MODULE_LICENSE about its licensing terms and that would not
make it's source automatically "free" and GPLable so I am now wondering if
this tainting mechanism is of any use at all.

    Just out of curiosity do all of these license tags in the modules take
up any permanent kernel memory, especially in a heavily modularize system?

> I believe that statement is as true as the assertion that nobody, even in
> the Free World, can write GPL'd code which use the algorithms covered by
> the patent.
>
> Either way, I didn't think that a political stance against patents was the
> point of the kernel tainting code - I thought it was about
maintainability.
>
> >  The problem we have is that "BSD without advertisment" can be claimed
> > by almost any binary only module whose author doesnt include source or
> > let it out fo their company ever
>
> GPL can also be claimed by a module whose author doesn't publish either
the
> source or the binary, or who charges lots and lots of money for shipping
the
> binary and ships the source with it with a 'request' that the recipient
> doesn't then give it away for free.
>
> But if we're not going to allow BSD-licensed modules to be loaded without
> tainting the kernel, we shouldn't mark any of the code distributed with
the
> kernel as BSD-licensed - we should make it all "Dual BSD/GPL" instead.
>
> It might also be useful to have a 'Dual GPL/Other' option, for covering
the
> other randomly dual-licensed code (like JFFS2).

Re: Tainted Modules Help Notices

[Morgan Collins [Ax0n]]

>     I was under the same impression about the module licensing tagging.  I
> had read that it was suppose to be for maintainability (.i.e. source available so
> kernel gods can debug) and not to enforce ideological conformity.  Now I read that
> anything not licensed under the GPL, including BSD or simply public domain source
> code, will taint my kernel and modprobe complains about non-GPL stuff including
> parport_pc which apparently did not have a license.  Should I expect a Linux kernel
> KGB to show up next?
> 
I think what has happened here is a little bit of a misunderstanding.

I think that the modprobe source and the kernel source just aren't in sync with the
development of the new (re DEVELOPMENTAL) MOD_LICENSE() implementation.

Weither or not the BSD-NAC is GPL compatible has already been determined, as it's in the
kernel and the lead developers have said so. I trust them, they'll get sued if they don't
look at things like that. Modprobe told me a BSD module was tainted, I assumed that ment
it was incompatible with the kernel which is GPLed. I shouldn't trust everything I read :>

The problem lies in modprobe not having it in it's list of licenses to not mark as tainted.

When I modprobe ppp_deflate, it does not fail to load, it simply warned me that my kernel
would be tainted. What does having a tainted kernel mean? It is to tell kernel 
debuggers if this is a clean kernel or if anything unusual has occurred.

>     Furthermore I have to agree with the previous poster.  Any module could
> easily lie to MODULE_LICENSE about its licensing terms and that would not make it's
> source automatically "free" and GPLable so I am now wondering if this tainting
> mechanism is of any use at all.
> 
If the purpose was to discriminate against licensing, I would agree. But since
non-compatible source is not distributed with the kernel, and the mechanism is for
debugging, what is the purpose of lying to the kernel? To confuse debuggers? No point in that.

>     Just out of curiosity do all of these license tags in the modules take
> up any permanent kernel memory, especially in a heavily modularize system?
> 
A grep of /proc/kcore only showed the MODULE_LICESE in this email, and the scrollback
buffer in my xterm, so I don't think so.

-- 
Morgan Collins [Ax0n] http://sirmorcant.morcant.org
Software is something like a machine, and something like mathematics, and something like
language, and something like thought, and art, and information.... but software is not in
fact any of those other things.

Re: Tainted Modules Help Notices

[Keith Owens]

On Wed, 10 Oct 2001 13:28:21 -0700 (PDT), 
"Morgan Collins [Ax0n]" <sirmorcant@morcant.org> wrote:
>I think that the modprobe source and the kernel source just aren't in sync with the
>development of the new (re DEVELOPMENTAL) MOD_LICENSE() implementation.

What makes you say that?  The list of GPL compatible license strings is
in include/linux/module.h, modutils uses *exactly* the same set of
strings.  If somebody uses a different string, their license is not
GPL.

>If the purpose was to discriminate against licensing, I would agree. But since
>non-compatible source is not distributed with the kernel, and the mechanism is for
>debugging, what is the purpose of lying to the kernel? To confuse debuggers? No point in that.

To triage bug reports.  Any bug report against a tainted kernel is
almost certain to be bounced with "your kernel contains code that we do
not have the source for, send this bug report to the company that
maintains the non-GPL code".

>>     Just out of curiosity do all of these license tags in the modules take
>> up any permanent kernel memory, especially in a heavily modularize system?
>> 

No, they are in the modinfo section along with module parms, author,
description, kernel vesrion etc.  None of that gets loaded into memory.

Re: Tainted Modules Help Notices

[Anthony DeRobertis]

> To triage bug reports.  Any bug report against a tainted kernel is
> almost certain to be bounced with "your kernel contains code that
> we do not have the source for, send this bug report to the company
> that
> maintains the non-GPL code".

Couldn't this mess be solved with a module (optionally) containing a URL
to a source-code tarball? Modules that come with the kernel would point
to the relevant kernel sources on ftp.kernel.org.

This would alleviate all worry about things like closed-source BSD;
after all, anyone could check if there is source availible with wget.

Re: Tainted Modules Help Notices

[David Woodhouse]

kaos@ocs.com.au said:
>  If somebody uses a different string, their license is not GPL. 

We do not care if they use a licence which is not GPL. We only care if they 
use a licence which is not GPL-compatible.

>  To triage bug reports.  Any bug report against a tainted kernel is
> almost certain to be bounced with "your kernel contains code that we
> do not have the source for, send this bug report to the company that
> maintains the non-GPL code".

In the case which started this thread, the non-GPL code in question was part
of the kernel source tree, and we _do_ have the source for it. It was the
BSD-licensed PPP compression code. 

You seem to have claimed that this is not a bug, but that it's intentional.
Are you therefore going to make changes to the build system so that the
static kernel image will boot up marked as tainted if CONFIG_PPP_BSDCOMP=y?

--
dwmw2

Re: Tainted Modules Help Notices

[Alan Cox]

> had read that it was suppose to be for maintainability (.i.e. source
> available so kernel gods can debug) and not to enforce ideological
> conformity.  Now I read that anything not licensed under the GPL, including
> BSD or simply public domain source code, will taint my kernel and modprobe
> complains about non-GPL stuff including parport_pc which apparently did not
> have a license.  Should I expect a Linux kernel KGB to show up next?

Hardly. Its there to handle maintainability issues. Right now its got some 
glitches - and the BSD one is a glitch we need to sort out. Clearly BSD
stuff where the source is in the kernel is not harming anyones ability to
deubg.

>     Furthermore I have to agree with the previous poster.  Any module could
> easily lie to MODULE_LICENSE about its licensing terms and that would not
> make it's source automatically "free" and GPLable so I am now wondering if
> this tainting mechanism is of any use at all.

Well under the DMCA thats probably a criminal offence with five years in
jail. The truth however is that if you want to lie about licensing or run a
modutils that doesn't do it nobody stops you. Its there primarily to deal
with bug filtering from people who don't know better. Folks who know enough
to subvert the mechanism generally also know better than to post Nvdriver
bugs to l/k.

Re: Tainted Modules Help Notices

[Juan Quintela]

>>>>> "alan" == Alan Cox <alan@lxorguk.ukuu.org.uk> writes:

hi

alan> Well under the DMCA thats probably a criminal offence with five years in
alan> jail. The truth however is that if you want to lie about licensing or run a
alan> modutils that doesn't do it nobody stops you. Its there primarily to deal
alan> with bug filtering from people who don't know better. Folks who know enough
alan> to subvert the mechanism generally also know better than to post Nvdriver
alan> bugs to l/k.

Never understimate the ability of users to subert that kind of
barriers.

Later, Juan.

-- 
In theory, practice and theory are the same, but in practice they 
are different -- Larry McVoy

Re: Tainted Modules Help Notices

[Andreas Dilger]

On Oct 11, 2001  01:02 +0200, Juan Quintela wrote:
> >>>>> "alan" == Alan Cox <alan@lxorguk.ukuu.org.uk> writes:
> alan> Well under the DMCA thats probably a criminal offence with five years in
> alan> jail. The truth however is that if you want to lie about licensing or
> alan> run a modutils that doesn't do it nobody stops you. Its there primarily
> alan> to deal with bug filtering from people who don't know better. Folks who
> alan> know enough to subvert the mechanism generally also know better than to
> alan> post Nvdriver bugs to l/k.
> 
> Never understimate the ability of users to subert that kind of
> barriers.

Given that "subversion" will only mean editing the text output of ksymoops
to not display the "tainted" flag, I don't see it to be a big barrier to
entry.  If it is in the FAQ (or documented elsewhere) that "if ksymoops
says 'tainted: 1' submit your bug reports only to the vendor" it will be
a small matter to delete that line, and if this is NOT documented anywhere
it will not reduce the number of bug submissions, which was the original
goal.

I don't think we need to be mucking with "GPL vs. BSD" or anything, but
rather "source available or not" as the criterion for a tainted module.
Heaven forbid that using some driver currently in the kernel sources
marks your kernel as tainted, it would make the whole thing useless.

Cheers, Andreas
--
Andreas Dilger  \ "If a man ate a pound of pasta and a pound of antipasto,
                 \  would they cancel out, leaving him still hungry?"
http://www-mddsp.enel.ucalgary.ca/People/adilger/               -- Dogbert

Re: Tainted Modules Help Notices

[Rob Landley]

On Wednesday 10 October 2001 19:28, Andreas Dilger wrote:

> Given that "subversion" will only mean editing the text output of ksymoops
> to not display the "tainted" flag, I don't see it to be a big barrier to
> entry.  If it is in the FAQ (or documented elsewhere) that "if ksymoops
> says 'tainted: 1' submit your bug reports only to the vendor" it will be
> a small matter to delete that line, and if this is NOT documented anywhere
> it will not reduce the number of bug submissions, which was the original
> goal.

If it gets them to read the FAQ, it's done it's job already!

What the flag REALLY means is "I didn't read the FAQ."  In order to know to 
change it, they have to know why it's there...

And it's not to reduce submissions, it's to let Kernel hackers discard them 
more quickly.  (No force on earth can stop clueless requests for tech 
support.  It's like trying to stop spam.  All you can do is filter it more 
effectively.)


Rob

2.4.11 UDF

[Morgan Collins [Ax0n]]

Hi,

I recieve the following when mounting The Matrix:

Oct 10 19:40:40 ember kernel: UDF-fs INFO UDF 0.9.4.1-ro (2001/06/13) Mounting volume
'THE_MATRIX_16X9LB_N_AMERICA', timestamp 1999/08/02 17:29 (1e5c)

However, upon ls, I get an empty directory and the following errors dumped to syslog:

Oct 10 19:40:41 ember kernel: UDF-fs DEBUG directory.c:237:udf_get_fileident: 0x0 !=
TID_FILE_IDENT_DESC
Oct 10 19:40:41 ember kernel: UDF-fs DEBUG directory.c:239:udf_get_fileident: offset: 532
sizeof: 38 bufsize: 2048

I can however mount the 5th Element and I see the following, and recieve no errors and a
correct ls.
Oct 10 19:44:11 ember kernel: UDF-fs INFO UDF 0.9.4.1-ro (2001/06/13) Mounting volume
'DVD_VIDEO', timestamp 1997/10/28 11:44 (1e5c)

I didn't use UDF in 2.4.10, so perhaps this has already been discussed, if so clue me in :>

-- 
Morgan Collins [Ax0n] http://sirmorcant.morcant.org
Software is something like a machine, and something like mathematics, and something like
language, and something like thought, and art, and information.... but software is not in
fact any of those other things.

Re: 2.4.11 UDF

[Craig Whitmore]

MAtrix is Encrypted and 5th Element is not Encrypted.. That seems to be the
only difference between them..

Thanks
Craig Whitmore

----- Original Message -----
From: "Morgan Collins [Ax0n]" <sirmorcant@morcant.org>
To: <linux-kernel@vger.kernel.org>
Sent: Thursday, October 11, 2001 3:48 PM
Subject: 2.4.11 UDF


> Hi,
>
> I recieve the following when mounting The Matrix:
>
> Oct 10 19:40:40 ember kernel: UDF-fs INFO UDF 0.9.4.1-ro (2001/06/13)
Mounting volume
> 'THE_MATRIX_16X9LB_N_AMERICA', timestamp 1999/08/02 17:29 (1e5c)
>
> However, upon ls, I get an empty directory and the following errors dumped
to syslog:
>
> Oct 10 19:40:41 ember kernel: UDF-fs DEBUG
directory.c:237:udf_get_fileident: 0x0 !=
> TID_FILE_IDENT_DESC
> Oct 10 19:40:41 ember kernel: UDF-fs DEBUG
directory.c:239:udf_get_fileident: offset: 532
> sizeof: 38 bufsize: 2048
>
> I can however mount the 5th Element and I see the following, and recieve
no errors and a
> correct ls.
> Oct 10 19:44:11 ember kernel: UDF-fs INFO UDF 0.9.4.1-ro (2001/06/13)
Mounting volume
> 'DVD_VIDEO', timestamp 1997/10/28 11:44 (1e5c)
>
> I didn't use UDF in 2.4.10, so perhaps this has already been discussed, if
so clue me in :>
>
> --
> Morgan Collins [Ax0n] http://sirmorcant.morcant.org
> Software is something like a machine, and something like mathematics, and
something like
> language, and something like thought, and art, and information.... but
software is not in
> fact any of those other things.
>
> -
> 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: Tainted Modules Help Notices

[Andreas Ferber]

On Wed, Oct 10, 2001 at 10:17:22PM +0100, Alan Cox wrote:
> 
> Hardly. Its there to handle maintainability issues. Right now its got some 
> glitches - and the BSD one is a glitch we need to sort out. Clearly BSD
> stuff where the source is in the kernel is not harming anyones ability to
> deubg.

What about simply adding "BSD (included in kernel)" as a possible
"untainted" MODULE_LICENSE()?

Andreas
-- 
       Andreas Ferber - dev/consulting GmbH - Bielefeld, FRG
     ---------------------------------------------------------
         +49 521 1365800 - af@devcon.net - www.devcon.net

Re: Tainted Modules Help Notices

[Alan Cox]

> What about simply adding "BSD (included in kernel)" as a possible
> "untainted" MODULE_LICENSE()?

Sounds sane to me

Re: Tainted Modules Help Notices

[Henning P. Schmiedehausen]

Alan Cox <alan@lxorguk.ukuu.org.uk> writes:

>> What about simply adding "BSD (included in kernel)" as a possible
>> "untainted" MODULE_LICENSE()?

>Sounds sane to me

How about 

"BSD (included in kernel source)" 

to make clear that this is part of the distributed kernel _sources_.

"included in kernel" could also be a 3rd party binary only driver
added by a Linux distribution vendor.

	Regards
		Henning

-- 
Dipl.-Inf. (Univ.) Henning P. Schmiedehausen       -- Geschaeftsfuehrer
INTERMETA - Gesellschaft fuer Mehrwertdienste mbH     hps@intermeta.de

Am Schwabachgrund 22  Fon.: 09131 / 50654-0   info@intermeta.de
D-91054 Buckenhof     Fax.: 09131 / 50654-20   

Re: Tainted Modules Help Notices

[Pekka Pietikäinen]

On Thu, Oct 11, 2001 at 09:35:34AM +0000, Henning P. Schmiedehausen wrote:
> How about 
> 
> "BSD (included in kernel source)" 
> 
> to make clear that this is part of the distributed kernel _sources_.
> 
> "included in kernel" could also be a 3rd party binary only driver
> added by a Linux distribution vendor.
Or even something like "BSD (unmodified source freely available)", which 
would cover 3rd party drivers as well.

-- 
Pekka Pietikainen

Re: Tainted Modules Help Notices

[Syed Mohammad Talha]

Dear all,

I have just subscribed this mailing list and sent mail to
linux-vger.kernel.org but this seems that I am missing something, because I
cant see my mail on the list and also have no idea whether this is the right
place to discuss or not, if not please excuse me, if yes than please help. I
have an IBM e-server and have installed redhat 7.1 with kernel 2.4.2, now
when I am trying to upgrade the kernel I am unable to do so. This has the
SCSI HDD and controller aic7xxx. I am upgrading the new kernel 2.4.10 now
when I start compiling the kernel every things goes ok but when I makes the
initrd image it gives different errors, like

modules for aic7xxx not found or
all loopback devices busy

I am selecting all the options in the kernel compilation as per my knowledge
and adopting the ways defined to compile, I have compiled the same kernel on
an IDE drive and is working fine and did not gave any error, but on scsci I
am very badly stuck, I can make the initrd image from the old modules
directory and define in the lilo.conf with the new kernel it works. Once I
was successful in making the initrd image through the new kernel module
directory but this was of no use, because when I rebooted the machine there
was a kernel panic


So guruz please if u can help me in resolving this problem, I am not sure
that whether I am selecting the wrong choices in the kernel compilation or
there is something else. Also when I compared the old module directory which
was of the default installed kernel and which I compile are quite different.


Looking for help

Talha

Re: Tainted Modules Help Notices

[Concerned Programmer]

    If this is about maintainability, why not just a simple flag stating if
source is available or not.

PS.

    Would be even nicer if it defaulted to "true" so my (and others') old
module source code did not now have to be changed just to avoid the annoying
warning from modprobe, though I assume thats out of the question.

> > "included in kernel" could also be a 3rd party binary only driver
> > added by a Linux distribution vendor.
> Or even something like "BSD (unmodified source freely available)", which
> would cover 3rd party drivers as well.

Re: Tainted Modules Help Notices

[Alan Cox]

>     If this is about maintainability, why not just a simple flag stating if
> source is available or not.

Available under what terms, NDA'd, subject to unacceptable other rules etc..

Its not as simple as it looks

Re: Tainted Modules Help Notices

[David Schwartz]

On Thu, 11 Oct 2001 11:37:27 +0100 (BST), Alan Cox wrote:

>>   If this is about maintainability, why not just a simple flag stating if
>> source is available or not.

>Available under what terms, NDA'd, subject to unacceptable other rules etc..
>Its not as simple as it looks

	I thought the issue was just whether or not people could get access to the 
source code for debugging purposes. What we really need is a tag that simply 
says, 'anyone can get the source code to this module for debugging purposes 
[from this URL, maybe]'.

	DS

Re: Tainted Modules Help Notices

[John Alvord]

On Thu, 11 Oct 2001 15:42:41 -0700, David Schwartz
<davids@webmaster.com> wrote:

>
>
>On Thu, 11 Oct 2001 11:37:27 +0100 (BST), Alan Cox wrote:
>
>>>   If this is about maintainability, why not just a simple flag stating if
>>> source is available or not.
>
>>Available under what terms, NDA'd, subject to unacceptable other rules etc..
>>Its not as simple as it looks
>
>	I thought the issue was just whether or not people could get access to the 
>source code for debugging purposes. What we really need is a tag that simply 
>says, 'anyone can get the source code to this module for debugging purposes 
>[from this URL, maybe]'.

URLs go bad and non-responsive regularly,,,

john

Re: Tainted Modules Help Notices

[David Schwartz]

>URLs go bad and non-responsive regularly,,,
>john

	Yes, but modules that have available source code don't often morph into 
modules that don't. The desired information is whether or not the source code 
is easily available for debugging.

	Perhaps the best solution is to develop a 'kernel module license' that 
simply requires that the source code be made available to anyone who wishes 
to debug for the purpose of debugging. Complying with the terms of the 
'kernel module license' would give you module that don't taint the kernel. 

	The license would be liberal in that it would allow you to impose a wide 
array of other licensing terms that didn't interfere with debugging. Though 
NDA requirements or any form of explicit contract to obtain the source 
wouldn't be allowed.

	This license wouldn't be compatible with the GPL since it would be 
considered an additional restriction - the GPL doesn't require you to make 
source code available to anyone who wants it and this license would require 
you to do so. It would, however, be compatible with the BSD license. BSD 
licenses shouldn't automatically cause no tainting of the kernel because the 
BSD license doesn't assure that the source code will be available.

	Because this really isn't a copyright enforcement scheme, it's not clear (at 
least to me) how using the tag falsely would be a DMCA violation. However, if 
the tag were copyrighted, displaying it falsely would be a violation of 
several laws (including simple fraud).

	DS

Re: Tainted Modules Help Notices

[Robert Love]

On Thu, 2001-10-11 at 21:12, David Schwartz wrote:
> 	Perhaps the best solution is to develop a 'kernel module license' that 
> simply requires that the source code be made available to anyone who wishes 
> to debug for the purpose of debugging. Complying with the terms of the 
> 'kernel module license' would give you module that don't taint the kernel. 

But if we couldn't release the (fixed) source, then what is the point? 
If it is not open source, why should Alan or I or anyone care to debug
it?

What we want is for users to not have a tainted kernel, so we can debug
the problem and release the results.  We are interested in fixing our (=
the open source community's) problems, not others.

	Robert Love

Re: Tainted Modules Help Notices

[James Sutherland]

On Thu, 11 Oct 2001, Pekka Pietikäinen wrote:

> On Thu, Oct 11, 2001 at 09:35:34AM +0000, Henning P. Schmiedehausen wrote:
> > How about
> >
> > "BSD (included in kernel source)"
> >
> > to make clear that this is part of the distributed kernel _sources_.
> >
> > "included in kernel" could also be a 3rd party binary only driver
> > added by a Linux distribution vendor.
> Or even something like "BSD (unmodified source freely available)", which
> would cover 3rd party drivers as well.

"BSD (GPL compatible)"? Or a more generic "Other GPL compatible"?

For that matter, it's not GPL compatibility that matters here, it's source
availability for debugging purposes; AIUI, even an "old-style BSD" module
shouldn't taint the kernel.

Better still, rather than the licensing details, have the source URL.
Either MODULE_SOURCE_URL("http://example.com/drivers/linux/scsi.html") or
MODULE_BINARY_ONLY, with the latter tainting the kernel since the source
is not *freely* available?


James.
-- 
"Our attitude with TCP/IP is, `Hey, we'll do it, but don't make a big
system, because we can't fix it if it breaks -- nobody can.'"

"TCP/IP is OK if you've got a little informal club, and it doesn't make
any difference if it takes a while to fix it."
		-- Ken Olson, in Digital News, 1988

Re: Tainted Modules Help Notices

[David Woodhouse]

kaos@ocs.com.au said:
> David Woodhouse <dwmw2@infradead.org> wrote:
> > BSD-licensed modules shouldn't mark the kernel as tainted. If they do, 
> > that's surely a bug.

>  Any license not listed in include/linux/module.h is not GPL
> compatible. That list is currently (2.4.11) 

In the world I live in,  the BSD licence without the advertising clause is
GPL compatible.

Hence, the complaint from modutils signifies a bug, either in the wording of
the MODULE_LICENSE tag for the offending module, or in the list of valid
licences. I care not which - that's an implementation issue for you to
decide.

> > The warning should probably read 'Incompatible licence' instead of
> > 'non-GPL', too.

>  No.  Any license text not approved as GPL compatible is, by
> definition, incompatible. 

Er, yes. By definition, incompatible. 'Incompatible' is a good word to use
when warning the user; the problem is not that the licence is non-GPL, but
that is it not _compatible_ with the GPL - now why didn't I think of using
that word?

--
dwmw2

Re: Tainted Modules Help Notices

[Alexander Viro]

On Wed, 10 Oct 2001, David Woodhouse wrote:

> 
> kaos@ocs.com.au said:
> > David Woodhouse <dwmw2@infradead.org> wrote:
> > > BSD-licensed modules shouldn't mark the kernel as tainted. If they do, 
> > > that's surely a bug.
> 
> >  Any license not listed in include/linux/module.h is not GPL
> > compatible. That list is currently (2.4.11) 
> 
> In the world I live in,  the BSD licence without the advertising clause is
> GPL compatible.

So is LGPL, for that matter.  And yes, it _does_ make sense, especially
for headers.

Re: Tainted Modules Help Notices

[Alan Cox]

>     What surprised me was the PPP compression modules, I didn't use PPP in 2.4.10 so maybe
> the notice was there in 2.4.10, but I didn't use them so I didn't see it. I shouldn't have
> been surprised, but I was. BSD compression, BSD license... doh... :>

Some of these are just things we need to tidy

>     After this discovery, I would like to ask opinions on including licensing terms in
> item/module help files. It would be very convient if under dpt_i2o help it said that it
> was licensed under BSD-NAC.

The kernel dpt_i2o is GPL. Its in part built from GPL'd code I wrote but
mostly from what I assume was originally a  cross platform dpt source set.

Alan

RE: Tainted Modules Help Notices

[Bonds, Deanna]

> 
> The kernel dpt_i2o is GPL. Its in part built from GPL'd code 
> I wrote but
> mostly from what I assume was originally a  cross platform 
> dpt source set.
> 
> Alan

The main dpt_i2o files are GPL.  There are some header files that are used
for the ioctl interface that are used across all platforms and management
utilities.  They were originally released under BDS license for the most
flexibility.  But we have no problems in re-releasing them under GPL as long
as we have the 'copy-back' right and can continue to use them in our other
products.  All we would be concerned with is not having to GPL all the
software that uses those headers (which is pretty much everything related to
the i2o raid cards on every OS).  

Deanna

Re: Tainted Modules Help Notices

[Arjan van de Ven]

"Bonds, Deanna" wrote:
> 
> >
> > The kernel dpt_i2o is GPL. Its in part built from GPL'd code
> > I wrote but
> > mostly from what I assume was originally a  cross platform
> > dpt source set.
> >
> > Alan
> 
> The main dpt_i2o files are GPL.  There are some header files that are used
> for the ioctl interface that are used across all platforms and management
> utilities.  They were originally released under BDS license for the most
> flexibility.  But we have no problems in re-releasing them under GPL as long
> as we have the 'copy-back' right and can continue to use them in our other
> products.  All we would be concerned with is not having to GPL all the
> software that uses those headers (which is pretty much everything related to
> the i2o raid cards on every OS).

Then dual-licensing it with BSD and GPL sounds the way to go; quite a
few drivers
do that, and I can't imagine anyone having a problem with that.