Open Stack

On 2016-11-12 17:44:42 -0800 (-0800), Clint Byrum wrote:
> https://www.apache.org/licenses/GPL-compatibility.html
> 
> "This licensing incompatibility applies only when some Apache project
> software becomes a derivative work of some GPLv3 software, because then
> the Apache software would have to be distributed under GPLv3. This would
> be incompatible with ASF's requirement that all Apache software must be
> distributed under the Apache License 2.0.
> 
> We avoid GPLv3 software because merely linking to it is considered by
> the GPLv3 authors to create a derivative work. We want to honor their
> license. Unless GPLv3 licensors relax this interpretation of their own
> license regarding linking, our licensing philosophies are fundamentally
> incompatible. This is an identical issue for both GPLv2 and GPLv3.
> 
> Despite our best efforts, the FSF has never considered the Apache
> License to be compatible with GPL version 2, citing the patent
> termination and indemnification provisions as restrictions not present
> in the older GPL license. The Apache Software Foundation believes that
> you should always try to obey the constraints expressed by the copyright
> holder when redistributing their work."
> 
> So, no, I don't believe that they're compatible and I don't believe this
> could even be rewritten to be ASL 2.0.
> 
> Ansible plugins need to be GPLv3. Period.

Fair enough. This seems to be a point of contention (whether using a
library inherently makes the software written to use it a derivative
work of that library, or merely requires the two when distributed to
be licensed compatibly):

http://www.rosenlaw.com/lj19.htm
https://lwn.net/Articles/548216/

The ASF position seems to be generally grounded in the FSF's
interpretation, and the opinions of those writing licenses aren't
necessarily always the opinions of those using them. We'd probably
be better off getting an opinion in writing from the Ansible devs on
whether they consider Ansible Python modules to cause the plug-ins
importing them to necessarily become derivative works.

Anyway, in the case in question it's irrelevant since the planned
plug-in will be directly derivative of the source code of an
existing GPLv3-licensed plug-in, so it remains academic for now
unless they've already officially answered that question elsewhere.

> I think it just has to be an exception and stored in a separate
> repo.

This is a leap I'm still unclear on. Is this separation for logistic
reasons? There's nothing I've seen which says every file in a Git
repo needs to be under even compatible licenses much less the same
license, nor does separating files into different repos magically
solve legal problems around license compatibility. It's been
suggested that our ICLA makes this a problem, but we don't say that
the ICLA covers every file in any particular Git repo (and in fact
we don't mention in the ICLA what software exactly is covered by
it... repos marked as deliverables of official teams recognized by
the TC? it would be nice to get that clarified).

If Kolla uses Ansible through subprocess/CLI integration which we
consider to not cause Kolla to be derivative, then does that
situation change if we put parts of Ansible in a Kolla repo and mark
those files as being distributed under GPLv3? What then makes
including this additional Ansible plug-in in a Kolla repo any
different from that situation? And how would putting it in a
separate repo instead change the licensing situation for it?

I'm all for the Kolla devs deciding they don't want this file in the
same repo as Kolla, but if we're going to say that there are legal
reasons forcing their hand I'd like to see those reasons enumerated.
-- 
Jeremy Stanley