Everything
php
Learn Community Releases The PHP Project
Home » Project » Newsgroups » php.internals » Extensions License »

Extensions License

php.internals

Remi Collet

9 years ago
Hi, All extensions in php-src are PHP 3.01 Licensed (libs may, of course, have different license) Is there any strong rule about this ? Or is it OK to have a BSD Licensed extension ? Context: see sodium PR https://github.com/php/php-src/pull/2560 IMHO, make sense to have only PHP Licensed ext. Remi

Nikita Popov

9 years ago
On Tue, Jun 13, 2017 at 8:23 AM, Remi Collet <remi@fedoraproject.org> wrote:
> Hi, > > All extensions in php-src are PHP 3.01 Licensed > (libs may, of course, have different license) > > Is there any strong rule about this ? > Or is it OK to have a BSD Licensed extension ? > > Context: see sodium PR > https://github.com/php/php-src/pull/2560 > > > IMHO, make sense to have only PHP Licensed ext. >
I think we should allow BSD/MIT licenses, as they are compatible with and less restrictive than the PHP license. TBH, the PHP license seems somewhat dubious when applied to extensions, as most of the additional clauses are simply not applicable (extensions do not bundle the Zend Engine and extensions have no control over the PHP group or the PHP name). Regards, Nikita

Sara Golemon

9 years ago
On Thu, Jun 15, 2017 at 5:06 AM, Nikita Popov <nikita.ppv@gmail.com> wrote:
> On Tue, Jun 13, 2017 at 8:23 AM, Remi Collet <remi@fedoraproject.org> wrote: >> All extensions in php-src are PHP 3.01 Licensed >> (libs may, of course, have different license) >> >> Is there any strong rule about this ? >> Or is it OK to have a BSD Licensed extension ? >> >> Context: see sodium PR > > I think we should allow BSD/MIT licenses, as they are compatible with and > less restrictive than the PHP license. TBH, the PHP license seems somewhat > dubious when applied to extensions, as most of the additional clauses are > simply not applicable (extensions do not bundle the Zend Engine and > extensions have no control over the PHP group or the PHP name). >
I agree that BSD/MIT being more permissive is probably fine as far as licensing goes. In fact, there are bundled libraries in ext/*/ which are (obviously) not PHP licensed, so drawing an arbitrary line at one point in ext as opposed to another is a bit... weird. Obviously we need to be very careful about *which* licenses are permitted, but BSD/MIT feel like no-brainers to me. -Sara Nit; I disagree with your second sentence. While the initial commit may not relate to anyone with any degree of control over the engine or core, it will inevitably be touched by those individuals over time. But that's just a digression since ultimately the PHP release is nothing without the engine and core, so the PHP licensed nature of those parts is sufficient.

Johannes Schlueter

9 years ago
On Do, 2017-06-15 at 08:29 -0400, Sara Golemon wrote:
> On Thu, Jun 15, 2017 at 5:06 AM, Nikita Popov <nikita.ppv@gmail.com> > wrote: > > > > On Tue, Jun 13, 2017 at 8:23 AM, Remi Collet <remi@fedoraproject.or > > g> wrote: > > > > > > All extensions in php-src are PHP 3.01 Licensed > > > (libs may, of course, have different license) > > > > > > Is there any strong rule about this ? > > > Or is it OK to have a BSD Licensed extension ? > > > > > > Context: see sodium PR > > I think we should allow BSD/MIT licenses, as they are compatible > > with and > > less restrictive than the PHP license. TBH, the PHP license seems > > somewhat > > dubious when applied to extensions, as most of the additional > > clauses are > > simply not applicable (extensions do not bundle the Zend Engine and > > extensions have no control over the PHP group or the PHP name). > > > I agree that BSD/MIT being more permissive is probably fine as far as > licensing goes. In fact, there are bundled libraries in ext/*/ which > are (obviously) not PHP licensed, so drawing an arbitrary line at one > point in ext as opposed to another is a bit... weird.  Obviously we > need to be very careful about *which* licenses are permitted, but > BSD/MIT feel like no-brainers to me.
There is a point for this: We copy and paste code between extensions. If different extensions use different copyrights doing this "correctly" becomes complicated.  If all PHP-related code is using PHP License and copyright by The PHP Group this becomes easier. Also mind that php-src extensions are our primary resource on how to use PHP extensions and "look how others are doing it" is a common strategy. Imagine sodium being the example for using some newly created PHP API. If that is copied into ext/foobar, foobar has to licensed with additional "Copyright (c) 2013-2017, Frank Denis", now somebody takes something from foobar and moves it to main/, now main/ has to add "Copyright (c) 2013-2017, Frank Denis, Copyright 2018-2019, John Doe" then suddenly all main/ consumers have to cite that copyright ...  Stuff like ext/date/lib is not PHP-specific and an independent module. Similar ext/sqlite/libsqlite or ext/gd/libgd. johannes

