Re: Licensing in PEAR
| From: | Ian Eure | Date: | Mon, 02 Dec 2002 18:46:50 +0000 |
| Subject: | Re: Licensing in PEAR | ||
| References: | 1 | Groups: | php.pear.dev |
| Request: | Send a blank email to pear-dev+get-11304@lists.php.net to get a copy of this message | ||
On Monday 02 December 2002 10:32 am, Lukas Smith wrote:
> > -----Original Message-----
> > From: Ian Eure [mailto:ieure@debian.org]
> > Sent: Monday, December 02, 2002 7:23 PM
> > To: pear-dev@lists.php.net
> > Subject: [PEAR-DEV] Licensing in PEAR
> >
> > After trying to submit GPL'd PEAR modules[1], I've looked over the PHP
> > license, the GPL, and the LGPL. I'm feeling stuck, and I'd like
>
> advice.
>
> > PHP License:
> > Unacceptable. I will not release my code under this license, unless
>
> major
>
> > changes are made. In particular, Clause 4 irks me, in that I'm not
>
> given a
>
> > choice to bind my code to a particular version of the license. With
>
> the
>
> > (L)GPL, I may specify a specific version of the license. This is an
>
> issue
>
> > because if a later version of the PHP license contains a clause that I
> > don't
> > agree with, I have no way to prevent people from using it anyways.
> >
> > LGPL:
> > Unacceptable. This license makes it far too easy to modify the class
> > without
> > contributing the code back. For example, writing a 'wrapper' class
>
> which
>
> > overloads the original, and changes the behavior, or adds a feature,
>
> or
>
> > whatever.
>
> Do you really think this is a real world issue?
>
Sure. I think it's a bigger issue when dealing with OO code vs. shared
libraries. OO code makes it very easy to change the behavior of inherited
functions without directly modifying the code.
> I have never seen anyone write a wrapper to get around licensing issues.
>
nVidia springs to mind as a real-world example. They released the source to a
kernel module which loads a (closed) binary driver in to the kernel, to avoid
releasing the source to their drivers.
> Nor would I expect people to do it because it adds overhead, makes the
> design needlessly complex.
>
When the alternative is releasing the code to your (closed) app, I'm pretty
sure that most people would opt to have a slightly messy design. Or just
reimplement the class.
--
"das ist liebe, das ist hass / mit eifersucht vermahlen"