[geos-devel] Extraction of PHP extension into PECL-style package

[J Smith]

On Wed, Jan 20, 2016 at 3:40 PM, Sandro Santilli <strk at keybit.net> wrote:
> On Wed, Jan 20, 2016 at 10:31:54AM -0500, J Smith wrote:
>
>> - "We strongly encourage contributors to choose the PHP License 3.01
>> for their extensions, in order to avoid possible troubles for
>> end-users of the extension. Other solid options are BSD and Apache
>> type licenses."
>
> I don't envision changing the license, other than maybe upgrading
> to LGPLv3.

Yeah, I don't think the underlying library license would make much of
a difference in this case, except for their strong wording about
LGPLv3 and GPLv3. On the plus side, there seems to be a move away from
PECL in general for hosting PHP extensions, so perhaps inclusion there
will become less mandatory.

>> I've never been completely comfortable with licensing
>> my own software under the PHP license because the terms of the license
>> seem to imply you have to re-assign copyright to the PHP Group. (I
>> think? The license itself says "Copyright (c) 1999 - 2014 The PHP
>> Group".)
>
> That probably covers the license text itself.

Could be, although I had a run-in years ago with a similar matter that
lead to some unpleasantness. But yeah, this might just be a copyright
on the license itself.

>> I prefer to license things under BSD or MIT licenses. For the
>> current example project I posted, I used a hybrid license to this end
>> -- the code extracted from the GEOS source is under the LGPLv2, while
>> the packaging itself is MIT.
>
> I see no problem with that.

Cool.

>> - "Note: wrappers for GPL (all versions) or LGPLv3 libraries will not
>> be accepted. Wrappers for libraries licensed under LGPLv2 are however
>> allowed while being discouraged." I'm assuming since GEOS is LGPLv2
>> there shouldn't be any problems here, but there might be some
>> grumbling from PECL potentially.
>
> GEOS being LGPL (no specific version is specified in the source code
> headers, so would be v2 or later) the wrappers should also be LGPL
> (or GPL).

Yeah, there would be no additional wrappers here, so the GEOS-owned
code itself would remain LGPL, but the build files themselves as a
package (config.m4, etc.) could be MIT or BSD. I'm not really too
concerned about the finer details here, more concerned with getting an
implementation out the door.

>> If that all sounds sane, I think this would be do-able. A longer-term
>> goal might be to do similar extractions for the Python and Ruby SWIG
>> wrappers, but I'll leave that for another day.
>
> +1
>
> So, to get you moved, I created a new "php-geos" git
> repository with "git subtree" from the official git
> mirror of GEOS.
>
> I've pushed this new repo on both github and gitlab,
> currently hosting mirror of the whole codebase:
>
>  https://github.com/libgeos/php-geos
>  https://gitlab.com/geos/php-geos
>
> If you could re-base your changes to one of these
> and send a pull-request I'll be happy to try at
> importing them back to SVN.
>
> In a second moment (possibly soon, if this gets too
> convoluted) we could decide to "bless" of of these
> places as the official one.
>

Cool, I'll take my repository and merge it into the Github one, then
I'll take down my php-geos-native repo once the new one is working
correctly. I'll add a README or something with a disclaimer stating
that this is experimental and all that, until it gets stable enough to
be releasable. I have set it up on a few of my client's dev machines
on OSX and several linux distros and it's actually working fine from
all indications, so that's a good sign.

I'll let you know when I've made the necessary changes and merged my
repo into this one. I'll also fix up the test files so they run as
phpt tests and make sure they're running. They all ran on my machine
with a bit of tweaking, but I'll take a look at some other extensions
and see how they run their tests and modify accordingly.

Cheers