Johannes Schlueter

9 years ago
On Do, 2017-06-15 at 11:06 +0200, Nikita Popov wrote:
> On Tue, Jun 13, 2017 at 8:23 AM, Remi Collet <remi@fedoraproject.org> > wrote: > > > > > Hi, > > > > All extensions in php-src are PHP 3.01 Licensed > > (libs may, of course, have different license) > > > > Is there any strong rule about this ? > > Or is it OK to have a BSD Licensed extension ? > > > > Context: see sodium PR > > https://github.com/php/php-src/pull/2560 > > > > > > IMHO, make sense to have only PHP Licensed ext. > > > I think we should allow BSD/MIT licenses, as they are compatible with > and > less restrictive than the PHP license. TBH, the PHP license seems > somewhat > dubious when applied to extensions, as most of the additional clauses > are > simply not applicable (extensions do not bundle the Zend Engine and > extensions have no control over the PHP group or the PHP name). >
Mind: The PHP License[1]  doesn't talk about the Zend engine, but "PHP Software", "PHP Software" is, since PHP License 3.01 compared to PHP License 3.0 defined as PEAR, PECL and PHP on [2] The "this software includes the ZendEngine" thing in the PHP distribution's license file[3] is not part of the PHP License, but a requirement for the PHP product, which includes the Zend Engine product, which is licensed under the Zend Engine License[4]. According to the most legal interpretations I know (IANAL ... ask two lawyers, get three answers ...) a BSD-licensed extension bundled in PHP would be relicensed under PHP license "automatically" when being distributed as part of the PHP product. I however think it makes sense to license all bundled extensions as PHP license with copyright PHP Group as this simplifies moving code around (i.e. if a BSD licensed extension contains some nice macro which might be useful to put into main/ this is simpler from a stricter legal pov if it's the same license) johannes [1] http://php.net/license/3_01.txt [2] http://php.net/software.php [3] http://git.php.net/?p=php-src.git;a=blob;f=LICENSE;h=9964e0737cc9be 0521b056be697a5fbeb14d01ef;hb=refs/heads/master [4] http://git.php.net/?p=php-src.git;a=blob;f=Zend/LICENSE;h=8acb9af4f 8a589076f305c31501565a2cfe0f6ff;hb=refs/heads/master

Christopher Jones

9 years ago
On 15/6/17 10:34 pm, Johannes Schlüter wrote:
> On Do, 2017-06-15 at 11:06 +0200, Nikita Popov wrote: >> On Tue, Jun 13, 2017 at 8:23 AM, Remi Collet <remi@fedoraproject.org> >> wrote: >> >>> Hi, >>> >>> All extensions in php-src are PHP 3.01 Licensed >>> (libs may, of course, have different license) >>> >>> Is there any strong rule about this ? >>> Or is it OK to have a BSD Licensed extension ? >>> >>> Context: see sodium PR >>> https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_php_php-2Dsrc_pull_2560&d=DwIDaQ&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=lLpUdeB4xTiOOWD6yGzxPFv2SHvPzg3yLT7kvD-ZfyU&m=GT6MkgICJHeF19FAbAaTtuH4St0KJibc9P1oLj7395Y&s=VGZgqeH18gkOkITtpv0ZRNfFvmlvCHdsjJ13Zu2yIv4&e= >>> >>> >>> IMHO, make sense to have only PHP Licensed ext. >>> >> I think we should allow BSD/MIT licenses, as they are compatible with >> and >> less restrictive than the PHP license. TBH, the PHP license seems >> somewhat >> dubious when applied to extensions, as most of the additional clauses >> are >> simply not applicable (extensions do not bundle the Zend Engine and >> extensions have no control over the PHP group or the PHP name). >>
What about the Apache 2 license? I'd like to be able to include the ODPI-C library code [1] in PDO_OCI and/or OCI8. It is being used for Python cx_Oracle [2] and Node.js node-oracledb [3]. ODPI-C is under a dual license, one of which is Apache 2.
> Mind: The PHP License[1] doesn't talk about the Zend engine, but "PHP > Software", "PHP Software" is, since PHP License 3.01 compared to PHP > License 3.0 defined as PEAR, PECL and PHP on [2] > > The "this software includes the ZendEngine" thing in the PHP > distribution's license file[3] is not part of the PHP License, but a > requirement for the PHP product, which includes the Zend Engine > product, which is licensed under the Zend Engine License[4]. > > According to the most legal interpretations I know (IANAL ... ask two > lawyers, get three answers ...) a BSD-licensed extension bundled in PHP > would be relicensed under PHP license "automatically" when being > distributed as part of the PHP product.
IANAL-too, and haven't talked to one about this - but will one day.
> I however think it makes sense to license all bundled extensions as PHP > license with copyright PHP Group as this simplifies moving code around > (i.e. if a BSD licensed extension contains some nice macro which might > be useful to put into main/ this is simpler from a stricter legal pov > if it's the same license)
True. Chris [1] https://github.com/oracle/odpi [2] https://github.com/oracle/python-cx_Oracle [3] https://github.com/oracle/node-oracledb/tree/dev-2.0
> > johannes > > [1] https://urldefense.proofpoint.com/v2/url?u=http-3A__php.net_license_3-5F01.txt&d=DwIDaQ&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=lLpUdeB4xTiOOWD6yGzxPFv2SHvPzg3yLT7kvD-ZfyU&m=GT6MkgICJHeF19FAbAaTtuH4St0KJibc9P1oLj7395Y&s=7x6vjEasY6oe1GzH9OXDBE3pXyveWOz8ls3sXtwy1vw&e= > [2] https://urldefense.proofpoint.com/v2/url?u=http-3A__php.net_software.php&d=DwIDaQ&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=lLpUdeB4xTiOOWD6yGzxPFv2SHvPzg3yLT7kvD-ZfyU&m=GT6MkgICJHeF19FAbAaTtuH4St0KJibc9P1oLj7395Y&s=g1dWNiQpuE2RR-lswQmJXYYD_zwkAzYd1bVVRLXOVBw&e= > [3] https://urldefense.proofpoint.com/v2/url?u=http-3A__git.php.net_-3Fp-3Dphp-2Dsrc.git-3Ba-3Dblob-3Bf-3DLICENSE-3Bh-3D9964e0737cc9be&d=DwIDaQ&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=lLpUdeB4xTiOOWD6yGzxPFv2SHvPzg3yLT7kvD-ZfyU&m=GT6MkgICJHeF19FAbAaTtuH4St0KJibc9P1oLj7395Y&s=ZUqrUXKbNqC3ECQzQRCh6wTF8HWoWt18RInPHAMHcQM&e= > 0521b056be697a5fbeb14d01ef;hb=refs/heads/master > [4] https://urldefense.proofpoint.com/v2/url?u=http-3A__git.php.net_-3Fp-3Dphp-2Dsrc.git-3Ba-3Dblob-3Bf-3DZend_LICENSE-3Bh-3D8acb9af4f&d=DwIDaQ&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=lLpUdeB4xTiOOWD6yGzxPFv2SHvPzg3yLT7kvD-ZfyU&m=GT6MkgICJHeF19FAbAaTtuH4St0KJibc9P1oLj7395Y&s=3J0pO0pb7tkfrqMlrZeaJ729znnn2I8lQqGW_lIt51I&e= > 8a589076f305c31501565a2cfe0f6ff;hb=refs/heads/master >
-- http://twitter.com/ghrd

Scott Arciszewski

9 years ago
On Mon, Jun 19, 2017 at 10:03 PM, Christopher Jones < christopher.jones@oracle.com> wrote:
> > > On 15/6/17 10:34 pm, Johannes Schlüter wrote: > >> On Do, 2017-06-15 at 11:06 +0200, Nikita Popov wrote: >> >>> On Tue, Jun 13, 2017 at 8:23 AM, Remi Collet <remi@fedoraproject.org> >>> wrote: >>> >>> Hi, >>>> >>>> All extensions in php-src are PHP 3.01 Licensed >>>> (libs may, of course, have different license) >>>> >>>> Is there any strong rule about this ? >>>> Or is it OK to have a BSD Licensed extension ? >>>> >>>> Context: see sodium PR >>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__github. >>>> com_php_php-2Dsrc_pull_2560&d=DwIDaQ&c=RoP1YumCXCgaWHvlZYR8P >>>> QcxBKCX5YTpkKY057SbK10&r=lLpUdeB4xTiOOWD6yGzxPFv2SHvPzg3yLT7 >>>> kvD-ZfyU&m=GT6MkgICJHeF19FAbAaTtuH4St0KJibc9P1oLj7395Y&s=VGZ >>>> gqeH18gkOkITtpv0ZRNfFvmlvCHdsjJ13Zu2yIv4&e= >>>> >>>> >>>> IMHO, make sense to have only PHP Licensed ext. >>>> >>>> I think we should allow BSD/MIT licenses, as they are compatible with >>> and >>> less restrictive than the PHP license. TBH, the PHP license seems >>> somewhat >>> dubious when applied to extensions, as most of the additional clauses >>> are >>> simply not applicable (extensions do not bundle the Zend Engine and >>> extensions have no control over the PHP group or the PHP name). >>> >>> > What about the Apache 2 license? > > I'd like to be able to include the ODPI-C library code [1] in PDO_OCI > and/or OCI8. > It is being used for Python cx_Oracle [2] and Node.js node-oracledb [3]. > ODPI-C is under a dual license, one of which is Apache 2. > > Mind: The PHP License[1] doesn't talk about the Zend engine, but "PHP >> Software", "PHP Software" is, since PHP License 3.01 compared to PHP >> License 3.0 defined as PEAR, PECL and PHP on [2] >> >> The "this software includes the ZendEngine" thing in the PHP >> distribution's license file[3] is not part of the PHP License, but a >> requirement for the PHP product, which includes the Zend Engine >> product, which is licensed under the Zend Engine License[4]. >> >> According to the most legal interpretations I know (IANAL ... ask two >> lawyers, get three answers ...) a BSD-licensed extension bundled in PHP >> would be relicensed under PHP license "automatically" when being >> distributed as part of the PHP product. >> > > IANAL-too, and haven't talked to one about this - but will one day. > > I however think it makes sense to license all bundled extensions as PHP >> license with copyright PHP Group as this simplifies moving code around >> (i.e. if a BSD licensed extension contains some nice macro which might >> be useful to put into main/ this is simpler from a stricter legal pov >> if it's the same license) >> > > True. > > Chris > > [1] https://github.com/oracle/odpi > [2] https://github.com/oracle/python-cx_Oracle > [3] https://github.com/oracle/node-oracledb/tree/dev-2.0 > >> >> johannes >> >> [1] https://urldefense.proofpoint.com/v2/url?u=http-3A__php.net_ >> license_3-5F01.txt&d=DwIDaQ&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5Y >> TpkKY057SbK10&r=lLpUdeB4xTiOOWD6yGzxPFv2SHvPzg3yLT7kvD-ZfyU& >> m=GT6MkgICJHeF19FAbAaTtuH4St0KJibc9P1oLj7395Y&s=7x6vjEasY6oe >> 1GzH9OXDBE3pXyveWOz8ls3sXtwy1vw&e= >> [2] https://urldefense.proofpoint.com/v2/url?u=http-3A__php.net_ >> software.php&d=DwIDaQ&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY0 >> 57SbK10&r=lLpUdeB4xTiOOWD6yGzxPFv2SHvPzg3yLT7kvD-ZfyU&m=GT6M >> kgICJHeF19FAbAaTtuH4St0KJibc9P1oLj7395Y&s=g1dWNiQpuE2RR-lswQ >> mJXYYD_zwkAzYd1bVVRLXOVBw&e= >> [3] https://urldefense.proofpoint.com/v2/url?u=http-3A__git.php. >> net_-3Fp-3Dphp-2Dsrc.git-3Ba-3Dblob-3Bf-3DLICENSE-3Bh-3D9964 >> e0737cc9be&d=DwIDaQ&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057 >> SbK10&r=lLpUdeB4xTiOOWD6yGzxPFv2SHvPzg3yLT7kvD-ZfyU&m=GT6Mkg >> ICJHeF19FAbAaTtuH4St0KJibc9P1oLj7395Y&s=ZUqrUXKbNqC3ECQzQRCh >> 6wTF8HWoWt18RInPHAMHcQM&e= >> 0521b056be697a5fbeb14d01ef;hb=refs/heads/master >> [4] https://urldefense.proofpoint.com/v2/url?u=http-3A__git.php. >> net_-3Fp-3Dphp-2Dsrc.git-3Ba-3Dblob-3Bf-3DZend_LICENSE-3Bh-3 >> D8acb9af4f&d=DwIDaQ&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057 >> SbK10&r=lLpUdeB4xTiOOWD6yGzxPFv2SHvPzg3yLT7kvD-ZfyU&m=GT6Mkg >> ICJHeF19FAbAaTtuH4St0KJibc9P1oLj7395Y&s=3J0pO0pb7tkfrqMlrZea >> J729znnn2I8lQqGW_lIt51I&e= >> 8a589076f305c31501565a2cfe0f6ff;hb=refs/heads/master >> >> > -- > http://twitter.com/ghrd > > > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > >
​Hi all, Towards the end (currently, anyway) of the pull request discussion, a possible resolution emerges for ext/sodium: https://github.com/php/php-src/pull/2560#issuecomment-312452732 I've never dealt with licensing issues before, so I'm not sure what the process is myself. However, feel free to treat my contributions as CC0/WTFPL/Unlicense so that everyone can freely just relicense my contributions as whatever license without complication. You don't even need me to sign off on it. Just, have at it. Would it make sense to post an issue on the libsodium-php Github to ask the contributors if they consent to a relicense? Or should we track them down and email them individually? This is new territory for me, so I apologize if anything I said sounds stupid. Regards, Scott Arciszewski Chief Development Officer Paragon Initiative Enterprises <https://paragonie.com/>​

Scott Arciszewski

9 years ago
On Sun, Jul 2, 2017 at 12:51 PM, Scott Arciszewski <scott@paragonie.com> wrote:
> > ​Hi all, > > Towards the end (currently, anyway) of the pull request discussion, a > possible resolution emerges for ext/sodium: https://github.com/php/php- > src/pull/2560#issuecomment-312452732 > > I've never dealt with licensing issues before, so I'm not sure what the > process is myself. > > However, feel free to treat my contributions as CC0/WTFPL/Unlicense so > that everyone can freely just relicense my contributions as whatever > license without complication. You don't even need me to sign off on it. > Just, have at it. > > Would it make sense to post an issue on the libsodium-php Github to ask > the contributors if they consent to a relicense? Or should we track them > down and email them individually? > > This is new territory for me, so I apologize if anything I said sounds > stupid. > > Regards, > > Scott Arciszewski > Chief Development Officer > Paragon Initiative Enterprises <https://paragonie.com/>​ > >
​Hi again, I haven't received any direction for what to do here, so I opened this issue on the libsodium-php repo: https://github.com/jedisct1/libsodium-php/issues/127 If we get a full checklist of consent from every contributor, including Frank, that should be enough to unblock this pull request, no?​ Scott Arciszewski Chief Development Officer Paragon Initiative Enterprises <https://paragonie.com/>​

Sara Golemon

9 years ago
On Thu, Jul 6, 2017 at 4:17 PM, Scott Arciszewski <scott@paragonie.com> wrote:
> I haven't received any direction for what to do here, so I opened this > issue on the libsodium-php repo: > > https://github.com/jedisct1/libsodium-php/issues/127 > > If we get a full checklist of consent from every contributor, including > Frank, that should be enough to unblock this pull request, no? >
If the extension is relicensed to the PHP license and Copyright assigned to The PHP Group, then every problem goes away in the simplest and least uncertain way possible. If the above can't be done, we still have options. The BSD license currently on the extension is not, in and of itself, super problematic. The only issue which needs resolving in my mind is addressing the frontier between ext/sodium and the rest of php-src. Code migrating (in either direction) muddies the waters between these parts of the repo and I just don't know what the consequences of that are. Maybe they're nothing. I wanted to move that part of the discussion here in the interest of getting other stakeholders to comment. Particularly those who are formally members of "The PHP Group". Rasmus? Ze'ev? Andi? I think you three are the only ones in that category still active. -Sara

Fleshgrinder

9 years ago
On 6/13/2017 8:23 AM, Remi Collet wrote:
> Hi, > > All extensions in php-src are PHP 3.01 Licensed > (libs may, of course, have different license) > > Is there any strong rule about this ? > Or is it OK to have a BSD Licensed extension ? > > Context: see sodium PR > https://github.com/php/php-src/pull/2560 > > > IMHO, make sense to have only PHP Licensed ext. > > > > Remi >
We also include GNU stuff: https://github.com/php/php-src/blob/6053987bc27e8dede37f437193a5cad448f99bce/ext/mbstring/libmbfl/LICENSE I cannot tell what implications this has, and do not want to make any judgment regarding this issue.
-- Richard "Fleshgrinder" Fussenegger