Open Stack

On Sat, Jun 14, 2014 at 01:20:27PM -0700, Monty Taylor wrote:
> > 2) libmysqlclient is GPL'd. MySQL Inc did this on purpose so that they
> > could extort people into paying for licenses they didn't actually need.

Indeed.

> > It's important to bring that up because
> > 
> > 3) mysql-python, as you say, is dual-licensed, but it uses
> > libmysqlclient under the covers, so as vague as several of the other
> > issues are here, I think it's pretty clear that mysql-python has to be
> > GPL, since it quite explicitly is a derived work.

I will take your word for it. (Does this also apply to the other
things mentioned in Mike Bayer's response?)
 
> > So the question at hand is whether or not the license of libmysqlclient
> > carries through and attaches to OpenStack. I contend that it does not,
> > for a specific reason: we're using it as an optional plugin.
> > 
> > We don't use mysql-python itself. We use sqlalchemy, which has pluggable
> > provider support. One of the plugins that can be used with sqlalchemy is
> > MySQL. Another is Postgres. Another is Oracle. Etc. So nothing about
> > OpenStack _itself_ requires MySQL or libmysqlclient. It is a
> > runtime/deployment choice.

Right, makes sense to me. However, Chris Friesen's hypothetical is:

 "Suppose someone creates a modified openstack and wishes to sell it to
  others.  They want to keep their changes private.  They also want to
  use the mysql database.

  The concern is this:

  nova is apache licensed
  sqlalchemy is MIT licensed
  mysql-python (aka mysqldb1) is GPLv2 licensed
  mysql is GPLv2 licensed

 The concern is that since nova/sqlalchemy/mysql-python are all
 essentially linked together, an argument could be made that the work
 as a whole is a derivative work of mysql-python, and thus all the
 source code must be made available to anyone using the binary."

So it seems what he really should have been asking is whether
(modified) nova/sqlalchemy/mysql-python/libmysqlclient somehow form a
derivative work of libmysqlclient.

Because:

> Also - the FOSS exception.

The FOSS exception would not help Chris Friesen with his hypothetical
"modified openstack" with "private" changes, *if* the "modified
openstack" is part of a 'Derivative Work' in the sense meant in the
FOSS Exception, assuming you're even in a situation where you want to
rely on the FOSS Exception.

So I think you're right about how things look from OpenStack's
perspective, and so probably the FOSS Exception isn't even relevant,
but that doesn't necessarily resolve Chris Friesen's question. 

I don't think Chris Friesen's question is an OpenStack project
question, since the issue he's worried about results from his own
discretionary choices downstream, if I understand everything correctly
here.

 RF