Re: Developing non-commercial drivers ?
- From: Enrico Weigelt <weigelt@xxxxxxxx>
- Date: Mon, 1 Dec 2008 01:19:13 +0100
* Fredrik Markström <fredrik.markstrom@xxxxxxxxxxxxxxxxxxxx> wrote:
Hi,
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.
Much of this already had been answered, but just to summarize:
* technically, binary drivers are a very bad idea - just look at
the utterly broken nv crap.
* IMHO, as soon as you include some kernel-internal headers, you've
got an derived work, thus violating GPL (IANAL!)
* binary-only drivers DON NOT protect IP, just delay the process
of revealing a little bit.
* try to find out whether the customer *really* has some valueble
IP to protect or if it's just it's default oppionion
* *if* the customer still wants an binary-only driver, you check
whether the logic to hide can be moved to userland (let the userland
part talk to the in-kernel driver via 9P)
* let your customer know that binary-only drivers tend to heavily
damage a company's reputation in the OSS world, *BAD* for marketing.
just my 0.02,-
cu
--
---------------------------------------------------------------------
Enrico Weigelt == metux IT service - http://www.metux.de/
---------------------------------------------------------------------
Please visit the OpenSource QM Taskforce:
http://wiki.metux.de/public/OpenSource_QM_Taskforce
Patches / Fixes for a lot dozens of packages in dozens of versions:
http://patches.metux.de/
---------------------------------------------------------------------
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
- Prev by Date: Re: [PATCH 3/3] SUNRPC: svc_xprt_enqueue should not refuse to enqueue 'XPT_DEAD' transports
- Next by Date: Re: [PATCH 0/3] NFS regression in 2.6.26?, "task blocked for more than 120 seconds"
- Previous by thread: Re: [PATCH 0/3] NFS regression in 2.6.26?, "task blocked for more than 120 seconds"
- Next by thread: [PATCH 10/9] swapfile: change discard pgoff_t to sector_t
- Index(es):
Relevant Pages
|