Re: New extension: Inotify

From: Date: Wed, 09 Jul 2008 07:32:24 +0000
Subject: Re: New extension: Inotify
References: 1 2 3 4 5  Groups: php.pecl.dev 
Request: Send a blank email to pecl-dev+get-5608@lists.php.net to get a copy of this message
On Wed, 9 Jul 2008, Arnaud LB wrote: > On Tue, Jul 8, 2008 at 3:31 PM, Antony Dovgal <tony@daylessday.org> wrote: > > On 04.07.2008 22:19, Arnaud LB wrote: > >>> > >>> lnotify is a part of Linux kernel, which is GPL-licensed. > >> > >> The inotify functions are a set of syscalls, just like open() and > >> close(). Using open() in your code does not force you to release it > >> under the GPL ;) That's the same situation with inotify. > > > > open() and close() exist in other (non-GPL) systems, i.e. your code doesn't > > depend on any certain kernel/library, hence its license doesn't affect your > > code. > > > > In case of Inotify, you code was clearly done especially for Inotify and > > fully depends on Inotify, which to my understanding means that this is a > > "derivative work" and it should be GPLed, too, unfortunately. > > > > We've had an opposite case: ext/readline can link to both GPL-ed readline > > and BSD-licensed libedit, which allows us to license it under PHP license. <snip> > So, yes, my code links and depends on the glibc (which is LGPL) > because it uses these 3 convenience functions instead of using > directly the syscall() function. I think it does not cause any problem > to the PHP license, but if it does I may use syscall() directly or > write these functions myself to not depend on any specific libc. > However there are chances that other non-(L)GPL libcs export (or will > export) the inotify functions, which would make my extension to not > depend on any specific libc. Perhaps you might want to check whether ulibc has it, if that's the case even this should be in the clear. regards, Derick -- Derick Rethans http://derickrethans.nl | http://ezcomponents.org | http://xdebug.org

« previous php.pecl.dev (#5608) next »