Re: Uploading extensions to PECL

From: 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 > > > > > >

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