Re: Uploading extensions to PECL
| From: | John Boehr | Date: | Wed, 04 May 2016 21:36:10 +0000 |
| Subject: | Re: Uploading extensions to PECL | ||
| References: | 1 2 3 4 5 6 | Groups: | php.pecl.dev |
| Request: | Send a blank email to pecl-dev+get-13731@lists.php.net to get a copy of this message | ||
Thanks for the comprehensive answer.
For the handlebars PHP module, would dual (PHP or LGPL) work?
I offered to change the license on the 'handlebars.c' repo because the
submission page states:
> Note: wrappers for GPL (all versions) or LGPLv3 libraries will not be
accepted.
For the psr extension, it might make sense to change the license on this to
match the PHP-FIG repositories of which it is a port (MIT License). If the
PHP License is better and a valid choice, I can do that as well.
On Wed, May 4, 2016 at 4:52 AM, Johannes Schlüter <johannes@php.net> wrote:
> On Fri, 2016-04-29 at 10:03 -0700, John Boehr wrote:
> > Thanks for the explanation. Just to be clear, I'm willing to change the
> > license on the three LGPLv3 repositories to 'LGPLv2 or later' Is that
> > acceptable for inclusion in PECL?
>
> I haven't reviewed this in detail. Some comments:
> * GPL (without leading L) is incompatible with the PHP License.
> distributing code (a PHP Extension) using a GPL library and PHP
> thus would conflict with licensing terms.
> * It is common to build extensions statically into PHP. If an
> extension is licensed under LGPL and statically built in (and
> then distributed with) PHP the LGPL considers this as a single
> work which has to comply with LGPL. This is a notable problem
> for extensions we bundle. Your module would likely be built as a
> shared module and it's unlikely to be bundled with the PHP
> distribution putting it under LGPL onto PECL shouldn't be an
> *legal* issue.
> * I haven't reviewed LGPL 2 vs LGPL 3, for GPL 2 vs GPL 3 the
> "Tivo clause" is seen as too broad. No idea if this has legal
> impact here for us.
>
> That's were some legal aspects (while IANAL applies)
>
> Aside from that there is a political/opinion side to this:
>
> We prefer PHP modules to be licensed under PHP/BSD/MIT-style licenses. A
> library used can however be LGPL-licensed (I assume LGPL3 would be fine)
>
> Of course this separation, when library and PHP module are from the same
> author, is a bit arbitrary but with such a licensing scheme we can do a
> few things we couldn't do if all your code was LGPL:
>
> * We can apply changes to extensions, i.e. when APIs change (most
> of those changes might be seen as non-copyrightable but there
> might be cases where a non-totally-trivial change is created by
> one contributor and then copied to different modules by a
> different contributor (thus the second contributor doesn't own
> it and can't freely relicense it)
> * In case you have an interesting routine for doing something PHP
> we could move it into core parts with less legal implications.
>
> johannes
>
> > On Fri, Apr 29, 2016 at 7:30 AM, Ben Ramsey <ben@benramsey.com> wrote:
> >
> > > Yes. It doesn't explicitly disallow wrappers for LGPLv2 libraries (or
> LGPL
> > >> extensions for that matter), and doesn't explain why it's discouraged.
> > >>
> > >
> > > Someone else on the list may be able to give a better reason for this,
> and
> > > I think there might be some historical context involved.
> > >
> > > Disclaimer: IANAL...
> > >
> > > In general, your extension links against LGPL code. When your
> extension is
> > > installed and PHP is configured to load your extension, it can be said
> to
> > > be linking against your extension and, through your extension, also
> against
> > > the LGPL library. This gets into weird ambiguities about what
> constitutes
> > > linking and whether users are allowed to do these things in a legal
> way,
> > > according to the licenses, and while the LGPL was created to allow
> these
> > > libraries to be used in proprietary code, it has a lot of requirements
> > > placed on the use of their code. These requirements are intended to
> protect
> > > users of the library, but they often hinder what developers can do.
> > >
> > > PHP has a bit of an odd history with the GPL, and as a result, PHP
> chose
> > > to go the route of using more permissive licenses (Apache, MIT, BSD,
> etc.),
> > > and that's primarily why we encourage the use of these looser licenses
> for
> > > anything that will be distributed through pecl.php.net (and other PHP
> > > properties).
> > >
> > > There's nothing to restrict you from using LGPLv3 and GPL libraries in
> > > extensions, though. They just can't be distributed through
> pecl.php.net.
> > >
> > > -Ben
> > >
>
>
>