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.
>
>
>[email protected] 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.
[email protected] 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
[email protected] 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
> 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
On Wed, 10 Oct 2001 09:20:58 +0100,
David Woodhouse <[email protected]> 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.
On Wed, 10 Oct 2001, Keith Owens wrote:
> On Wed, 10 Oct 2001 09:20:58 +0100,
> David Woodhouse <[email protected]> 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.
On Wed, 10 Oct 2001 09:59:01 -0400 (EDT),
Alexander Viro <[email protected]> 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.
>
> 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
[email protected] said:
> David Woodhouse <[email protected]> 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
On Wed, 10 Oct 2001, David Woodhouse wrote:
>
> [email protected] said:
> > David Woodhouse <[email protected]> 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.
"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.
> 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
[email protected] 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
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).
> 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.
> 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.
On Wed, 10 Oct 2001 13:28:21 -0700 (PDT),
"Morgan Collins [Ax0n]" <[email protected]> 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.
> 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.
>>>>> "alan" == Alan Cox <[email protected]> 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
On Oct 11, 2001 01:02 +0200, Juan Quintela wrote:
> >>>>> "alan" == Alan Cox <[email protected]> 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
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
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.
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]" <[email protected]>
To: <[email protected]>
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 [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
[email protected] 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
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 - [email protected] - http://www.devcon.net
> What about simply adding "BSD (included in kernel)" as a possible
> "untainted" MODULE_LICENSE()?
Sounds sane to me
Alan Cox <[email protected]> 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 [email protected]
Am Schwabachgrund 22 Fon.: 09131 / 50654-0 [email protected]
D-91054 Buckenhof Fax.: 09131 / 50654-20
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
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
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.
> 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
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
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
On Thu, 11 Oct 2001 15:42:41 -0700, David Schwartz
<[email protected]> 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
>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
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