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
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/2560IMHO, 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
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.
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
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/2560IMHO, 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
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 ?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
On Mon, Jun 19, 2017 at 10:03 PM, Christopher Jones <
christopher.jones@oracle.com> 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.0johannes
[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--
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/
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-312452732I'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/
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
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/2560IMHO, make sense to have only PHP Licensed ext.
Remi
We also include GNU stuff:
I cannot tell what implications this has, and do not want to make any
judgment regarding this issue.
--
Richard "Fleshgrinder" Fussenegger