[openstack-dev] Policy on using GPL libraries [was Re: rtslib dependency for cinder is AGPL - thoughts?]

Mark McLoughlin markmc at redhat.com
Mon Mar 25 21:49:27 UTC 2013


Hi Richard,

On Thu, 2013-03-21 at 21:39 -0400, Richard Fontana wrote:
> On Thu, Mar 21, 2013 at 04:11:26PM +0000, Mark McLoughlin wrote:
> 
> > What I'm taking away from all this is that if an OpenStack project
> > includes code (even optional code) which uses a GPL/AGPL Python library,
> > then it's at least possible that someone with some credibility (maybe
> > even a copyright holder of that module) might claim that this means that
> > OpenStack project needs to be distributed under the terms of the
> > GPL/AGPL.
> 
> Is it *likely* though?  In five years of experience dealing with
> Python packages in Fedora and RHEL and other code contributed to by
> Red Hat developers I have never encountered a single GPL (or AGPL)
> licensor who made such a claim, nor have I encountered a single
> downstream customer or partner that raised this as a concern. That has
> to mean something.

It does indeed. Good info, thanks.

> > Its
> > seems pretty clear cut to me - the Foundation's bylaws appears to
> > prevent any OpenStack project from doing anything that would require the
> > project to be distributed under the GPL or AGPL.
> 
> That is true; for an easy example, if an OpenStack project developer
> somehow did not sign the CLA, put a GPL notice (and no other license
> notice) on a source file, and committed that source file to an
> OpenStack project, that result would unquestionably conflict with the
> policy stated in the bylaws (clearly at least *some* code in the
> project would be distributed under the GPL).
> 
> However, 
> 
> > i.e. to consider linking to GPL/AGPL libraries we would need a bylaws
> > change
> 
> To me this doesn't necessarily follow. It embodies a particular legal
> conclusion.

This is the point that I wish you could just categorically say "it's the
wrong conclusion" :-)

> Maybe it's nonetheless the best approach for OpenStack to
> adopt (e.g. for ease of administration).
> 
> I would think something less severe could be appropriate. I can
> imagine many situations that ought not present even a hypothetical
> problem, drawn from real experiences I've had dealing with other
> projects. Easy case: Suppose the GPL library in question is developed
> solely by one copyright holder who does not wish to use a license
> other than GPL but who states very explicitly that it sees no
> licensing implications for the OpenStack code using said library, no
> conflict with the bylaws policy. And suppose the GPL library falls
> outside the scope of the definition of "the OpenStack Project".
> 
> IOW you could have a case-by-case approach, or a default rule with
> some opportunity to argue that an exception should be made in a
> particular circumstance (without requiring bylaws amendment).

That makes a tonne of sense to me.

> Maybe the ASF *is* a good model to follow here, in that, AIUI, it does
> not have absolute rules around things of this sort (requiring bylaws
> amendment to override). It appears to me (as an outside observer) to
> have an evolving legal policy -- admittedly one that remains strongly
> biased against having GPL code in proximity -- based on real cases
> faced by ASF project developers in real life.

The thing about OpenStack is that I honestly don't see any developers on
the project being interested in taking the difficult decisions about
exceptions to the default rule of "no GPL libraries".

(I'd love someone to say I'm wrong about that)

However, I could imagine us developers delegating that responsibility to
a committee of experts in this area.

Personally, I had hoped (and, I guess, still hope) that the Foundation's
Legal Affairs committee could take on this responsibility without being
overly conservative. But we do need the policy documented and a process
whereby developers can escalate a particular licensing issue to the
committee and get a decision turned around quickly.

Thanks,
Mark.




More information about the OpenStack-dev mailing list