On 18/05/07, Shlomi Fish <[EMAIL PROTECTED]> wrote:
On Friday 18 May 2007, Amos Shapira wrote: > Hello, > > We have just noticed that one of the programs in our proprietary arsenal > uses GPL code (libipq, the netfilter interface library) even though the > contractor who wrote it was instructed to re-code the application to avoid > using GPL code. > > We are now trying to figure out a way to remove the code which uses libipq. > > The options we are thinking about: > > 1. Clean-room implementation - one programmer reads the code and describes > it in a document which is then passed to another programmer to implement. > Possibly the best solution but we suspect it'll take most effort too. > > 2. Wrap the libipq calls with a separate GPL program which will talk to the > proprietary code over pipes. It will slow things down and seems to take the > least effort, but most importantly we are not sure whether this is allowed > by the GPL. It is allowed by the GPL. A GPLed server can talk to a GPL-incompatible client with a protocol. It's like that you can use a GPLed program to edit proprietary code.
Thanks for the clarification.
> 3. Try to understand the netfilter kernel interface that libipq talks to > and write our own cut-down interface functions which do just what we need > and nothing more. For this I wonder whether it would be OK to learn the > interface by looking at the libipq code (I suspect not). It would. If you read GPLed code, and then write something, your code is not "tainted" by the GPL. Such tainting is the realm of NDAs, Microsoft's Shared-Source, etc. and does not belong in a free software licence.
That relaxation of the conditions would help a lot.
It looks like > reading the kernel side of the API IS allowed under the Linux license (and > besides, our code doesn't "link" with the kernel). You can read any GPL or free software and then write similar proprietary code.
Thanks. --Amos
