All of lore.kernel.org
 help / color / mirror / Atom feed
From: "M. R. Brown" <mrbrown@0xd6.org>
To: "Richard B. Johnson" <root@chaos.analogic.com>
Cc: Linux kernel <linux-kernel@vger.kernel.org>
Subject: Re: Non-GPL modules
Date: Thu, 18 Oct 2001 09:04:12 -0500	[thread overview]
Message-ID: <20011018090412.I22296@0xd6.org> (raw)
In-Reply-To: <Pine.LNX.3.95.1011018091343.32746A-100000@chaos.analogic.com>
In-Reply-To: <Pine.LNX.3.95.1011018091343.32746A-100000@chaos.analogic.com>

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

* Richard B. Johnson <root@chaos.analogic.com> on Thu, Oct 18, 2001:

> 
> >From time-to-time, I've asked that certain things be allowed
> within the kernel such as, most recently, denying a raw write
> to a mounted file-system. Such things have been opposed because,
> as I have been told, "Policy is not allowed within the kernel...".
> 
> Well, with the current GPL code-only fiasco, this is Policy being
> enforced by the kernel.
> 
> It won't be long before we get:
> 
> Script started on Thu Oct 18 08:44:44 2001
> # gcc -o applic xxx.c
> # ./applic
> Kernel panic
> Non GPL application pollution of the Linux environment
> Application name = ./applic
>  Virtual address = 0x8048528
>    Stack address = 0xbffff72c
>              PID = 32636
> System halted
> 
> I can understand not wanting to take any responsibility for
> some binary-only module when attempting to find a kernel
> problem. However, denying the use of non GPL modules is
> not the way. As a developer of many modules, I can certainly
> add the required object(s) during development and bypass the
> current policy. In fact, since the source code of `insmod`
> is available, it won't be long before any checks put there
> are eliminated. 
> 

I've seen this skewed view being reiterated time and time enough on the
list to ask,

Are you people on crack?

Where is policy being enforced?  insmod spits out a *warning* and procedes
to taint the kernel.  That's it.  It doesn't prevent such modules from
being loaded, it doesn't go back on Linus' provision to allow proprietary
modules, and it doesn't e-mail RMS with the subject "Linux (not GNU/Linux) is
no longer pure".  From reading Alan's posts, the primary purpose of this
provision is to help kernel hackers determine whether it's worth their
while to follow up on bug reports.  You can only do this with a "pure"
kernel, since you have no way of knowing if it's something in the
binary-only module that's killing the kernel.

Why the conspiracy?

As far as EXPORT_MODULE_GPL is concerned, I think that's an excellent idea.
There is *nothing* wrong with a copyright holder enforcing the fair use of
his/her software, and I'd encourage all new GPL'd modules to start
exporting these symbols.

There are some of us who strive to keep the kernel as "pure" as possible,
for a variety of reasons, the main one for me being peace of mind (knowing
my code base is supported, and bugfixes are cheap).  Why is this so
difficult for folks to grasp?

I'll shutup now, please read Keith Owen's post ("MODULE_LICENSE and
EXPORT_SYMBOL_GPL") for any more clarification.

M. R.

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

  parent reply	other threads:[~2001-10-18 14:04 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-10-18 13:15 Non-GPL modules Richard B. Johnson
2001-10-18 13:38 ` Adrian Bunk
2001-10-18 13:58   ` Richard B. Johnson
2001-10-18 14:11     ` Ben Collins
2001-10-18 14:46       ` Richard B. Johnson
2001-10-18 14:53         ` Peter T. Breuer
2001-10-18 15:21           ` Richard B. Johnson
2001-10-18 15:40             ` Peter T. Breuer
2001-10-18 16:40               ` Jan Niehusmann
2001-10-18 17:02         ` Martin Dalecki
2001-10-18 17:16           ` Ben Collins
2001-10-18 17:15             ` Martin Dalecki
2001-10-18 18:06               ` Mark Hahn
2001-10-18 14:06   ` Ben Collins
2001-10-18 14:04 ` M. R. Brown [this message]
2001-10-18 14:31   ` Jesper Juhl
2001-10-18 14:37   ` Martin Donnelly
2001-10-18 14:50     ` Arjan van de Ven
2001-10-18 15:48     ` M. R. Brown
2001-10-20 22:08     ` Alan Cox

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20011018090412.I22296@0xd6.org \
    --to=mrbrown@0xd6.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=root@chaos.analogic.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.