2001-10-27 03:32:00

by Keith Owens

[permalink] [raw]
Subject: Non-standard MODULE_LICENSEs in 2.4.13-ac2

These are the non-standard MODULE_LICENSEs in 2.4.13-ac2, compiling
these as modules will result in a tainted kernel. "BSD without
advertising clause" is not quite good enough for the kernel, that
licence allows for binary only modules. Kernel debuggers insist on
general source availability.

Since the source is already in the kernel which is distributed as a GPL
work, these sources are effectively dual BSD/GPL. Could the owners
please convert them to "Dual BSD/GPL"?

net/ipv4/netfilter/ipchains_core.c:MODULE_LICENSE("BSD without advertisement clause");
fs/nls/nls_cp874.c:MODULE_LICENSE("BSD without advertising clause");
fs/nls/nls_cp869.c:MODULE_LICENSE("BSD without advertising clause");
fs/nls/nls_cp866.c:MODULE_LICENSE("BSD without advertising clause");
fs/nls/nls_cp865.c:MODULE_LICENSE("BSD without advertising clause");
fs/nls/nls_cp864.c:MODULE_LICENSE("BSD without advertising clause");
fs/nls/nls_cp863.c:MODULE_LICENSE("BSD without advertising clause");
fs/nls/nls_cp862.c:MODULE_LICENSE("BSD without advertising clause");
fs/nls/nls_cp861.c:MODULE_LICENSE("BSD without advertising clause");
fs/nls/nls_cp860.c:MODULE_LICENSE("BSD without advertising clause");
fs/nls/nls_cp857.c:MODULE_LICENSE("BSD without advertising clause");
fs/nls/nls_cp855.c:MODULE_LICENSE("BSD without advertising clause");
fs/nls/nls_cp852.c:MODULE_LICENSE("BSD without advertising clause");
fs/nls/nls_cp850.c:MODULE_LICENSE("BSD without advertising clause");
fs/nls/nls_cp775.c:MODULE_LICENSE("BSD without advertising clause");
fs/nls/nls_cp737.c:MODULE_LICENSE("BSD without advertising clause");
fs/nls/nls_cp437.c:MODULE_LICENSE("BSD without advertising clause");
fs/nls/nls_cp1255.c:MODULE_LICENSE("BSD without advertising clause");
fs/nls/nls_cp1251.c:MODULE_LICENSE("BSD without advertising clause");
drivers/scsi/pci2220i.c:MODULE_LICENSE("BSD without advertising clause");
drivers/scsi/u14-34f.c:MODULE_LICENSE("BSD without advertisement clause");
drivers/scsi/pci2000.c:MODULE_LICENSE("BSD without advertisement clause");
drivers/scsi/eata.c:MODULE_LICENSE("BSD");
drivers/scsi/advansys.c:MODULE_LICENSE("BSD without advertising clause");
drivers/net/pcmcia/wavelan_cs.c:MODULE_LICENSE("BSD without advertisement clause");
drivers/net/ppp_deflate.c:MODULE_LICENSE("BSD without advertisement clause");
drivers/net/bsd_comp.c:MODULE_LICENSE("BSD without advertising clause");
drivers/net/strip.c:MODULE_LICENSE("BSD without advertisement clause");
drivers/net/slhc.c:MODULE_LICENSE("BSD without advertising clause");


2001-10-27 07:20:43

by Andreas Dilger

[permalink] [raw]
Subject: Re: Non-standard MODULE_LICENSEs in 2.4.13-ac2

On Oct 27, 2001 13:31 +1000, Keith Owens wrote:
> These are the non-standard MODULE_LICENSEs in 2.4.13-ac2, compiling
> these as modules will result in a tainted kernel. "BSD without
> advertising clause" is not quite good enough for the kernel, that
> licence allows for binary only modules. Kernel debuggers insist on
> general source availability.
>
> Since the source is already in the kernel which is distributed as a GPL
> work, these sources are effectively dual BSD/GPL. Could the owners
> please convert them to "Dual BSD/GPL"?

Ah, so Keith has become (self) nominated license God for the kernel?
Being included in the kernel source isn't "general source availability"?

I can see that you want to make this whole tainted-kernel mess work,
but I think you are confusing intent with implementation. The intent
(AFAICS) is to mark the kernel tainted ONLY if a closed-source module
is loaded, rather than to be a "license police" mechanism, especially
for sources that have been included in the kernel for a long time.

