public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Krzysztof Halasa <khc@pm.waw.pl>
To: <linux-kernel@vger.kernel.org>
Cc: Jamie Lokier <jamie@shareable.org>
Subject: Re: Using GPL'd Linux drivers with non-GPL, binary-only kernel
Date: 08 May 2003 13:11:00 +0200	[thread overview]
Message-ID: <m3llxhlmm3.fsf@defiant.pm.waw.pl> (raw)
In-Reply-To: <20030506164252.GA5125@mail.jlokier.co.uk>

Jamie Lokier <jamie@shareable.org> writes:

> I was mulling over a commercial project proposal, and this question
> came up:
> 
> What's the position of kernel developers towards using the GPL'd Linux
> kernel modules - that is, device drivers, network stack, filesystems
> etc. - with a binary-only, closed source kernel that is written
> independently of Linux?

IANAL, but Linux drivers are usually licensed under the GPL and not LGPL.
> 
> I realise that linking the modules directly with the binary kernel is
> a big no no, but what if they are dynamically loaded?

You mean one big file versus many small fragments? I don't think there
is a difference. LGPL would permit that (in fact, it seems to be the
difference between GPL and LGPL).

> There seems to be a broad agreement, and I realise it isn't unanimous,
> that dynamically loading binary-only modules into the Linux kernel is
> ok.

That's different, the modules are not (generally) derivatives of the
kernel. The (running) kernel is a derivative of both the GPL code and
binary drivers (all parts are linked at run time) - and while you can't
distribute such a beast at all, you usually don't want to.
(which makes me wonder if "distributing" a running machine with binary
drivers linked to the kernel is legal :-) )

>  Furthermore, there are some funny rules about which interfaces a
> binary-only module may use and which it may not, before it's
> considered a derivative work of the kernel.

IMHO it's independent problem, not related to the license, but rather
to source code symbol names (a technical and not legal issue - something
like copy-protection mechanisms).

> So, as dynamic loading is ok between parts of Linux and binary-only
> code, that seems to imply we could build a totally different kind of
> binary-only kernel which was able to make use of all the Linux kernel
> modules.

Build - sure. However, distributing such a system (with GPLed parts)
would be illegal, unless the GPLed code is not a part of the system,
and rather an "independent and separate work" (i.e. the system does not
"depend" on GPL part).
-- 
Krzysztof Halasa
Network Administrator

  parent reply	other threads:[~2003-05-08 17:14 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-05-06 16:42 Using GPL'd Linux drivers with non-GPL, binary-only kernel Jamie Lokier
2003-05-06 17:35 ` Alan Cox
2003-05-06 18:54   ` Jamie Lokier
2003-05-06 19:28     ` Jean-Marc Lienher
2003-05-06 19:53     ` Alan Cox
2003-05-06 22:31       ` Jamie Lokier
2003-05-06 21:38         ` Alan Cox
2003-05-08 21:36     ` Pavel Machek
2003-05-06 19:17 ` Eric W. Biederman
2003-05-06 21:55   ` Jamie Lokier
2003-05-06 22:21     ` David Schwartz
2003-05-07  8:21     ` Eric W. Biederman
2003-05-07 14:25       ` Valdis.Kletnieks
2003-05-07 14:31         ` Jamie Lokier
2003-05-07 15:50           ` Eric W. Biederman
2003-05-06 20:43 ` Pavel Machek
2003-05-06 22:18   ` Jamie Lokier
2003-05-06 21:31     ` Alan Cox
2003-05-06 22:48       ` Jamie Lokier
2003-05-07 12:20         ` Alan Cox
2003-05-07 14:26           ` Jamie Lokier
2003-05-07 15:18             ` Pavel Machek
2003-05-08 11:11 ` Krzysztof Halasa [this message]
     [not found] <20030506165014$3d57@gated-at.bofh.it>
     [not found] ` <20030506193019$0d29@gated-at.bofh.it>
     [not found]   ` <20030506220018$5b96@gated-at.bofh.it>
2003-05-07  1:17     ` Tony 'Nicoya' Mantler
     [not found] <BKEGKPICNAKILKJKMHCAAEBCCLAA.Riley@Williams.Name>
2003-05-07 16:57 ` Eric W. Biederman
  -- strict thread matches above, loose matches on Subject: below --
2003-05-09  1:23 Jean Tourrilhes
2003-05-13  9:08 Dean McEwan

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=m3llxhlmm3.fsf@defiant.pm.waw.pl \
    --to=khc@pm.waw.pl \
    --cc=jamie@shareable.org \
    --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