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

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

* Martin Donnelly <md@uklinux.net> on Thu, Oct 18, 2001:

> 
> It is a completely naive idea. You export some symbols as
> EXPORT_MODULE_GPL(). I write a wrapper which is GPL'd but i don't export
> my symbols as EXPORT_MODULE_GPL(), i now can interface to your code from
> a proprietry module without breach of license through my wrapper with
> very little work on my part.

Prorprietary modules do that anyways, your workaround isn't anything new
(NVIDIA's module comes to mind).  If you don't want to use
EXPORT_MODULE_GPL(), don't use it, and if you're willing to make the effort
to write a wrapper and accept the blight that comes with it, by all means
go ahead.  Thanks for pointing out the obvious.

> Your probably the same people who run about using ROT13 as encryption.

I fail to see how this statement has anything to do with the above
paragraph.  But anyway, I use PGP-based and other forms of encryption (did
you notice that this e-mail is signed?).

>  
> That is you decision and you are free to have it, but don't try and
> force it on other people by saying if you don't have a system running
> 100% GPL'd (or compatibly) licensed kernel - we reserve the right to
> ignore any bugs you try and inform us about, regardless of whether or
> not is is to do with the binary only module. It isn't exactly
> encouraging.
> 

It's not force, it's a choice.  That taint mechanism is by no means force,
it doesn't force modules to be GPL-compatible, it just taints when a module
isn't.  Tainting and EXPORT_MODULE_GPL() are two entirely different things,
intended to accomplish entirely seperate goals.  Are you able to make that
distinction?  It seems from the posts so far that most people can't.  The
only thing in common with tainting and EXPORT_MODULE_GPL() is the
MODULE_LICENSE() macro.  Any other comparisons are apples and oranges.

> Perhaps a less blunt tool could be used to encourage people to release
> GPL compatibly licensed code for their previously binary modules? I
> think you risk manufacturers withdrawing the support they have given by
> saying if they don't release their code we won't support anything to do
> with it. Carrots work better than sticks.
> 

The GPL was the tool, but since binary-only modules were allowed
EXPORT_MODULE_GPL() takes on that role.  And again, you confuse tainting
with GPL-only symbols, the support issue comes from tainted kernels - so
no, we won't support anything to do with unreleased code.

M. R.

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

  parent reply	other threads:[~2001-10-18 15:48 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
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 [this message]
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=20011018104835.J22296@0xd6.org \
    --to=mrbrown@0xd6.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=md@uklinux.net \
    --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.