You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@apr.apache.org by Garrett Rooney <ro...@electricjellyfish.net> on 2006/02/03 23:22:01 UTC
Re: svn commit: r374743 - /apr/apr/branches/1.2.x/STATUS
On 2/3/06, wrowe@apache.org <wr...@apache.org> wrote:
> --- apr/apr/branches/1.2.x/STATUS (original)
> +++ apr/apr/branches/1.2.x/STATUS Fri Feb 3 13:01:05 2006
> @@ -15,6 +15,10 @@
>
> RELEASE 1.2.x SHOWSTOPPERS:
>
> + * MUST invert default selection of GPL, Sleepcat, BDB licensed plug
> + in detection to default to off, following clarification of the
> + ASF license compatibility
> +
Umm, why is this being listed as a showstopper? The policy in
question is not yet public, is not yet final, and is not yet in place.
Even if it was in place, it has a built in timeline for projects to
get up to speed with it. There's no reason, as far as I can tell, for
us to be holding back any release at this point.
This should at least have been brought up on the dev list first before
throwing it into STATUS as if it had been decided on, IMO.
-garrett
Re: svn commit: r374743 - /apr/apr/branches/1.2.x/STATUS
Posted by Garrett Rooney <ro...@electricjellyfish.net>.
On 2/4/06, William A. Rowe, Jr. <wr...@rowe-clan.net> wrote:
> Looks good, +1 to commit to branches 0.9, 1.2 and trunk.
Committed and merged to both 0.9.x and 1.2.x.
> I see --with-gdbm=yes already does some sane looking for an obvious install
> path of gdmb.h etc, so the change should be mostly painless. An obvious note
> in CHANGES would be useful here for users who wish to continue configuring
> against gdbm.
Agreed, I added a note to CHANGES about it.
-garrett
Re: svn commit: r374743 - /apr/apr/branches/1.2.x/STATUS
Posted by Garrett Rooney <ro...@electricjellyfish.net>.
On 2/4/06, William A. Rowe, Jr. <wr...@rowe-clan.net> wrote:
> > Garrett Rooney wrote:
> >
> >> FWIW, here's a patch (to trunk) that handles the GDBM side of things,
> >> since it's like a 2 line change. Seems to work just fine here. I
> >> didn't do anything about BDB, since the BDB part of the configure
> >> scripts scare me...
>
> ROFL - I don't blame you (!) But it appears to me that axing lines 728
> and 729, the exception clause for APR_ARG_WITH([berkeley-db], [ ... is the
> correct solution there, too. Perhaps the docs should read 'path to library,
> yes for default search of expected locations, or no (default) to disable'.
The only question I had was if we should try to link against BDB 1.8
(the old version, still under a BSD style license) by default if we
can find it. If so, the logic gets more complex. I'll probably look
at this later tonight, but if someone else wants to deal with it I'd
be forever in their debt, as I HATE screwing around with autoconf...
-garrett
Re: svn commit: r374743 - /apr/apr/branches/1.2.x/STATUS
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
> Garrett Rooney wrote:
>
>> FWIW, here's a patch (to trunk) that handles the GDBM side of things,
>> since it's like a 2 line change. Seems to work just fine here. I
>> didn't do anything about BDB, since the BDB part of the configure
>> scripts scare me...
ROFL - I don't blame you (!) But it appears to me that axing lines 728
and 729, the exception clause for APR_ARG_WITH([berkeley-db], [ ... is the
correct solution there, too. Perhaps the docs should read 'path to library,
yes for default search of expected locations, or no (default) to disable'.
Bill
Re: svn commit: r374743 - /apr/apr/branches/1.2.x/STATUS
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
Looks good, +1 to commit to branches 0.9, 1.2 and trunk.
I see --with-gdbm=yes already does some sane looking for an obvious install
path of gdmb.h etc, so the change should be mostly painless. An obvious note
in CHANGES would be useful here for users who wish to continue configuring
against gdbm.
Bill
Garrett Rooney wrote:
> On 2/3/06, William A. Rowe, Jr. <wr...@rowe-clan.net> wrote:
>
>
>>It's a showstopper if we violate licensing terms, period. In fact a case
>>could be made to take down www.apache.org/dist/apr/ today. But I think that
>>the better solution is to immediately and agressively address this flagrent
>>stealth license now, and release a version that users and distributors clearly
>>are aware of any licensing impacts of their --with-xxx decisions.
>
>
> FWIW, here's a patch (to trunk) that handles the GDBM side of things,
> since it's like a 2 line change. Seems to work just fine here. I
> didn't do anything about BDB, since the BDB part of the configure
> scripts scare me...
>
> -garrett
>
>
> ------------------------------------------------------------------------
>
> Index: build/dbm.m4
> ===================================================================
> --- build/dbm.m4 (revision 374803)
> +++ build/dbm.m4 (working copy)
> @@ -607,6 +607,7 @@
> requested=default
> ])
>
> + dnl We don't pull in GDBM unless the user asks for it, since it's GPL
> AC_ARG_WITH([gdbm], [
> --with-gdbm=DIR specify GDBM location
> ], [
> @@ -626,9 +627,6 @@
> APR_ADDTO(APRUTIL_INCLUDES, [-I$withval/include])
> fi
> fi
> - ], [
> - apu_have_gdbm=0
> - AC_CHECK_HEADER(gdbm.h, AC_CHECK_LIB(gdbm, gdbm_open, [apu_have_gdbm=1]))
> ])
>
> AC_ARG_WITH([ndbm], [
Re: svn commit: r374743 - /apr/apr/branches/1.2.x/STATUS
Posted by Garrett Rooney <ro...@electricjellyfish.net>.
On 2/3/06, William A. Rowe, Jr. <wr...@rowe-clan.net> wrote:
> It's a showstopper if we violate licensing terms, period. In fact a case
> could be made to take down www.apache.org/dist/apr/ today. But I think that
> the better solution is to immediately and agressively address this flagrent
> stealth license now, and release a version that users and distributors clearly
> are aware of any licensing impacts of their --with-xxx decisions.
FWIW, here's a patch (to trunk) that handles the GDBM side of things,
since it's like a 2 line change. Seems to work just fine here. I
didn't do anything about BDB, since the BDB part of the configure
scripts scare me...
-garrett
Re: svn commit: r374743 - /apr/apr/branches/1.2.x/STATUS
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
Garrett Rooney wrote:
>
> On the other hand, it's probably a fairly reasonable change. I
> eagerly await your patch to reverse the default behavior of the GDBM
> detection code, since you seem to feel this is of critical importance,
> but I still don't think it's a showstopper.
Note that I did *not* showstopper any linkages to LGPL code. Those, too,
are likely to be covered under the new policy.
But LGPL detection, e.g. libiconv, does not polute our license in the same
manner as GDBM and Sleepycat DB.
It's a showstopper if we violate licensing terms, period. In fact a case
could be made to take down www.apache.org/dist/apr/ today. But I think that
the better solution is to immediately and agressively address this flagrent
stealth license now, and release a version that users and distributors clearly
are aware of any licensing impacts of their --with-xxx decisions.
Bill
Re: svn commit: r374743 - /apr/apr/branches/1.2.x/STATUS
Posted by Garrett Rooney <ro...@electricjellyfish.net>.
On 2/3/06, William A. Rowe, Jr. <wr...@rowe-clan.net> wrote:
> Garrett Rooney wrote:
> > On 2/3/06, wrowe@apache.org <wr...@apache.org> wrote:
> >
> >
> >>--- apr/apr/branches/1.2.x/STATUS (original)
> >>+++ apr/apr/branches/1.2.x/STATUS Fri Feb 3 13:01:05 2006
> >>@@ -15,6 +15,10 @@
> >>
> >> RELEASE 1.2.x SHOWSTOPPERS:
> >>
> >>+ * MUST invert default selection of GPL, Sleepcat, BDB licensed plug
> >>+ in detection to default to off, following clarification of the
> >>+ ASF license compatibility
> >
> > Umm, why is this being listed as a showstopper? The policy in
> > question is not yet public, is not yet final, and is not yet in place.
> > Even if it was in place, it has a built in timeline for projects to
> > get up to speed with it. There's no reason, as far as I can tell, for
> > us to be holding back any release at this point.
>
> GPL was an issue when this code was first introduced. Only now those
> of us vocal against auto-detection have a soon-to-be policy to point at.
>
> Automerging into GPL code infects APR, you don't need policy to tell you
> that. Ergo, anytime someone -wants- to ./configure --with-gdbm, they are
> creating a GPL APR. No way legally to avoid that polution.
No argument there, I agree this is what we need to do going forward.
> > This should at least have been brought up on the dev list first before
> > throwing it into STATUS as if it had been decided on, IMO.
>
> It's not a question of a decision; it's a simple legal truth. Compiling
> against gdbm creates GPL APR, which in turn creates a GPL httpd.
I'm not going to argue about that, nobody seems to disagree that is
indeed what happens, what I'm arguing about is you taking it upon
yourself to decide that this project needs to follow a policy that has
not even been completed yet. Now there's nothing that says we can't,
independent of any such policy, decide to do this, but that's a
decision the group needs to make, not one that you get to dictate to
it.
> There is no problem with a user -explicitly- choosing a GPL version of our
> package. But there is a problem when it's silently propogated without any
> proper LICENSE or NOTICE files.
>
> The fix is simple, --without-gdbm goes away (or becomes a noop). --with-gdbm
> becomes the current behavior (find the thing somewhere). --with-gdbm=/foo
> remains as today, just point to it.
>
> Then there is no way they can end up with stealth terms on APR because the
> builder chose license. But at least we are not embedding the GPL into our
> library without the user's knowledge.
>
> Any additional questions?
Why is this all of a sudden a show-stoppingly bad situation. The
current state of things is somewhat unwise, I agree, but it's a
problem that's been there as long as that code exists. Considering
you're basing this on a proposed policy that isn't even public yet,
I'm unconvinced that it's something that should halt a release.
On the other hand, it's probably a fairly reasonable change. I
eagerly await your patch to reverse the default behavior of the GDBM
detection code, since you seem to feel this is of critical importance,
but I still don't think it's a showstopper.
-garrett
Re: svn commit: r374743 - /apr/apr/branches/1.2.x/STATUS
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
Garrett Rooney wrote:
> On 2/3/06, wrowe@apache.org <wr...@apache.org> wrote:
>
>
>>--- apr/apr/branches/1.2.x/STATUS (original)
>>+++ apr/apr/branches/1.2.x/STATUS Fri Feb 3 13:01:05 2006
>>@@ -15,6 +15,10 @@
>>
>> RELEASE 1.2.x SHOWSTOPPERS:
>>
>>+ * MUST invert default selection of GPL, Sleepcat, BDB licensed plug
>>+ in detection to default to off, following clarification of the
>>+ ASF license compatibility
>
> Umm, why is this being listed as a showstopper? The policy in
> question is not yet public, is not yet final, and is not yet in place.
> Even if it was in place, it has a built in timeline for projects to
> get up to speed with it. There's no reason, as far as I can tell, for
> us to be holding back any release at this point.
GPL was an issue when this code was first introduced. Only now those
of us vocal against auto-detection have a soon-to-be policy to point at.
Automerging into GPL code infects APR, you don't need policy to tell you
that. Ergo, anytime someone -wants- to ./configure --with-gdbm, they are
creating a GPL APR. No way legally to avoid that polution.
> This should at least have been brought up on the dev list first before
> throwing it into STATUS as if it had been decided on, IMO.
It's not a question of a decision; it's a simple legal truth. Compiling
against gdbm creates GPL APR, which in turn creates a GPL httpd.
There is no problem with a user -explicitly- choosing a GPL version of our
package. But there is a problem when it's silently propogated without any
proper LICENSE or NOTICE files.
The fix is simple, --without-gdbm goes away (or becomes a noop). --with-gdbm
becomes the current behavior (find the thing somewhere). --with-gdbm=/foo
remains as today, just point to it.
Then there is no way they can end up with stealth terms on APR because the
builder chose license. But at least we are not embedding the GPL into our
library without the user's knowledge.
Any additional questions?
Bill