public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Keith Owens <kaos@ocs.com.au>
To: linux-kernel@vger.kernel.org
Subject: MODULE_LICENSE and EXPORT_SYMBOL_GPL
Date: Thu, 18 Oct 2001 13:23:53 +1000	[thread overview]
Message-ID: <8658.1003375433@kao2.melbourne.sgi.com> (raw)

That has been a lot of uninformed and confused comment on l-k about
MODULE_LICENSE and EXPORT_SYMBOL_GPL.  I will try to make this as
simple as possible, to improve the signal to noise ration on this list.

Don't bother cc'ing me on any replies.  Also I don't care what your
view of the GPL is or should be.

MODULE_LICENSE

MODULE_LICENSE() allows kernel developers to identify kernels that have
been tainted by modules whose source code is not generally available.
No source code means that only the supplier can debug the problem so
send the bug report to them, not l-k.  Precisely which license string
indicates that source is freely available is still being fine tuned.

A module without a license must be assumed to be proprietary.  Not all
existing modules have a MODULE_LICENSE() yet but most do, the rest are
not far behind.  For code that is not in the standard kernel tree, it
is up to the supplier to set the license string accordingly.  I
recommend that binary only modules contain a string like :-

  MODULE_LICENSE("Proprietary.  Send bug reports to joe.bloggs@somewhere")

Modutils marks the kernel as tainted when it loads a module without a
GPL compatible MODULE_LICENSE(), reporting the license string so users
know where to send bug reports.  Oops reports the tainted status of the
kernel.  Kernel developers can decide if they want to look at tainted
bug reports or not.  End of story.

Somebody raised the red herring of linking proprietary code into the
kernel.  If you compile and link code into the kernel and do not
provide the source then you cannot distribute the resulting kernel.  To
do so is a breach of GPL conditions, read the GPL if you don't believe
me.  There is nothing to stop you building your own kernel with binary
only code and using it internally, but any bugs are your problem and
you cannot distribute the result.

EXPORT_SYMBOL_GPL

Some kernel developers are unhappy with providing external interfaces
to their code, only to see those interfaces being used by binary only
modules.  They view it as their work being appropriated.  Whether you
agree with that view or not is completely irrelevant, the person who
owns the copyright decides how their work can be used.

EXPORT_SYMBOL_GPL() allows for new interfaces to be marked as only
available to modules with a GPL compatible license.  This is
independent of the kernel tainting, but obviously takes advantage of
MODULE_LICENSE() strings.

EXPORT_SYMBOL_GPL() may only be used for new exported symbols, Linus
has spoken.  I believe the phrase involved killer penguins with
chainsaws for anybody who changed existing exported interfaces.

System calls are not affected and cannot be, that is yet another red
herring.  Anybody who thinks otherwise does not understand the GPL.
System calls define how user space code accesses the kernel, nobody
pretends that a binary only user space program cannot use a syscall.


             reply	other threads:[~2001-10-18  3:23 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-10-18  3:23 Keith Owens [this message]
2001-10-18  4:03 ` MODULE_LICENSE and EXPORT_SYMBOL_GPL Alexander Viro
2001-10-19  7:16 ` Kai Henningsen
2001-10-19  8:26   ` Nils Philippsen
  -- strict thread matches above, loose matches on Subject: below --
2001-10-18 16:05 Roy Murphy
2001-10-18 15:17 ` Arjan van de Ven
2001-10-19 15:30   ` Taral
2001-10-21 15:22     ` Alan Cox
2001-10-21 20:16       ` Taral
2001-10-19 17:06   ` David Woodhouse
2001-10-18 16:43 Roy Murphy
2001-10-18 15:49 ` Arjan van de Ven
2001-10-18 18:42   ` Tim Bird
2001-10-19 15:38   ` Taral
2001-10-18 16:07 ` Jan-Benedict Glaw
2001-10-18 22:38   ` David Lang
2001-10-19  0:46     ` John Alvord
2001-10-18 23:57       ` David Lang
2001-10-19 12:44         ` Reid Hekman
2001-10-19 20:07           ` David Lang
2001-10-20  0:00             ` Reid Hekman
2001-10-20  6:38             ` Keith Owens
2001-10-21 15:06               ` Alan Cox
2001-10-21 15:47 ` Alan Cox
2001-10-19 18:03 Roy Murphy

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=8658.1003375433@kao2.melbourne.sgi.com \
    --to=kaos@ocs.com.au \
    --cc=linux-kernel@vger.kernel.org \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox