Open Stack

On 13/11/16 11:44, Jeremy Stanley wrote:
> 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/

Sure, and it's even less clear with a language like Python, where you're 
not distributing a binary that is derived from the source code of the 
GPL component.

> The ASF position seems to be generally grounded in the FSF's
> interpretation,

I think the ASF's position is grounded in not wanting to score a 
spectacular own goal for FOSS by getting into an unnecessary licensing 
dispute with another open source project :)

> 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.

It only takes one copyright holder to disagree before you find yourself 
trying to explain to a jury how this "derived class" isn't actually a 
"derivative work". That's worth avoiding even when you're correct.

So unless there was an up-front interpretation, preferably in the 
license file itself, I think it's perfectly reasonable that we're taking 
a conservative approach.

> 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).

Agreed, it hasn't been as clear as it probably should be. It was 
certainly not our position in the past that non-official repos are not 
covered by the CLA, because I believe we have relied on the CLA when 
incubating previously non-official projects (IIRC having all past 
contributors sign the CLA was one of the checklist requirements).

I think the DCO process makes things much clearer though. It's quite 
easy to understand that contributions to an ASL2-licensed repo are ASL2 
and contributions to a GPL-licensed repo are GPL.

> 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?

1) It can be in a non-official repo without making all of Kolla 
non-official; and
2) a whole repo that is licensed as GPL leaves much less room for 
confusion than a repo that contains a mixture of ASL2 and GPL code (in 
terms of how contributors understand their rights/responsibilities as 
well as how downstreams deal with what we produce).

> 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.

I don't get this. The TC has adopted an official policy that explicitly 
excludes both GPL code and code that imports GPL code from official 
repositories. If you think the policy is too conservative (and it is 
quite conservative) then you're on the TC... change it. Until then we 
don't need legal reasons to force us to follow our policy. It's our 
policy. That's enough.

cheers,
Zane.