lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Tue, 18 Nov 2008 17:52:21 +0100
From:	"Fredrik Markström" 
	<fredrik.markstrom@...lonenterprise.com>
To:	"Robert Hancock" <hancockr@...w.ca>
Cc:	linux-kernel@...r.kernel.org
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@...w.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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