Re: Libapache-mod-backhand: load balancing Apache requests.
On Thu, 5 Apr 2001, Richard Braakman wrote:
> On Wed, Apr 04, 2001 at 01:26:13PM -0700, Brian Behlendorf wrote:
> > 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.
>
> I think there was an earlier version that looked like this:
[5-clause license removed]
You're right. Searching back, I see in 1998 we added that clause about
naming - you can see the diff here:
http://www.apache.org/websrc/viewcvs.cgi/apache-1.3/LICENSE
Specifically, rev 1.9. I'd have to go dig up the archives to find out
exactly what the situation was that caused us to get concerned about this,
I believe it was a certain degree of paranoia about "not allowing to
happen to Apache what happened to Linux" name-wise, since that was around
the time IBM started getting interested in Apache.
It's been brought up multiple times this was technically an issue for
people building packages, but we felt it wasn't important since we clearly
weren't going to go after them, or something. That's probably not enough
these days; a document that explains the conditions for repackaging that
can be called Apache would probably be good. If anyone has written such a
doc or has ideas around that, email me.
> > 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".
>
> This approach would be similar to TeX, I think, which has a detailed
> compatibility test that all implementations must pass in order to
> call themselves TeX.
>
> Creating such a test would be a lot of work if you don't already
> have one.
Yes, I'm not thinking of a compatibility test suite. I'm thinking of
things like "All modifications must be clearly itemized in a file called
MODIFICATIONS at the root level" and "The place to report errors or bugs
must not be an apache.org address, and must be clearly indicated in the
README or end-user docs", stuff like that. Stuff that addresses the few
sources of pain it causes us when people release broken packages.
> > 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.
>
> Ah, this is an alternative I hadn't thought of. It has some problems
> from Debian's perspective, though, mainly related to the fact that most
> Debian developers will not be part of it. For example, what happens
> if our Security Team has to quickly release a new Apache package?
If that person is a part of that project and has the right to create
packages and put them on apache.org for download, it can be done quickly,
but I agree it raises an obstacle, technically.
> Also, will the Debian maintainers that are involved be able to freely
> create new apache debs when needed, or will they have to go through
> some kind of approval process?
It's up to each project, I guess - in the httpd project, once you're a
committer, you're a pretty trusted entity and can put stuff in the dist
directory for download, etc.
> The reason I bought up DFSG #8 is that if renaming the package is a
> significant inconvenience (partly because of our name-oriented package
> structure, partly because all places where Apache announces its own
> name have to be hunted down), then I think that the package is _not_
> free if making a modification means first dealing with this inconvenience.
You're right, my proposal about having that Debian developer be a core
Apache developer and thus have special rights isn't just an inconvenience,
it constitutes a license that gives Debian special treatment, which isn't
DFSG-compatible. So, a document describing the criteria a package must
meet to be called Apache would be better.
> The trademark approach works for several open projects I know of,
> including Debian itself, Linux, and the Kannel project (which I do
> for a living).
Is there a document or email somewhere that describes a situation where
Debian has had to enforce its trademarks? Did anything go beyond an email
threat to pursue? I'm just worried that no one's really tried to enforce
a trademark on an open source project before, in front of a judge, even if
email threats worked.
> (Should I continue to Cc you? I'm not sure if you're on debian-legal)
I am on the list, and don't mind getting duplicates.
Brian
Reply to: