httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ralf S. Engelschall" <...@engelschall.com>
Subject Re: apache2-ng7
Date Thu, 06 Jan 2000 09:18:59 GMT

In article <Pine.LNX.4.10.10001051516160.412-100000@nebula.lyra.org> you wrote:

> [...]
> shtool is a different matter. We already have the needed functionality in
> our helpers/ directory. To switch over to shtool means that we must assume
> the burden of the GPL license, with no incremental benefit in
> functionality over our existing codebase. So why should we?

For the same reason we're using libtool, of course. We also have all the
functionality of libtool in our src/Configure, of course. So, Apache
2.0 the same way could avoid libtool et all. But it's not reasonable
to do because libtool is actively maintained and enhanced and better polished
for creating DSOs (yes, I know, libtool has a few faults, but certainly less
faults than our stuff). The same applies to shtool, which is also more
polished and fixed than src/helpers/*. So, it's especially a maintainance
point.

Compare this: Why do people often upgrade to the latest Apache version?
The _functionality_ which 99% of the people need is already present
since Apache 0.8.4. So are they crazy? No, they see the long-term
benefit of receiving bugfixes, small enhancements, etc with their
continued upgrades. That's why they try to be more or less up to date
all the time (or at least from time to time on a regular basis). The
same applies to tools like libtool or shtool. Sure, Apache 2.0 already
has this functionality. But just functionality is useless if you have to
bash and maintain it yourself all the time while at the same time you could
get it without efforts, because others already do the job for you. So if
license issues are not the problem, why shouldn't one go the short-term way?

Hey, instead of Autoconf you also could even just use AT&T's good old
and nice "iffe" script (you can find it for instance in Sfio and it's
totally free and works fine). It provides 95% of Autoconf functionality
in just a single 30KB script. But people use Autoconf. Why? Because
Autoconf is a central maintained package and with every Autoconf release
we get the new features, bugfixes and polishing for free without having
to spend own efforts. So, if you're saying the ASF is lazy, fine. But
then I'm wondering why such an egg-dance is done about those tools.
Because if the ASF would be really lazy, we would not discuss such
issues. Instead the ASF would be happy to use libtool, shtool, etc.

> In essence: we don't really have a problem with the license itself, but
> that the cost of that license has no incremental benefit for us (in
> regards to shtool; auto* and libtool do have benefit).

Actually one can argue that libtool has also no short-term incremental
benefit IMHO, because the functionality and DSO knowledge is already
present in src/Configure. But, as for shtool, one has to see the
long-term incremental benefit, of course.

Hmmm.... I'm really wondering why it has to be such complicated all
the time inside the ASF... Actually I think, it's not the ASF, it's
just a few of us which always want to have a problem with anything
non-Apache-licensed as a matter of principle. So, please stop those
egg-dances. Instead..

a) either finally create now an "ASF footool" out of src/helpers/*
   and use this for the ASF's sake and forever and stop complaining
   about other tools or...

b) stick with src/helpers/* forever and accept that people complain
   about the fact that this might be unreasonable or..

c) use the other tools like libtool, shtool, etc. and stop complaining
   about them just because they cannot be re-licensed under the Apache
   license.

I personally can accept a), think b) is silly and would appreciate c), of
course.  Let us finally make a group decision and be happy, but let us stop
discussing the same topic over and over, please. We just walk in a cycle here
every time...

Greetings,
                                       Ralf S. Engelschall
                                       rse@engelschall.com
                                       www.engelschall.com

Mime
View raw message