| Message ID | 1381146130-8575-1-git-send-email-jezz@sysmic.org |
|---|---|
| State | Superseded |
| Headers | show |
Dear Jérôme Pouiller, On Mon, 7 Oct 2013 13:42:10 +0200, Jérôme Pouiller wrote: > Add patch from : > https://bugs.php.net/patch-display.php?bug_id=65426&patch=db6.patch&revision=1376033083&download=1 > > Notice this patch was not applied by upstream because of licence > issue with berkeleydb 6. Linking with berkeleydb 6 may force user > to publish patch applyed to php. > > Signed-off-by: Jérôme Pouiller <jezz@sysmic.org> This looks problematic to me. PHP is licensed under the "PHP license", which according to http://en.wikipedia.org/wiki/PHP_License is incompatible with the GPL (and therefore I assume with the AGPL, which is the new license of BerkeleyDB). Therefore, linking PHP with BerkeleyDB version 6 creates a PHP binary that cannot legally be distributed. If this analysis is correct, I'd suggest one of the following options: * Drop the support for BerkeleyDB support in PHP. * Add a berkeleydb5 package that packages the last known non-AGPL version of BerkeleyDB, and use that for PHP. Considering how useful BerkeleyDB can be with PHP, I'm suggesting the first option. Best regards, Thomas
On 10/07/2013 08:57 AM, Thomas Petazzoni wrote: > Therefore, linking PHP with BerkeleyDB version 6 creates a PHP binary > that cannot legally be distributed. > > If this analysis is correct, I'd suggest one of the following options: > > * Drop the support for BerkeleyDB support in PHP. > > * Add a berkeleydb5 package that packages the last known non-AGPL > version of BerkeleyDB, and use that for PHP. > > Considering how useful BerkeleyDB can be with PHP, I'm suggesting the > first option. You mean the second option right? Otherwise you're conflicting with yourself ;) Regards.
Dear Gustavo Zacarias, On Mon, 07 Oct 2013 09:23:59 -0300, Gustavo Zacarias wrote: > On 10/07/2013 08:57 AM, Thomas Petazzoni wrote: > > Therefore, linking PHP with BerkeleyDB version 6 creates a PHP binary > > that cannot legally be distributed. > > > > If this analysis is correct, I'd suggest one of the following options: > > > > * Drop the support for BerkeleyDB support in PHP. > > > > * Add a berkeleydb5 package that packages the last known non-AGPL > > version of BerkeleyDB, and use that for PHP. > > > > Considering how useful BerkeleyDB can be with PHP, I'm suggesting the > > first option. > > You mean the second option right? > Otherwise you're conflicting with yourself ;) Sorry, I forgot to add a smiley or something. To be "how useful BerkleyDB can be with PHP" was ironic, so I was actually meaning that I don't think PHP+BerkeleyDB is so useful, so that to me, the first option is perfectly acceptable. Thomas
On 10/07/2013 09:26 AM, Thomas Petazzoni wrote: > Sorry, I forgot to add a smiley or something. To be "how useful > BerkleyDB can be with PHP" was ironic, so I was actually meaning that I > don't think PHP+BerkeleyDB is so useful, so that to me, the first > option is perfectly acceptable. Seems to be useful to Jerome maybe since he cared about fixing it. That being said the license is rotten and not only for PHP, we should just stick away from bdb6 IMHO. Regards.
Dear Gustavo Zacarias, On Mon, 07 Oct 2013 09:30:16 -0300, Gustavo Zacarias wrote: > On 10/07/2013 09:26 AM, Thomas Petazzoni wrote: > > > Sorry, I forgot to add a smiley or something. To be "how useful > > BerkleyDB can be with PHP" was ironic, so I was actually meaning that I > > don't think PHP+BerkeleyDB is so useful, so that to me, the first > > option is perfectly acceptable. > > Seems to be useful to Jerome maybe since he cared about fixing it. > That being said the license is rotten and not only for PHP, we should > just stick away from bdb6 IMHO. Ok, so as discussed on IRC, my proposal would be: * Downgrade the berkeleydb package to the last known non-AGPL version (i.e essentially revert commit 4c478de2e76ffc1d0a6dc413475307fd44a0a595). This way, all existing packages in Buildroot that rely on berkeleydb continue to work with no change, and don't create a legal issue. Add a comment in the berkeleydb.mk file that explains why it shouldn't be bumped to v6 of the project. * If someone cares, integrate an additional berkeleydb6 package that packages the v6 of berkeleydb under AGPL. Jérôme, are you interested in doing such work? Best regards, Thomas
On Monday 07 October 2013 14:57:34 Thomas Petazzoni wrote: [...] > Ok, so as discussed on IRC, my proposal would be: > > * Downgrade the berkeleydb package to the last known non-AGPL version > (i.e essentially revert commit > 4c478de2e76ffc1d0a6dc413475307fd44a0a595). This way, all existing > packages in Buildroot that rely on berkeleydb continue to work with > no change, and don't create a legal issue. Add a comment in the > berkeleydb.mk file that explains why it shouldn't be bumped to v6 of > the project. > > * If someone cares, integrate an additional berkeleydb6 package that > packages the v6 of berkeleydb under AGPL. > > Jérôme, are you interested in doing such work? I don't care of version of berkeleydb. But, I can send revert commit :-)
On 10/07/13 14:57, Thomas Petazzoni wrote: > Dear Gustavo Zacarias, > > On Mon, 07 Oct 2013 09:30:16 -0300, Gustavo Zacarias wrote: >> On 10/07/2013 09:26 AM, Thomas Petazzoni wrote: >> >>> Sorry, I forgot to add a smiley or something. To be "how useful >>> BerkleyDB can be with PHP" was ironic, so I was actually meaning that I >>> don't think PHP+BerkeleyDB is so useful, so that to me, the first >>> option is perfectly acceptable. >> >> Seems to be useful to Jerome maybe since he cared about fixing it. >> That being said the license is rotten and not only for PHP, we should >> just stick away from bdb6 IMHO. > > Ok, so as discussed on IRC, my proposal would be: > > * Downgrade the berkeleydb package to the last known non-AGPL version > (i.e essentially revert commit > 4c478de2e76ffc1d0a6dc413475307fd44a0a595). This way, all existing > packages in Buildroot that rely on berkeleydb continue to work with > no change, and don't create a legal issue. Add a comment in the > berkeleydb.mk file that explains why it shouldn't be bumped to v6 of > the project. > > * If someone cares, integrate an additional berkeleydb6 package that > packages the v6 of berkeleydb under AGPL. I didn't follow the conversation on IRC, but IMHO this proposal has important political implications. With this change, we are taking a stand: non-copyleft software should be the default. So in my opinion, we should instead make the default berkeleydb v6 and add a berkeleydb5 package for PHP. I took a quick look at which other packages are using berkeleydb. Most of them are compatible with GPL. netatalk: GPLv2+ -> compatible (note that _LICENSE is missing) perl: Aristic is not compatible, but GPLv1+ is (note that _LICENSE is wrong) python: PSF license v2 is compatible ruby: Ruby license is probably incompatible, but BSD-2c is (note that _LICENSE is wrong). Unfortunately, there are also a few incompatible files in the ruby distribution. Footnote: except for python, none of the licenses above are actually correctly defined in buildroot. This worries me... Regards, Arnout > Jérôme, are you interested in doing such work? > > Best regards, > > Thomas >
Dear Arnout Vandecappelle, On Tue, 08 Oct 2013 09:20:20 +0200, Arnout Vandecappelle wrote: > I didn't follow the conversation on IRC, but IMHO this proposal has > important political implications. With this change, we are taking a > stand: non-copyleft software should be the default. So in my opinion, > we should instead make the default berkeleydb v6 and add a > berkeleydb5 package for PHP. This solution is also fine with me. In the mean time, I still believe reverting the patch that bumps to v6 is for the moment the best action to take, until someone steps up to make the change to berkeleydb v6. However, AGPLv3+ (the new license of berkeleydb) is a fairly strong license, so I'm quite sure a number of embedded system markers would be interested in having the ability to build Python, or Perl, against a non-strongly-copyleft licensed version of berkeleydb. > netatalk: GPLv2+ -> compatible (note that _LICENSE is missing) > perl: Aristic is not compatible, but GPLv1+ is (note that _LICENSE is > wrong) But aren't all Perl modules licensed under the Artistic license? Not sure if it can cause some problems with berkeleydb being AGPLv3+, though. > python: PSF license v2 is compatible > ruby: Ruby license is probably incompatible, but BSD-2c is (note that > _LICENSE is wrong). Unfortunately, there are also a few incompatible > files in the ruby distribution. > > Footnote: except for python, none of the licenses above are > actually correctly defined in buildroot. This worries me... Well, licensing information is tricky to get right. I believe the kind of review you made is typically what makes the licensing information progressively better. Best regards, Thomas
On 10/08/13 10:01, Thomas Petazzoni wrote: > Dear Arnout Vandecappelle, > > On Tue, 08 Oct 2013 09:20:20 +0200, Arnout Vandecappelle wrote: > >> I didn't follow the conversation on IRC, but IMHO this proposal has >> important political implications. With this change, we are taking a >> stand: non-copyleft software should be the default. So in my opinion, >> we should instead make the default berkeleydb v6 and add a >> berkeleydb5 package for PHP. > > This solution is also fine with me. In the mean time, I still believe > reverting the patch that bumps to v6 is for the moment the best action > to take, until someone steps up to make the change to berkeleydb v6. > > However, AGPLv3+ (the new license of berkeleydb) is a fairly strong > license, so I'm quite sure a number of embedded system markers would be > interested in having the ability to build Python, or Perl, against a > non-strongly-copyleft licensed version of berkeleydb. Indeed, I think it may be a good idea to offer the user the possibility to use a non-copyleft version. But that's something completely different than forcing the user to use an old version just because the current one has strong copyleft... BTW for the typical embedded use cases, AGPL is hardly stronger than GPL. The "remote user" is typically the owner of the embedded device so the rights granted under GPL already apply. >> netatalk: GPLv2+ -> compatible (note that _LICENSE is missing) >> perl: Aristic is not compatible, but GPLv1+ is (note that _LICENSE is >> wrong) > > But aren't all Perl modules licensed under the Artistic license? Not > sure if it can cause some problems with berkeleydb being AGPLv3+, > though. I haven't checked everything, but the ones I looked at either specify "GPL or Artistic", or "under the same terms as Perl". >> python: PSF license v2 is compatible >> ruby: Ruby license is probably incompatible, but BSD-2c is (note that >> _LICENSE is wrong). Unfortunately, there are also a few incompatible >> files in the ruby distribution. >> >> Footnote: except for python, none of the licenses above are >> actually correctly defined in buildroot. This worries me... > > Well, licensing information is tricky to get right. I believe the kind > of review you made is typically what makes the licensing information > progressively better. You're saying I should produce patches, right? :-) Regards, Arnout
Dear Arnout Vandecappelle, On Tue, 08 Oct 2013 19:16:09 +0200, Arnout Vandecappelle wrote: > > However, AGPLv3+ (the new license of berkeleydb) is a fairly strong > > license, so I'm quite sure a number of embedded system markers would be > > interested in having the ability to build Python, or Perl, against a > > non-strongly-copyleft licensed version of berkeleydb. > > Indeed, I think it may be a good idea to offer the user the possibility > to use a non-copyleft version. But that's something completely different > than forcing the user to use an old version just because the current one > has strong copyleft... True. But offering a choice between two versions is always complicated, because we're not sure the new version will remain API compatible with the old version. And remember that randpackageconfig is not capable of randomizing 'choices' in Kconfig, so the autobuilders are only testing the default value of all the choices we have in Buildroot. > BTW for the typical embedded use cases, AGPL is hardly stronger than > GPL. The "remote user" is typically the owner of the embedded device so > the rights granted under GPL already apply. It's not really the A in front of GPL that causes the problem in AGPL, but the v3 at the end of it. For consumer devices, the v3 requires that the end user must be given the physical possibility of running a modified version of the software under (A)GPLv3. I'm not saying it's useless, on the contrary, but it's quite a significant change compared to the requirement of GPLv2. > >> netatalk: GPLv2+ -> compatible (note that _LICENSE is missing) > >> perl: Aristic is not compatible, but GPLv1+ is (note that _LICENSE is > >> wrong) > > > > But aren't all Perl modules licensed under the Artistic license? Not > > sure if it can cause some problems with berkeleydb being AGPLv3+, > > though. > > I haven't checked everything, but the ones I looked at either specify > "GPL or Artistic", or "under the same terms as Perl". Ok. > >> python: PSF license v2 is compatible > >> ruby: Ruby license is probably incompatible, but BSD-2c is (note that > >> _LICENSE is wrong). Unfortunately, there are also a few incompatible > >> files in the ruby distribution. > >> > >> Footnote: except for python, none of the licenses above are > >> actually correctly defined in buildroot. This worries me... > > > > Well, licensing information is tricky to get right. I believe the kind > > of review you made is typically what makes the licensing information > > progressively better. > > You're saying I should produce patches, right? :-) That's one way of reading what I said, which obviously, would be the best thing. But if that doesn't happen, the simple fact that you mentioned those licensing issues is likely to encourage someone to do the corresponding patches. Best regards, Thomas
On 10/08/13 20:09, Thomas Petazzoni wrote: > Dear Arnout Vandecappelle, > > On Tue, 08 Oct 2013 19:16:09 +0200, Arnout Vandecappelle wrote: [snip] >> You're saying I should produce patches, right? :-) > > That's one way of reading what I said, which obviously, would be the > best thing. But if that doesn't happen, the simple fact that you > mentioned those licensing issues is likely to encourage someone to do > the corresponding patches. Darn, I already sent the patches before reading this :-) Regards, Arnout
diff --git a/package/php/php-db6.patch b/package/php/php-db6.patch new file mode 100644 index 0000000..e28e715 --- /dev/null +++ b/package/php/php-db6.patch @@ -0,0 +1,70 @@ +Allow PHP to compile ans link with berkeleydb 6 + +Copied from: + https://bugs.php.net/patch-display.php?bug_id=65426&patch=db6.patch&revision=1376033083&download=1 + +Notice this patch iwas not applied by upstream because of licence +problem with berkeleydb 6. Linking with berkeleydb 6 may force you +to publish patch applyed to php. + +Signed-off-by: Jérôme Pouiller <jezz@sysmic.org> + +--- a/configure 2013-07-03 08:16:15.000000000 +0200 ++++ b/configure 2013-08-07 19:19:16.797273766 +0200 +@@ -42409,7 +42409,7 @@ + /* end confdefs.h. */ + + #include "$THIS_INCLUDE" +-#if DB_VERSION_MAJOR == 4 || (4 == 4 && DB_VERSION_MAJOR == 5) ++#if DB_VERSION_MAJOR == 4 || (4 == 4 && DB_VERSION_MAJOR >= 5) + yes + #endif + +@@ -42785,7 +42785,7 @@ + /* end confdefs.h. */ + + #include "$THIS_INCLUDE" +-#if DB_VERSION_MAJOR == 3 || (3 == 4 && DB_VERSION_MAJOR == 5) ++#if DB_VERSION_MAJOR == 3 || (3 == 4 && DB_VERSION_MAJOR >= 5) + yes + #endif + +@@ -43161,7 +43161,7 @@ + /* end confdefs.h. */ + + #include "$THIS_INCLUDE" +-#if DB_VERSION_MAJOR == 2 || (2 == 4 && DB_VERSION_MAJOR == 5) ++#if DB_VERSION_MAJOR == 2 || (2 == 4 && DB_VERSION_MAJOR >= 5) + yes + #endif + +--- a/ext/dba/config.m4 2013-07-03 08:10:53.000000000 +0200 ++++ b/ext/dba/config.m4 2013-08-07 19:18:55.774448348 +0200 +@@ -245,7 +245,7 @@ + ],[ + AC_EGREP_CPP(yes,[ + #include "$THIS_INCLUDE" +-#if DB_VERSION_MAJOR == $1 || ($1 == 4 && DB_VERSION_MAJOR == 5) ++#if DB_VERSION_MAJOR == $1 || ($1 == 4 && DB_VERSION_MAJOR >= 5) + yes + #endif + ],[ +--- a/ext/dba/dba_db4.c 2013-07-03 08:10:53.000000000 +0200 ++++ b/ext/dba/dba_db4.c 2013-08-07 19:19:04.827562638 +0200 +@@ -44,7 +44,7 @@ + { + TSRMLS_FETCH(); + +-#if (DB_VERSION_MAJOR == 5 || (DB_VERSION_MAJOR == 4 && DB_VERSION_MINOR == 8)) ++#if (DB_VERSION_MAJOR >= 5 || (DB_VERSION_MAJOR == 4 && DB_VERSION_MINOR == 8)) + /* Bug 51086, Berkeley DB 4.8.26 */ + /* This code suppresses a BDB 4.8+ error message, thus keeping PHP test compatibility */ + { +--- a/ext/dba/tests/dba_db4_handlers.phpt 2013-07-03 08:10:53.000000000 +0200 ++++ b/ext/dba/tests/dba_db4_handlers.phpt 2013-08-07 20:39:34.640194224 +0200 +@@ -47,4 +47,4 @@ + Test 1 + Success: db4 enabled + Test 2 - full info +-.*Berkeley DB (4|5).* ++.*Berkeley DB (4|5|6).*
Add patch from : https://bugs.php.net/patch-display.php?bug_id=65426&patch=db6.patch&revision=1376033083&download=1 Notice this patch was not applied by upstream because of licence issue with berkeleydb 6. Linking with berkeleydb 6 may force user to publish patch applyed to php. Signed-off-by: Jérôme Pouiller <jezz@sysmic.org> --- package/php/php-db6.patch | 70 +++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 70 insertions(+) create mode 100644 package/php/php-db6.patch