Rather than make the MODULE_LICENSE() a string that people just fill in
(which as your example shows also has problems with spelling and such)
you could have a few pre-defined values to make things easier:

#define LICENSE_STRING_GPL "GPL"
#define LICENSE_STRING_DUAL_BSD_GPL "Dual BSD/GPL"
#define LICENSE_STRING_DUAL_MPL_GPL "Dual MPL/GPL"
#define LICENSE_STRING_BSD_KERNEL "BSD without advertising clause, kernel source"

This not only means we avoid problems with spelling (which will mark a
kernel as tainted, even if it says "GNU GPL" or similar, and makes keeping
the values consistent between user-space and kernel space easier. A
NON-TAINTING license string needs to be added for BSD sources that are
part of the kernel.

I totally disagree with the assertion that a module has to be "GPL" in
order to be "OSS free" especially for sources already in the kernel,
so lets not go on a witch hunt for non-GPL licenses in the kernel just
to make this tainted stuff work without adding a new license. There is
enough animosity between the Linux and GPL camps without more fire for
the "GPL is viral, BSD is free" flamewars.

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

2001-10-27 15:37:38

by Alan

[permalink] [raw]
Subject: Re: Non-standard MODULE_LICENSEs in 2.4.13-ac2

> but I think you are confusing intent with implementation. The intent
> (AFAICS) is to mark the kernel tainted ONLY if a closed-source module
> is loaded, rather than to be a "license police" mechanism, especially
> for sources that have been included in the kernel for a long time.

"BSD" can indicate totally closed source material as well as other stuff

Also Keith is right - if it is GPL compatible BSD code linked with the
kernel then its correct to describe it as Dual BSD/GPL anyway

2001-10-28 08:06:10

by H. Peter Anvin

[permalink] [raw]
Subject: Re: Non-standard MODULE_LICENSEs in 2.4.13-ac2

Followup to: <[email protected]>
By author: Alan Cox <[email protected]>
In newsgroup: linux.dev.kernel
>
> > but I think you are confusing intent with implementation. The intent
> > (AFAICS) is to mark the kernel tainted ONLY if a closed-source module
> > is loaded, rather than to be a "license police" mechanism, especially
> > for sources that have been included in the kernel for a long time.
>
> "BSD" can indicate totally closed source material as well as other stuff
>

I was thinking about that, and that doesn't seem right to me -- you
can make closed-source derivative works based on BSD but I would
typically not refer to them as "BSD" license (think SunOS 4.1 here...)

>
> Also Keith is right - if it is GPL compatible BSD code linked with the
> kernel then its correct to describe it as Dual BSD/GPL anyway
>

I think the idea of making a standard set of macros available is a
good idea for two reasons:

a) It avoids mispellings;

b) It makes it possible to apply standard definitions to the codified
strings.

-hpa

--
<[email protected]> at work, <[email protected]> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt <[email protected]>

2001-10-28 11:16:05

by Riley Williams

[permalink] [raw]
Subject: [PATCH] Re: Non-standard MODULE_LICENSEs in 2.4.13-ac2

Hi Peter.

> I think the idea of making a standard set of macros available is a
> good idea for two reasons:
>
> a) It avoids mispellings;
>
> b) It makes it possible to apply standard definitions to the
> codified strings.

For reference, here's a summary of the strings in the 2.4.13 kernel
tarball as distributed, counted using `sort | uniq -c` to avoid spam:

6 MODULE_LICENSE("BSD without advertisement clause")
22 MODULE_LICENSE("BSD without advertising clause")
1 MODULE_LICENSE("BSD")
8 MODULE_LICENSE("Dual BSD/GPL")
15 MODULE_LICENSE("Dual MPL/GPL")
2 MODULE_LICENSE("GPL and additional rights")
1 MODULE_LICENSE("GPL v2")
912 MODULE_LICENSE("GPL")

Note particularly the line...

1 MODULE_LICENSE("GPL v2")

...which indicates that drivers/net/pcmcia/xircom_tulip_cb.c is regarded
as tainting the kernel - this string is NOT one of the ones that are
accepted as untainted. Is this reasonable?

