apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Garrett Rooney <roo...@electricjellyfish.net>
Subject Re: svn commit: r374743 - /apr/apr/branches/1.2.x/STATUS
Date Sat, 04 Feb 2006 00:50:14 GMT
On 2/3/06, William A. Rowe, Jr. <wrowe@rowe-clan.net> wrote:
> Garrett Rooney wrote:
> > On 2/3/06, wrowe@apache.org <wrowe@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

Mime
View raw message