All of lore.kernel.org
 help / color / mirror / Atom feed
From: Richard Thrapp <rthrapp@sbcglobal.net>
To: Erik Mouw <J.A.K.Mouw@its.tudelft.nl>
Cc: Allo! Allo! <lachinois@hotmail.com>,
	linux-kernel <linux-kernel@vger.kernel.org>
Subject: Re: Kernel module ethics.
Date: 27 Feb 2002 21:59:46 -0600	[thread overview]
Message-ID: <1014868787.3565.127.camel@wizard> (raw)
In-Reply-To: <20020228005152.GB8858@arthur.ubicom.tudelft.nl>
In-Reply-To: <F82zxvoEaZWNaBJjvmZ00001183@hotmail.com> <Pine.LNX.3.95.1020227164752.16918A-100000@chaos.analogic.com>  <20020228005152.GB8858@arthur.ubicom.tudelft.nl>

On Wed, 2002-02-27 at 18:51, Erik Mouw wrote:
> On Wed, Feb 27, 2002 at 05:23:41PM -0500, Richard B. Johnson wrote:
> > So, enter the compromise. Make your proprietary stuff in separate file(s)
> > known only to your company. This keeps them trade secret. Compile them
> > into a library. Provide that library with your module. The functions
> > contained within that library should be documented as well as the
> > calling parameters (a header file). This helps GPL maintainers
> > determine if your library is broken.
> 
> Brilliant, this violates section 2b from the GPLv2. If that's OK with
> you, see a lawyer first.

Hasn't it been said (by people in control) that binary only modules are
okay to link into the kernel, or do I remember incorrectly?  How is this
different from a binary only module?  Release an open-source component
under a BSD license, or even a commercial license if you like, along
with a closed source component.  Link the two together, and finally
insmod your non-GPL amalgamation into the kernel.

Anyway, you're not distributing your kernel with your module linked in,
so you're not distributing a derivative of a GPLed program, so by my
understanding section 2b doesn't apply.  Comments?

-- 
Richard Thrapp



  parent reply	other threads:[~2002-02-28  3:54 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-02-27 21:11 Kernel module ethics Allo! Allo!
2002-02-27 21:33 ` Cyrille Chepelov
2002-02-27 22:23 ` Richard B. Johnson
2002-02-28  0:51   ` Erik Mouw
2002-02-28  1:03     ` Karl
2002-02-28  2:03       ` Erik Mouw
2002-02-28  2:13       ` Larry McVoy
2002-02-28  1:38         ` Karl
2002-03-04 14:07         ` Rogier Wolff
2002-02-28  2:37       ` John Jasen
2002-02-28  3:59     ` Richard Thrapp [this message]
2002-02-28 17:52       ` Jeff V. Merkey
2002-03-01  0:22       ` Alan Cox
2002-02-28  1:20   ` Rik van Riel
2002-02-27 22:37 ` Greg KH
2002-02-28  9:42 ` Helge Hafting
2002-02-28 13:55   ` Reid Hekman
2002-02-28 16:04   ` Mark H. Wood
2002-02-28 18:31     ` David Lang
  -- strict thread matches above, loose matches on Subject: below --
2002-02-27 21:57 Jesper Juhl
2002-02-28 12:05 Alexander Sandler
2002-03-01  0:53 ` Erik Mouw

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=1014868787.3565.127.camel@wizard \
    --to=rthrapp@sbcglobal.net \
    --cc=J.A.K.Mouw@its.tudelft.nl \
    --cc=lachinois@hotmail.com \
    --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 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.