Re: New extension: Inotify
| From: | Derick Rethans | 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