httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject Re: libtool in APR.
Date Sat, 01 Apr 2000 21:41:08 GMT

I have done something now that we should have done initially.  I have
applied the second of these patches, and run the configure script.  This
creates a directory that looks to me as if it is protected by the GPL.  I
may be wrong about this, but here is how I read this.

There are two separate and distinct projects in this tree currntly.  APR
and Apache.  APR would require libltdl in order to load pre-compiled
modules.  Apache would use libtool to compile and link modules.  Here's
the problem.  All of the special exceptions say that if you include the
files as a part of another program that use libtool, then you can use
whatever license you wish.  However, in APR, we do not currently (and have
no plans to) use libtool to build our binaries.

This means that if we use libtool as it is currently being used in these
packages, we are using GPL'ed code.  Now, as I have said, IANAL, so I
could be completely wrong.  I would like somebody with more experience
with Licenses to look into this for me.



On Fri, 31 Mar 2000, Jon Travis wrote:

> wrote:
> > Okay,
> >
> > After reading the opinions expressed so far, here is my take and my plan
> > for the day.  :-)
> >
> > It looks like libtool is more than we need for loading dso's.  It is VERY
> > useful for compiling dso's however.  Seeing as how we have two projects
> > and two different dso problems, lets use libtool in one project and not in
> > the other.  Therefore:
> >
> > The dso directory is going to be removed from the build process, until it
> > is actually fixed, before the alpha today.  We will release the alpha
> > using the dso loading code from the Apache-2.0/src/os/foo tree today.
> >
> > After the alpha, we will change the dso directory to use the current
> > Apache code.  And turn on compiling it again.
> >
> > When dsotool is released (or before if somebody gets motivated to get the
> > code from Ralf), we'll take a closer look at what it provides and
> > determine at that point if we want to use it in APR to load dso's.
> >
> > If anybody disagrees with this, let me know.  Currently, I am
> > planning to remove the dso code from APR for today's alpha, because it
> > doesn't build cleanly without the second patch from Jon Travis which was
> > held up by this debate.  I would personally like to see Apache-2.0a2
> > compile cleanly and delay this decision.
> >
> > Ryan
> Ryan,
> I understand your opinion about wanting to get another 2.0 alpha
> out the door.  The main reason for my DSO patches was that I
> was trying to develop a module, and with the current state of
> Apache, it was not possible to work on it without butchering
> the Apache source tree.  (Does 2.0 yet support inclusion
> of static modules as libraries?)  This DSO patch solves that
> problem perfectly for me, and I was thinking that if anyone else
> wanted to do a lot of module work that this would be quite handy
> to them.
> I'd like to recognize an excellent points that Ralf has brought up:
> o)  dsotool may not be the be-all-end-all for the DSO loading,
> it currently exists in a lot of minds as the fix to all the
> problems.  Nobody really knows.  (this is my own paraphrase.;-))
> If a much nicer (cleaner) libtool patch would be accepted into
> the tree, I'd whip one up, no problemo.  It works, it allows
> people to work on DSOs in this 'limbo' stage, and it provides
> as an API with which we can change the backend later if we
> feel that Ralf can end world-hunger.. ;-)  Libltdl has always
> built very nice for me on all the platforms I've ever developed
> for -- it doesn't seem like much of a burden at all.
> -- Jon

Ryan Bloom               
406 29th St.
San Francisco, CA 94131

View raw message