httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Eli Marmor <>
Subject Re: Apache license and GZIP
Date Fri, 15 Oct 1999 01:38:27 GMT
Let me add my ideas to this discussion:

Currently, there are many modules/patches/add-ons and so on, which are
problematic to include in the standard distribution, because of either
their license (e.g. GPL), or crypto limitations in the US and some
other places, or because there is no 100% consensus as the rules demand
(e.g. EAPI), and so on. One wishing to build Apache with all the Good
Things, must collect various pieces from the Net, and enter a complex
process of dozens of steps, which is very hard, and prevents Apache to
gain even higher rates of popularity.

The possible solution: To have a secondary distribution of Apache,
located in a free place (i.e. without limiting crypto laws), with a
source tree that combines all the most used modules and add-ons (e.g.
Perl, mod_dav, EAPI(*)+mod_ssl+OpenSSL, zlib, PHP, JServ, etc.).
Instead of a multi step build process, there will be a one
"src/helpers/" automatic scipts that builds everything. Of
course, the generated executable should not be too big, because most of
the modules and the add-ons are dynamic. They even should not take any
space in the run-time memory, if they are configured to be disabled, so
there is no cost for the inclusion of almost anything in this source
tree. Only an "all in one Apache", built "out of the box".

There will not be any danger of dividing the development to two
threads, because this distribution will be based EXACTLY on the
original separated source trees, with no modifications (but only some
additional shell/perl scripts to allow an automatic build and
installation of the whole package).

The idea that I raise here, is already implemented in many other areas:
For example, operating systems, especially Linux, are collections of
many other packages, with many added values:

1. No need to fit versions to each other. When a specific package
   requires that another package will be present in version X and not
   Y, it is already done by the distribution maintainer or vendor. The
   best example for this is GNOME: When it is packaged in one package,
   its build is "Click and Forget". When it is collected manually, its
   build may take long days, and usually the result is a total failure.
2. Additional scripts for easy and/or better build and/or installation,
   without modifying the original code.
3. No need to collect stuff from dozens of places; Everything is
   packaged to one distro.
4. Sometimes, there are optimizations to help some packages to work
   better with some other packages.

I think that the success of Linux proved that this model is good.

(*) Contrary to the current status, where EAPI is a patch which is
applied into the Apache original files, this secondary distribution
will include already patched files, and this will be true to other
future patches too (though I don't think that the FP Server Extensions
are a good example...).

Thanks for the attention and patience ;-)
Eli Marmor

View raw message