Messages in this thread | | | Date | Tue, 18 Nov 2008 17:52:21 +0100 | From | "Fredrik Markström" <> | Subject | Re: Developing non-commercial drivers ? |
| |
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.. > -- 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/
| |