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.
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: [email protected]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
