Open Stack

Logistically it would be best to make this one file GPLv3. No other
files would need to be GPLv3 in Kolla as this is only one that will be
derivative, rest of Kolla will be safe because of subprocess
separation. Who would be able to say whether or not it's possible to
put single GPLv3 file into otherwise ASL repository? We don't have any
other project with multiple licenses in it? What would LICENSE file in
github show? Do we need to mention parts of GPL there?

On 13 November 2016 at 10:44, Jeremy Stanley <fungi at yuggoth.org> 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/
>
> 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
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev