Compatibility of the AFL with the GPL
Brian Behlendorf
brian at collab.net
Wed Mar 12 19:24:30 UTC 2003
On Tue, 11 Mar 2003, Lawrence E. Rosen wrote:
> 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.... :-)
Let's say I'm trying to be more cognizant of my own lack of formal legal
training, and have a strong desire to improve it based on real-world
examples.
> > 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.
I can't speak for RMS and would never want to. My perception is that one
of the things that attracts people to the GPL is this sense of trust - if
a whole package claims to be GPL, you can combine it with other GPL or
LGPL code, the net result will be GPL, and you can rely on that fact. I
think most people would prefer a world where there were as few different
licenses they had to read and understand and follow as possible, and the
GPL biases towards that end. That's not necessarily a "free software"
goal, but a pretty saavy practical goal.
Section 2b is pretty clear:
You must cause any work that you distribute or publish, that in whole or
in part contains or is derived from the Program or any part thereof, to
be licensed as a whole at no charge to all third parties under the
terms of this License.
As is section 6:
You may not impose any further restrictions on the recipients' exercise
of the rights granted herein.
GPL + anything = GPL, or you can't redistribute. The GPL *does* allow for
certain kinds of additional restrictions where there are laws one can't
work around - see section 8. But they're extremely narrow in scope.
> > 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.
By redistributing your work I run the risk that our two interpretations of
"endorse" and "promote" may differ, and to wake up one morning to find a
breach of contract claim against me. That's my worry. Now, Apache has
used that to *positive* advantage, as it's much easier to go to a party
and tell them they're violating the Apache license by using our name, than
pursuing a claim under trademark law. But, that's not something the GPL
allows today. So as I've seen this, being GPL-compatible means giving up
a rather useful device to protect one's name. It's a tradeoff.
> > 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!)
>From the way I read that section, it sounded like the clause was a
condition I had to follow in order to redistribute. That is, if I publish
a derived work and use language that you find objectionable on those
terms, then I will have broken the contract. "You may not use" is, to me,
much different than "nothing gives you the right". Reaching here, I'm
thinking that if I break the contract then everyone I gave a copy of my
derived work to suddenly finds themselves in license limbo as well, even
if *they* properly respected your trademarks.
> > 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?
Let's talk about user Bob. User Bob picks up a piece of GPL software and
starts to use it. User Bob doesn't crawl through the code looking for
copyright notices; he saw that the codebase was under the GPL, and assumed
that it meant he just had to follow the terms of the GPL. Certainly
nothing in the GPL suggests that other parts in the codebase could be
under other licenses which had additional terms he had to follow; if
anything it seemed to guarantee to him it didn't.
User Bob does something that triggers the Mutual Defense clause. Oops.
He wasn't even aware that existed. Someone with standing comes along and
sues him for violating a clause in a license he didn't even know existed.
Should he have known that there were additional terms on some parts of the
software he was using? Should all people who use GPL software crawl
through the code looking for additional licenses?
It seems to me (again IANAL) that the license on the whole has to be a
superset of the individual licenses it contains. If the license on the
whole is GPL, then that means any other licenses within that bundle on
just parts of the code need to be subsets of the requirements the GPL
places.
> > 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.
But but... your AFL terms persist, so I'm not really relicensing. This
new one-byte-different derivative work is *not* under an Apache license -
one who picks up that code and follows only the Apache license may find
themselves violating your AFL license. The license on my *modification*
(that whole byte) may be Apache licensed, but not the bits derived from
your original work.
Brian
--
license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
More information about the License-discuss
mailing list