Re: Is the xdebug's non-free license necessary?
On Tue, Dec 21, 2004 at 12:15:50AM +0100, Derick Rethans wrote:
> This clause is perfectly acceptable as a part of the Apache 1.1 license.
> As the Apache 1.1 license is OSI certified, and has certainly been used
> by software distributed as a part of Debian, why would this clause cause
> any problems in my license?
"That license is already in Debian", "that license is used by an important,
high-profile project", and "{the FSF,OSI} likes the license" aren't very
strong arguments for why a particular clause is free; they indicate that
new issues in licensing are always being found, not that those issues
aren't important.
> Find something that allows me to exclude people from using "Xdebug+" or
> "RealXdebug" for names of derived products. That is exactly what I mean
> with this clause. I don't see why this should render something non-free.
> The source is free as you can get, I just do not want any confusion that
> people might get if somebody makes a derived product and calls it
> Xdebug+, as I as original author, will get silly support questions about
> it.
I sympathize with wanting to prevent legitimate confusion, and I sympathize
strongly with wanting to prevent deliberate confusion (eg. trying to leech
mindshare away from your work through clever name selection, instead of by
actually making a better fork). Legitimate goals don't necessarily make
other negative effects of a license clause go away, though.
For what it's worth, I don't really sympathize with using the sledgehammer of
copyright law to avoid receiving a few misdirected emails. :)
In the general case, I think this type of clause is sticky. It doesn't seem
free that my (hypothetical) game, "Apache Combat", couldn't reuse code from
Apache[1]. "Xdebug" doesn't seem as bad, but it feels wrong to be determining
freeness of the clause based on whether the word being prohibited is a
dictionary word or not.
(I don't have a strong opinion on this--not that my opinion is individually
important--which is why I end up using words like "sticky" and "seem".)
> Of course, it's not a derived product, just a package with Xdebug in it.
> As long as there are no strange patches that removes or adds
> functionality (something that I feel distributions should NEVER do),
> there should not be a problem as you're only delivering a 'pure' Xdebug
> to users.
I don't know what "derived product" means. Most packages are probably
derived works, which has a very specific legal meaning, but I don't
know if "derived product" means "derived work".
Another comment on this license:
"Redistributions of any form whatsoever must retain the following
acknowledgment: "This product includes Xdebug, freely available from
http://xdebug.org/".";
These clauses are free, but poorly constructed: requiring acknowledgement
is fine, but it's much better to not specify the exact text. For example,
the URL may change in the future, and this does not allow for it to be
corrected. It doesn't allow translating the text in any way. (An
acknowledgement in English won't work too well if the target audience is
French.) This particular acknowledgement may be false, as well: if I'm
using a couple functions from Xdebug, I'd want to say eg. "... includes
code from Xdebug ...", and if I'm developing a fork, I'd want "... is
based upon Xdebug ...", not "includes Xdebug".
[1] note that Apache no longer seems to use this clause, except in a couple
cases: "mod_ssl", and a single file (which appears to be a test component)
for "Apache" in apache2.
--
Glenn Maynard
Reply to: