[Buildroot] [PATCH] Allow PHP to compile ans link with berkeleydb 6

[Buildroot] [PATCH] Allow PHP to compile ans link with berkeleydb 6

[Jérôme Pouiller]

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

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).*
-- 
1.7.9.5

[Buildroot] [PATCH] Allow PHP to compile ans link with berkeleydb 6

[Thomas Petazzoni]

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
-- 
Thomas Petazzoni, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

[Buildroot] [PATCH] Allow PHP to compile ans link with berkeleydb 6

[Gustavo Zacarias]

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.

[Buildroot] [PATCH] Allow PHP to compile ans link with berkeleydb 6

[Thomas Petazzoni]

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
-- 
Thomas Petazzoni, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

[Buildroot] [PATCH] Allow PHP to compile ans link with berkeleydb 6

[Gustavo Zacarias]

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.

[Buildroot] [PATCH] Allow PHP to compile ans link with berkeleydb 6

[Thomas Petazzoni]

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
-- 
Thomas Petazzoni, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

[Buildroot] [PATCH] Allow PHP to compile ans link with berkeleydb 6

[Jérôme Pouiller]

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


-- 
J?r?me Pouiller, Sysmic
Embedded Linux specialist
http://www.sysmic.fr

[Buildroot] [PATCH] Allow PHP to compile ans link with berkeleydb 6

[Arnout Vandecappelle]

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
>


-- 
Arnout Vandecappelle                          arnout at mind be
Senior Embedded Software Architect            +32-16-286500
Essensium/Mind                                http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium           BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint:  7CB5 E4CC 6C2E EFD4 6E3D A754 F963 ECAB 2450 2F1F

[Buildroot] [PATCH] Allow PHP to compile ans link with berkeleydb 6

[Thomas Petazzoni]

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
-- 
Thomas Petazzoni, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

[Buildroot] [PATCH] Allow PHP to compile ans link with berkeleydb 6

[Arnout Vandecappelle]

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


-- 
Arnout Vandecappelle                          arnout at mind be
Senior Embedded Software Architect            +32-16-286500
Essensium/Mind                                http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium           BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint:  7CB5 E4CC 6C2E EFD4 6E3D A754 F963 ECAB 2450 2F1F

[Buildroot] [PATCH] Allow PHP to compile ans link with berkeleydb 6

[Thomas Petazzoni]

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
-- 
Thomas Petazzoni, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

[Buildroot] [PATCH] Allow PHP to compile ans link with berkeleydb 6

[Arnout Vandecappelle]

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


-- 
Arnout Vandecappelle                          arnout at mind be
Senior Embedded Software Architect            +32-16-286500
Essensium/Mind                                http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium           BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint:  7CB5 E4CC 6C2E EFD4 6E3D A754 F963 ECAB 2450 2F1F