I don’t see why the GPL would be a major barrier to a useful MySQL fork
I posted suggesting that substantial elements of the MySQL community should throw their weight behind MySQL forks. Mike Olson of Cloudera helpfully pointed out, on Twitter and by email, how the GPL could appear to stand in the way of such an effort. But would it really?
Currently, any version of the MySQL code that isn’t proprietary to the MySQL company — which is owned by Sun and hence expected to be owned soon by Oracle — is covered by GPL 2. That license states (emphasis mine):
Activities other than copying, distribution and modification are not covered by this License; they are outside its scope. The act of running the Program is not restricted,
Hence it is hard for me to see how the MySQL company could in any way hinder another software vendor from saying “Please buy my software, then go download a free copy of GPLed MySQL and run the two together.”*
*Of course, saying that might be more awkward for an appliance vendor such as Kickfire than for a software-only company such as Infobright, but I’m not prepared to address that nuance yet.
Admittedly, what I’m proposing is not the business model for MySQL storage engine vendors such as Infobright today. They ship software that includes MySQL, and incidentally co-market with MySQL, and all that might indeed depend on cooperation with the MySQL company. But in principle, I’m not aware of any reason a software vendor or consortium of software vendors couldn’t support a project to modify a forked version of MySQL as they deem appropriate, GPL that, and then sell their own proprietary software to interact with it.
It is widely believed that Richard Stallman et al. are correct when they claim that anything which links with a GPLed program must be GPLed itself, special license arrangements perhaps excepted. (At least, that’s consensus for static linking; the case of dynamic linking is more controversial.) But while this might be true in many scenarios, I don’t see how the extreme form of the claim makes sense. In the case I posited, neither the vendor nor the user would be doing anything other than what the GPL expressly allows.
Comments
14 Responses to “I don’t see why the GPL would be a major barrier to a useful MySQL fork”
Leave a Reply
GPL v2 states that it applies to “either the Program or any derivative work under copyright law”. The interesting part is in Section 2, where it states “If identifiable sections of that work are not derived from the Program, and can be reasonably considered independent and separate works in themselves, then this License, and its terms, do not apply to those sections when you distribute them as separate works. But when you
distribute the same sections as part of a whole which is a work based on the Program, the distribution of the whole must be on the terms of
this License”
The big question is how does a third party storage engine fit into the picture? Clearly, if it is statically linked to a MySQL binary, it should be subject to the GPL v2. A commercial company selling a storage engine can’t accept this, so that would be a barrier to supporting the fork. If the storage engine is dynamically linked though, you hit a gray area that, as far as I know, has not been tested in court. Does that constitute a derivative work?
I usually use the rule that if I am loosely bound to a project, where it can easily be swapped out for another implementation without any changes to my code, than I can call GPL code from my code, as long as the licenses are compatible. For example, if I use JDBC and standard SQL, swapping MySQL out for PostgreSQL or Oracle just involves adding the appropriate driver and changing the connection definition, typically in a text file somewhere. In this case, I don’t believe my code is subject to the license of the database. MySQL (the company) felt differently.
The case with storage engines is fuzzy. Are they usually dynamic libraries? Do they use a standard or proprietary API? Its my understanding that they are dynamically loaded, but are using a MySQL specific API, and require info about the engine to be loaded into the MySQL engine. I think this would make them subject to the license of the MySQL flavor they use IF they ship the engine with the database.
Now what happens if they just release their engine as a binary, and include info on how to get the MySQL source and build a version that supports their engine? I’d say “consult your lawyer”. Of course, it may be an academic question, as I can’t see a commercial entity requiring that their customers to download and compile a database just to install their product.
Disclaimer: I am not a lawyer, and the above does not constitute legal advice.
-Barry
[…] I don’t see why the GPL would be a major barrier to a useful MySQL Fork […]
I’ve given up on Stallman’s understanding of derivative work. He starts out well enough discussing how people can contribute code to FSF projects even if they have seen the source code for non-GPLed programs ( http://www.gnu.org/prep/standards/html_node/Reading-Non_002dFree-Code.html#Reading-Non_002dFree-Code ). But when it comes to linking to a GPLed program he leaves the law behind and talks about technical questions like address spaces.
Derivative work is a legal question, and the boundaries will be expressed in legal terms, not technical ones.
I understood MySQL was open to dual licensing ( http://www.mysql.com/about/legal/licensing/oem/#3 ). Is this not the case in practice?
I agree from a technical point of view. There are some costs associated with maintaining forks (GNU Emacs vs XEmacs, or if you prefer http://www.codemonkey.org.uk/projects/fsx/ ), but if the consortium gets enough user and developer support it can run indefinitely. But I would prefer to see one de facto implementation instead of fragmentation a la FreeBSD, OpenBSD, NetBSD, DragonflyBSD, etc. (please note, I have no problem with the BSDs; they are great software, but there is no arguing that a lot of effort is duplicated by four teams maintaining their own BSD).
My whole theme here is doing something with MySQL that the MySQL company might actively oppose. That can only be done under the GPL. 🙂
IANAL, and even smart lawyers whom I’ve spoken to consider the GPL hard to deal with because it’s so uncertain what various provisions might mean. There evidently is not a lot of case law at this point.
I know enough about law to know that relying on the distinction between “statically linked” and “dynamically linked” is unlikely to make a big difference in a legal outcome.
If a storage engine vendor has to tell its customers to download something and recompile or relink something, that is a very large problem. Making software that requires even THAT level of technical expertise, and can’t just install in a straightforward way, would be a serious disadvantage. Maybe you could hide it all in an installation tool, or something like that.
But my biggest worry is that the GPL issues raised here are murky. I would want some very strong assurances from a lawyer who, for some reason, was extremely credible about interpretation of the GPL, were I to approach this potential time-bomb.
Well, yes. The GPL carries quite a load of FUD with it.
It is my understanding that commercial storage engines can create an OSS glue layer that makes calls to storage engines (multiple). This same OSS glue could work with Berkeley DB, PostgreSQL and Ingres. Thus it is DB independent. Such glue could then call multiple commercial storage engines, aking it storage engine independent. This way the two pieces (MySQL and storage engine) are not considered one product. This satisfies another aspect of the buffer between GPL and commercial. With an open source glue that supports X DBMS and Y storage engines, and by making the glue OSS, you are good to go.
Mike,
Good point. And I think it addresses a point Dan was raising in another comment thread.
Thanks,
CAM
Curt,
Do you have any additional thoughts, or have you uncovered any reasons, to your comments expressed above?
But in principle, I’m not aware of any reason a software vendor or consortium of software vendors couldn’t support a project to modify a forked version of MySQL as they deem appropriate, GPL that, and then sell their own proprietary software to interact with it.
Secondly, can you think of any reasons why a customer wouldn’t be concerned about what Oracle might do to forked MySQL initiatives?
Jeff,
Not really. I’m just waiting — and not necessarily while holding my breath — for news that storage engine CEOs like you and Mike are getting together and actually making something happen.
CAM
Mike didn’t leave a calling card?
ScaleDB
[…] vendors from selling their products without MySQL code (e.g., with MySQL-fork front-ends). I argued No. Most people, however, seemed to think “Yes, and even if the matter isn’t clear, the […]
[…] MariaDB, the product, is a MySQL fork. […]