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