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