On Wed, 4 Apr 2001, Richard Braakman wrote:
> Hmm. In /usr/share/doc/apache/copyright there is this clause:
>
> 5. Products derived from this software may not be called "Apache"
> nor may "Apache" appear in their names without prior written
> permission of the Apache Group.
>
> This seems to be a new clause; it wasn't there the last time I
> looked (which was a while ago).
I am pretty sure that such a clause has always been a part of the Apache
licenses. The intent is pretty simple - we don't want people calling
their commercial derivatives "Apache++", "ApachePro", etc.
Only recently did we realize that, technically, this affected people who
released their own packages of Apache. From one perspective, this is
unfair - this is "just" a repackaging. But from another perspective,
keeping the same name means that the Apache developers are blamed when
things go wrong. And in fact, we've had to deal with lots of reports of
bugs that show up in the various RPM's that Red Hat and Suse distribute,
though they finally got some sanity and that has died down.
So, one thing the Apache developers have considered doing is coming up
with a list of prereq's that, if satisfied, a product could carry the name
Apache. This is tricky ground, though, because you know some corporate
type is going to look for loopholes in that definition so that can legally
meet the requirements and still call their tool "ApachePro".
So until such a perfect document can be described, I think there are two
possibilities:
a) The Debian maintainers for Apache should join the appropriate
developers lists, and volunteer to create .deb packages for Apache that we
can distribute from apache.org. Those packages can then be distributed
from debian.org as well, carrying the same name, since they're the same
file. I strongly recommend this approach.
b) The Debian maintainers for Apache could email [EMAIL PROTECTED] asking
for permission, as the license suggests. I don't recommend this
direction, because then it would cause us to have to define what it is
we're agreeing to, etc... it could get messy. Though the consensus would
probably be, Debian's a reputable group, so let them do it. I see the
concern about issue #8 in the DFSG - I think that's not relevant, because
the original license stands and is non-Debian-specific.
The reason I recommend a) is because:
> The Debian package of apache is clearly a derived product -- it
> has 600 kilobytes of diffs, including patches to core Apache files.
Wow! What *are* those diffs? Has anyone contributed them to Apache? Why
not? Note that we have a pretty modular installation configuration
mechanism, so there's no reason that Debian-specific installation dirs or
other settings can't be made a part of our code. Ideally, we work
creating .deb files into our release process, so that a .deb is created
as a side-effect of doing a release (or soon after).
Comments?
Brian
