linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* RE: How to Avoid GPL Issue
@ 2003-07-01 19:36 Heater, Daniel (IndSys, GEFanuc, VMIC)
  2003-07-01 19:55 ` Steven Cole
  0 siblings, 1 reply; 7+ messages in thread
From: Heater, Daniel (IndSys, GEFanuc, VMIC) @ 2003-07-01 19:36 UTC (permalink / raw)
  To: 'G. C.', linux-kernel

> 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?

It depends on what you intend to do with your port. If it is only for
internal use (you will not distribute the ported code in any form)
then you may not be required to supply the source code to anyone. This is
a common interpretation of the GPL (although I can not find explicit
language providing for this interpretation in the license).


^ permalink raw reply	[flat|nested] 7+ messages in thread

* RE: How to Avoid GPL Issue
  2003-07-01 19:36 How to Avoid GPL Issue Heater, Daniel (IndSys, GEFanuc, VMIC)
@ 2003-07-01 19:55 ` Steven Cole
  0 siblings, 0 replies; 7+ messages in thread
From: Steven Cole @ 2003-07-01 19:55 UTC (permalink / raw)
  To: Heater, Daniel (IndSys,  GEFanuc, VMIC); +Cc: 'G. C.', linux-kernel

On Tue, 2003-07-01 at 13:36, Heater, Daniel (IndSys, GEFanuc, VMIC)
wrote:
> > 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?
> 
> It depends on what you intend to do with your port. If it is only for
> internal use (you will not distribute the ported code in any form)
> then you may not be required to supply the source code to anyone. This is
> a common interpretation of the GPL (although I can not find explicit
> language providing for this interpretation in the license).

Look here:
http://www.gnu.org/licenses/gpl-faq.html#GPLRequireSourcePostedPublic

Steven



^ permalink raw reply	[flat|nested] 7+ messages in thread

* re: How to Avoid GPL Issue
@ 2003-06-29  4:53 Dan Kegel
  0 siblings, 0 replies; 7+ messages in thread
From: Dan Kegel @ 2003-06-29  4:53 UTC (permalink / raw)
  To: linux-kernel

GC wrote:
> 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?

Xose replied:
> You should begin reading 'Proprietary kernel modules' at
> http://people.redhat.com/rkeech/pkm.html

That's a very good summary.  Xose pointed you to the right place, GC.

Practically speaking, you can probably do what Nvidia does,
but nobody on this list will support users who run into
trouble loading your kernel module.

In other words, you may not in fact be able to avoid the GPL issue...
sorry...
- Dan

-- 
Dan Kegel
http://www.kegel.com
http://counter.li.org/cgi-bin/runscript/display-person.cgi?user=78045


^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: How to Avoid GPL Issue
  2003-06-27 23:04 G. C.
  2003-06-28  0:03 ` root
@ 2003-06-28 19:22 ` Alan Cox
  1 sibling, 0 replies; 7+ messages in thread
From: Alan Cox @ 2003-06-28 19:22 UTC (permalink / raw)
  To: G. C.; +Cc: Linux Kernel Mailing List

On Sad, 2003-06-28 at 00:04, G. C. wrote:
> 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?
> 
> Thank you very much in advance,

I can understand why you asked the question here, but you need to ask a
lawyer. The GPL license forbids derivative works being nonfree (eg
binary only). Your question boils down to "what is not a derivative
work", which is a lawyer not a programmer question


^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: How to Avoid GPL Issue
  2003-06-28  0:03 ` root
@ 2003-06-28  0:15   ` nick
  0 siblings, 0 replies; 7+ messages in thread
From: nick @ 2003-06-28  0:15 UTC (permalink / raw)
  To: root; +Cc: G. C., linux-kernel

I think you misunderstood the question.  He's not asking what he should
do, he's not asking what it would be nice for him to do.  He's asking what
the leagle minimum he can possibly do is.  He's not intrested in
"supporting linux" or anything like it, he meerly wants to be able to
stamp "Compatible with Linux $latest_redhat_release" on the front of the
box.
	Nick

On Sat, 28 Jun 2003 root@mauve.demon.co.uk wrote:

> > 
> > 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.
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> 


^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: How to Avoid GPL Issue
  2003-06-27 23:04 G. C.
@ 2003-06-28  0:03 ` root
  2003-06-28  0:15   ` nick
  2003-06-28 19:22 ` Alan Cox
  1 sibling, 1 reply; 7+ messages in thread
From: root @ 2003-06-28  0:03 UTC (permalink / raw)
  To: G. C.; +Cc: linux-kernel

> 
> 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.

^ permalink raw reply	[flat|nested] 7+ messages in thread

* How to Avoid GPL Issue
@ 2003-06-27 23:04 G. C.
  2003-06-28  0:03 ` root
  2003-06-28 19:22 ` Alan Cox
  0 siblings, 2 replies; 7+ messages in thread
From: G. C. @ 2003-06-27 23:04 UTC (permalink / raw)
  To: linux-kernel; +Cc: gpc01532

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?

Thank you very much in advance,

GC

_________________________________________________________________
MSN 8 with e-mail virus protection service: 2 months FREE*  
http://join.msn.com/?page=features/virus


^ permalink raw reply	[flat|nested] 7+ messages in thread

end of thread, other threads:[~2003-07-01 19:42 UTC | newest]

Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2003-07-01 19:36 How to Avoid GPL Issue Heater, Daniel (IndSys, GEFanuc, VMIC)
2003-07-01 19:55 ` Steven Cole
  -- strict thread matches above, loose matches on Subject: below --
2003-06-29  4:53 Dan Kegel
2003-06-27 23:04 G. C.
2003-06-28  0:03 ` root
2003-06-28  0:15   ` nick
2003-06-28 19:22 ` Alan Cox

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).