On Tue, Jun 13, 2006 at 02:12:41PM -0700, Daniel Phillips wrote: > This has the makings of a nice stable internal kernel api. Why do we want > to provide this nice stable internal api to proprietary modules? because there is IMHO legally nothing we can do about it anyway. Use of an industry-standard API that is provided in multiple operating system is one of the clearest idnication of some program _not_ being a derivative work. Whether we like it or not, it doesn't really matter if we export them GPL-only or not. Anybody using those scoket API calls will be having an easy time arguing in favor of non-derivative work. The GPL doesn't extend beyon what copyright law allows you to do... -- - Harald Welte <[email protected]> http://gnumonks.org/ ============================================================================ We all know Linux is great...it does infinite loops in 5 seconds. -- Linus
Attachment:
pgpyrnAMkLpNf.pgp
Description: PGP signature
- Follow-Ups:
- Re: [RFC/PATCH 1/2] in-kernel sockets API
- From: Daniel Phillips <[email protected]>
- Re: [RFC/PATCH 1/2] in-kernel sockets API
- From: Erik Mouw <[email protected]>
- Re: [RFC/PATCH 1/2] in-kernel sockets API
- References:
- [RFC/PATCH 1/2] in-kernel sockets API
- From: Sridhar Samudrala <[email protected]>
- Re: [RFC/PATCH 1/2] in-kernel sockets API
- From: Stephen Hemminger <[email protected]>
- Re: [RFC/PATCH 1/2] in-kernel sockets API
- From: "Brian F. G. Bidulock" <[email protected]>
- Re: [RFC/PATCH 1/2] in-kernel sockets API
- From: Daniel Phillips <[email protected]>
- [RFC/PATCH 1/2] in-kernel sockets API
- Prev by Date: Re: NPTL mutex and the scheduling priority
- Next by Date: Re: [PATCH 2.6.17-rc6 7/9] Remove some of the kmemleak false positives
- Previous by thread: Re: [RFC/PATCH 1/2] in-kernel sockets API
- Next by thread: Re: [RFC/PATCH 1/2] in-kernel sockets API
- Index(es):