Subject: RE: Compatibility of the AFL with the GPL
From: "Lawrence E. Rosen" <lrosen@rosenlaw.com>
Date: Tue, 11 Mar 2003 21:54:13 -0800

Brian Behlendort wrote:
> All IMHO, and IANAL, coz I get burned every time I post here 
> these days...

Are you afraid I'll slap you 'aside the head?  Relax....  :-)
 
> Despite these clauses being within the spirit of the GPL, 
> they are still additional restrictions on redistribution.

If the goal is "just the GPL, only the GPL, nothing but the GPL, forever
and ever, amen" then I suppose anything that differs from it has a big
hurdle to overcome.  But I thought the real goal was *free software*,
not simply protecting a license.  So what if there are "additional
restrictions" (although I quarrel with your use of the word
"restrictions")?  Why is that not "within the spirit of the GPL?"  RMS
is challenging compatibility, not testing for equivalence.

> In the case of the trademark/names, one who creates a 
> derivative work will always have to worry that your 
> interpretation of "endorse or promote" is broader than 
> anticipated.  For example, if a derivative work proudly and 
> loudly claimed its heritage, perhaps even named itself 
> something similar, there would always be the possibility that 
> you would disagree, and the right to redistribute would be 
> revoked.  Sure, the GPL has other vague clauses, but I just 
> want to point out this is a clause that essentially forms an 
> additional restriction.

Are you suggesting different words besides "endorse or promote"?  Under
U.S. trademark law, anyone can say "I've built a derivative work of
Apache" without using Apache's good name, or yours, to endorse or
promote their software.  I think the words "endorse" and "promote" are
clear enough.

> If instead the license simply *reminded* people that nothing 
> gives them the right to use the trademarks or good name of 
> the original author, then that wouldn't be an additional restriction.

That is precisely what it does.  Note that the provision is entitled
"Exclusions from License Grant," and it says, in essence, "here's what
you don't get with this license."  It doesn't say, here's the penalty
for doing these things without permission.  Do you want me to add the
phrase "pretty please" to the end of the provision so that people will
recognize it is a reminder rather than an order to do or not to do
something?  

Simply put, if an AFL-licensee infringes an AFL-licensor's trademark, he
will get sued for trademark infringement rather than breach of contract.
The infringer won't be able to defend himself by arguing he has an
implied license, because the AFL contains an express exclusion of
trademarks from the license grant.  All the provision does is promote
clarity of the scope of license.  (That's a deficiency of the GPL, by
the way!)

> As for the mutual patent termination clause:
> 
> > I'll leave for another thread any discussion about whether 
> this is a 
> > good idea or a bad idea.  But how is it incompatible with the GPL?  
> > The provision only applies to software licensed under the AFL and 
> > similar licenses, and it doesn't affect in any way software that is 
> > not licensed with this provision.
> 
> The whole point of "compatibility" between licenses is this: 
> if you can combine (not "mere aggregation", but linking, etc) 
> software with license A with software license B and legally 
> redistribute it with license C, then licenses A and B are 
> compatible for some values of C.  If either A or B is the 
> GPL, then C *must* also be the GPL, and nothing more.  But, C 
> must be comprehensive and cover the license of the whole 
> codebase; which means your termination clause must be 
> represented in license C, and that prevents it from being the GPL.

Once again, there is nothing in the AFL that prohibits anyone from
combining AFL-licensed code with GPL-licensed code and licensing the
entire resulting derivative work under the GPL.  The Mutual Defense
provision acts to prevent infringement lawsuits against the original
code but not to prevent lawsuits against the GPL-licensed code.  As long
as the original AFL-licensor is protected, why does he care what license
is used by others for their derivative works?

> Amateur set theorists will quickly see that the only licenses 
> that are compatible with the GPL are those whose terms and 
> requirements are a subset of those of the GPL.  That's always 
> been my understanding.  The MIT/X licenses are GPL-compatible 
> because there is nothing they demand from the end-user or 
> redistributor that the GPL doesn't demand.

I'm reluctant to apply amateur set theory when what is needed is clear
reading of legal provisions in a license.  

> > ***Anyone*** is free to take software licensed under the AFL and 
> > re-license it under any license, including licenses not 
> containing the 
> > Mutual Defense provision ["to use, copy, modify, merge, publish, 
> > perform, distribute and/or sell copies of the Original Work and 
> > derivative works thereof,..."].  In fact, the AFL permits anyone to 
> > freely relicense their derivative work software under the GPL.
> 
> But the license on the parts copied from the original work 
> are still under the AFL, right?  

Yes.

> Which means any new license 
> I put on it has to carry forward the same terms, at least on 
> that original code, unless I indemnify those I give software 
> to by meeting the terms on their behalf?

Nope, it doesn't mean that at all.  What provision in the AFL leads you
to think so?  The only thing you're required to do is honor the license
under which YOU received the software, e.g., the AFL.

> When we use third-party code in Apache, we're careful that 
> the requirements that code places are *not* more onerous than 
> those of the Apache license as well.

OK.  Good for you.  You can also accept code into Apache that is
licensed to you under the AFL.  The AFL is compatible with the Apache
license too!

> Surely you're not saying I can add some whitespace to the end 
> of a .c file, and put the entire codebase under the Apache 
> license, for example.

Yes.  That's exactly what I'm saying (assuming that adding that
whitespace creates a derivative work).  That's true under the AFL.  

/Larry Rosen

--
license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3