The Linux Kernel Mailing List
 help / color / mirror / Atom feed
From: Robert Hancock <hancockr@shaw.ca>
To: "Fredrik Markström" <fredrik.markstrom@avalonenterprise.com>
Cc: linux-kernel@vger.kernel.org
Subject: Re: Developing non-commercial drivers ?
Date: Tue, 18 Nov 2008 11:04:22 -0600	[thread overview]
Message-ID: <4922F596.1010805@shaw.ca> (raw)
In-Reply-To: <7a9e70560811180852y9eb2bf6s8682609dcb10fd9f@mail.gmail.com>

Fredrik Markström wrote:
> Thanks for the prompt respons.
> 
> I do agree that it would be better for everyone to release it under
> GPL and I have already expressed that to our customer.
> 
> At this point I feel that we have two possibilities, help our customer
> violate GPL or say no to the project. I'd prefer a third option where
> I could tell the customer that we can setup the project in a certain
> way (some "cleanroom" setup ?) to ensure that the results can not be
> considered derived work.

The problem is that if it's coded specifically for Linux it's pretty 
much inherently a derived work. Things like the NVIDIA binary graphics 
driver, the old Atheros madwifi HAL stuff, etc. are on a little more 
solid ground as their binary part is theoretically OS-independent and 
there's an open-source shim layer to interface to the kernel, but some 
would say even they are taking some legal risk.

> 
> Is your short answer also the definite answer considering this ?

I don't think anyone on this list is a lawyer, and since this is a legal 
question, legal advice would be what I would suggest you and/or this 
company should have before considering going down the non-GPL driver 
road. The risk is mainly that a kernel contributor (or one of their 
employers like IBM, Red Hat, etc.) could sue them for violating the GPL.

> 
> /Fredrik
> 
> 
> 
> 
> 2008/11/18 Robert Hancock <hancockr@shaw.ca>:
>> Fredrik Markström wrote:
>>> Linus, others...
>>>
>>> I'm working for as a consultant for a large hardware company porting
>>> Linux to their new cpu-architecture and everything is pretty much
>>> up and running. Now they want us to develop a closed-source (to
>>> protect their IP) ethernet driver for their proprietary Ethernet MAC.
>>>
>>> My question is:    Is there a fair way to do this and still comply to
>>> the intent and spirit of the Linux licensing ?
>>>
>>> If yes, how ?
>> In a word, I would say: no.
>>
>> When developing a non-GPL kernel driver, one finds themselves on very shaky
>> legal ground. Unless one is 100% sure their code is not legally considered a
>> derived work from the kernel, it's likely a GPL violation.
>>
>> One could point out the pile of other Ethernet drivers in the kernel from
>> the likes of Intel, Broadcom, etc. and ask why those companies did not feel
>> the need to "protect their IP" in this manner.. as well as the significant
>> advantages of having their driver in the mainline kernel, and the horrible
>> disadvantages of trying to manage closed-source drivers..
>>
> 

  reply	other threads:[~2008-11-18 17:04 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-11-18 16:16 Developing non-commercial drivers ? Fredrik Markström
2008-11-18 16:29 ` Robert Hancock
2008-11-18 16:52   ` Fredrik Markström
2008-11-18 17:04     ` Robert Hancock [this message]
2008-11-18 17:17     ` Xavier Bestel
2008-11-18 17:17     ` Chris Friesen
2008-11-18 18:00       ` Radhakrishnan
2008-11-18 18:13         ` Chris Friesen
2008-11-18 18:33           ` linux-os (Dick Johnson)
2008-11-18 17:40     ` Alan Cox
2008-11-22 18:16     ` Dr. David Alan Gilbert
2008-11-18 17:32 ` Alan Cox
2008-11-18 19:25 ` Valdis.Kletnieks
2008-11-18 19:29   ` Alan Cox
2008-11-18 20:20     ` Theodore Tso
2008-11-18 21:13       ` Fredrik Markström
2008-11-18 23:28         ` Theodore Tso
2008-11-19 18:38 ` Lennart Sorensen
2008-11-19 22:32   ` Fredrik Markström
2008-11-19 22:47     ` Lennart Sorensen
2008-12-01  0:19 ` Enrico Weigelt

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=4922F596.1010805@shaw.ca \
    --to=hancockr@shaw.ca \
    --cc=fredrik.markstrom@avalonenterprise.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