The enclosed patch first moves the license definitions to a new header
file linux/license.h and then defines standard macros (with the ML_
prefix) for each of the above strings in standardised form, with dual
licenses listed in alphabetical order. It does NOT change any of the
uses of the MODULE_LICENSE macro, but if I get confirmation that this
patch is accepted into the kernel source tree, I'll go through the
kernel and tweak them all to match it.

Here's the definitions used for the above, in the same order.

ML_BSD_NO_AD
ML_BSD_NO_AD
ML_BSD
ML_BSD_GPL
ML_GPL_MPL
ML_GPL_PLUS
ML_GPL_V2
ML_GPL

You will note that the first two have been merged into a single
definition, as they are reasonably clearly the same license.

Best wishes from Riley.


Attachments:
mod.diff (3.16 kB)
Standardise module licenses

2001-10-28 11:34:27

by Jeff Garzik

[permalink] [raw]
Subject: Re: [PATCH] Re: Non-standard MODULE_LICENSEs in 2.4.13-ac2

Riley Williams wrote:
> Note particularly the line...
>
> 1 MODULE_LICENSE("GPL v2")
>
> ...which indicates that drivers/net/pcmcia/xircom_tulip_cb.c is regarded
> as tainting the kernel - this string is NOT one of the ones that are
> accepted as untainted.

That's definitely a bug that needs fixing... "GPL v2" shouldn't taint.

--
Jeff Garzik | Only so many songs can be sung
Building 1024 | with two lips, two lungs, and one tongue.
MandrakeSoft | - nomeansno

2001-10-29 10:16:57

by David Woodhouse

[permalink] [raw]
Subject: Re: Non-standard MODULE_LICENSEs in 2.4.13-ac2


[email protected] said:
> "BSD" can indicate totally closed source material as well as other
> stuff

"GPL" can indicate modules which are either for internal use only and not
distributed, or which are distributed only to paying customers and shipped
with source, but the source is not publicly available.

Should we make the licence string "GPL" taint the kernel too, unless it's
explicitly stated that the source is available?

--
dwmw2


2001-10-29 19:34:32

by kaih

[permalink] [raw]
Subject: Re: Non-standard MODULE_LICENSEs in 2.4.13-ac2

[email protected] (Andreas Dilger) wrote on 27.10.01 in <[email protected]>:

> On Oct 27, 2001 13:31 +1000, Keith Owens wrote:
> > These are the non-standard MODULE_LICENSEs in 2.4.13-ac2, compiling
> > these as modules will result in a tainted kernel. "BSD without
> > advertising clause" is not quite good enough for the kernel, that
> > licence allows for binary only modules. Kernel debuggers insist on
> > general source availability.
> >
> > Since the source is already in the kernel which is distributed as a GPL
> > work, these sources are effectively dual BSD/GPL. Could the owners
> > please convert them to "Dual BSD/GPL"?
>
> Ah, so Keith has become (self) nominated license God for the kernel?
> Being included in the kernel source isn't "general source availability"?
>
> I can see that you want to make this whole tainted-kernel mess work,
> but I think you are confusing intent with implementation. The intent

No, you are. Keith is asking module owners to change their part of the
*implementation*, not any *intent*. He says that if a BSD/noadv module
source is in the kernel, the correct tag is GPL/BSD, not BSD/noadv.

> I totally disagree with the assertion that a module has to be "GPL" in
> order to be "OSS free" especially for sources already in the kernel,

Sure. What it needs to be, when included with the kernel and distributed
(and the inclusion and distribution are the critical points here, not OSS-
freeness) is GPL-compatible; that means that the combination *will* be
GPL. That is the famous "viral clause" in the GPL.

That doesn't mean that non-GPL-compatible stuff isn't OSS, just that it
cannot be distributed with the kernel, because the kernel *is* GPL. It's a
consequence of the GPL, not of the OSS rules.

> so lets not go on a witch hunt for non-GPL licenses in the kernel just

As far as I can see, nobody is.

> to make this tainted stuff work without adding a new license. There is
> enough animosity between the Linux and GPL camps without more fire for
> the "GPL is viral, BSD is free" flamewars.

Aah, so it seems *you* are on a witch hunt against the GPL!

I have no idea why someone using the BSD license - which, after all,
allows for relicensing under any proprietary scheme you care to dream up -
should have any problem whatsoever with relicensing under the GPL. Nor do
I have any idea why someone using the GPL should have any problem with
anything else also available under the GPL.

There's no conflict here. We're not talking about who is more free.

MfG Kai