linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: root@mauve.demon.co.uk
To: gpc01532@hotmail.com (G. C.)
Cc: linux-kernel@vger.kernel.org
Subject: Re: How to Avoid GPL Issue
Date: Sat, 28 Jun 2003 01:03:56 +0100 (BST)	[thread overview]
Message-ID: <200306280004.BAA23407@mauve.demon.co.uk> (raw)
In-Reply-To: <BAY8-F20kf6etlmIWMA00004812@hotmail.com> from "G. C." at Jun 27, 2003 07:04:18 PM

> 
> Dear Sir or Madam,
> 
> We are trying to port a third party hardware driver into Linux kernel and 
> this third party vendor does not allow us to publish the source code. Is 
> there any approach that we can avoid publicizing the third party code while 
> porting to Linux? Do we need to write some shim layer code in Linux kernel 
> to interface the third party code? How can we do that? Is there any document 
> or samples?

The best way is to convince them to allow you to.
Otherwise.

The right way is to write a spec for the hardware, based on the code.
Now develop a GPL driver based on this spec.
This is the best way to do it, and will result in a driver distributed with
the kernel that can be maintained and used by anyone, likely on any 
architecture that the thing can be plugged into, even if you don't decide
to work on it any more, and the original vendor dies.

There are other ways.
Probably the wrong way is to simply compile this module, and distribute
the binary. 
This will result in you needing to create at the very least dozens of binaries
at each kernel upgrade, and your driver not working at all for many people
that you haven't compiled for.

If you can't afford the time/cost to go the GPL route, probably the least 
bad option is to move as much of the code as you can into a GPL'd interface
module that talks to a small binary stub.
Ideally the binary stub does not talk to the hardware, only to your 
interface module. 
This means that you need to compile only one stub per architecture, and
even in the face of dramatic kernel changes, as the part that talks to the
kernel (and hardware) is GPL, it can be fixed by anyone.

  reply	other threads:[~2003-06-27 23:50 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-06-27 23:04 How to Avoid GPL Issue G. C.
2003-06-28  0:03 ` root [this message]
2003-06-28  0:15   ` nick
2003-06-28 19:22 ` Alan Cox
2003-06-29  4:53 Dan Kegel
2003-07-01 19:36 Heater, Daniel (IndSys, GEFanuc, VMIC)
2003-07-01 19:55 ` Steven Cole

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=200306280004.BAA23407@mauve.demon.co.uk \
    --to=root@mauve.demon.co.uk \
    --cc=gpc01532@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).