From: "Fredrik Markström" <fredrik.markstrom@avalonenterprise.com>
To: "Robert Hancock" <hancockr@shaw.ca>
Cc: linux-kernel@vger.kernel.org
Subject: Re: Developing non-commercial drivers ?
Date: Tue, 18 Nov 2008 17:52:21 +0100 [thread overview]
Message-ID: <7a9e70560811180852y9eb2bf6s8682609dcb10fd9f@mail.gmail.com> (raw)
In-Reply-To: <4922ED5A.3030808@shaw.ca>
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.
Is your short answer also the definite answer considering this ?
/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..
>
next prev parent reply other threads:[~2008-11-18 16:52 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-11-18 16:16 Fredrik Markström
2008-11-18 16:29 ` Robert Hancock
2008-11-18 16:52 ` Fredrik Markström [this message]
2008-11-18 17:04 ` Robert Hancock
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=7a9e70560811180852y9eb2bf6s8682609dcb10fd9f@mail.gmail.com \
--to=fredrik.markstrom@avalonenterprise.com \
--cc=hancockr@shaw.ca \
--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
all inboxes | Powered by JetHome®