Re: Uploading extensions to PECL
| From: | Johannes Schlüter | Date: | Wed, 04 May 2016 11:52:19 +0000 |
| Subject: | Re: Uploading extensions to PECL | ||
| References: | 1 2 3 4 5 | Groups: | php.pecl.dev |
| Request: | Send a blank email to pecl-dev+get-13728@lists.php.net to get a copy of this message | ||
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
> >