Re: Uploading extensions to PECL

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

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