New insights into the GPL vs. MySQL storage engine debates
Around the time of Oracle’s acquisition of Sun and hence MySQL, there was a lot of discussion as to whether MySQL’s GPL license could inhibit MySQL storage engine 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 threat of nasty lawyers creates enough FUD to be a practical market problem for the storage engine vendors.” Based on those concerns, I eventually took the position that Oracle should be inhibited for antitrust reasons from invoking its real or alleged GPL rights to mess with the MySQL storage engine vendors. Oracle’s agreement with the EU alleviated that concern, except that there was an annoying time limit on the alleviation.
Now a related can of worms has been opened in a related technology area — WordPress and WordPress themes. Since many bloggers use WordPress, this has gotten a lot of attention, and some interesting new insights have emerged.
Um, in case you didn’t know: WordPress is the software that runs blogs such as this, and it’s a GPLed open source project. However, the user interface — look, feel, and behavior alike — are determined by separate themes, that one usually gets from third parties (WordPress ships with a a few default choices).
It started when Matt Mullenweg went after the makers of an unfree theme Thesis, and wielding a legal opinion from the Software Freedom Law Center. The gist of the SFLC’s argument seems to be
They are derivative of WordPress because every part of them is determined by the content of the WordPress functions they call. As works of authorship, they are designed only to be combined with WordPress into a larger work.
And of course the point of the GPL is that if you create a derivative work of something GPLed, you have to GPL it yourself.
However, Perpetual Beta pointed out that, under the rules of copyright law as expressed in a court case known as Galoob, depending on another program does not make something a derivative work. This is actually blindingly obvious, as in the example of any program that runs on top of an operating system. Or for more examples see Dave Winer on the point.
Perpetual Beta further argued that, even if it were a derivative work, fair use would let one copy it anyway. I.e., if you’re engaging in “fair use,” you’re entitled to do what otherwise would be a copyright violation. Good point. The GPL license says in effect “You only are allowed to use this material (in certain ways) if you do as we say about your own work,” so that is defeated if the Fair Use Doctrine lets you say “Um, actually, I’m using this without your permission, so buzz off.”
GPL advocates can pontificate all they want about certain uses of GPLed code violating their license terms. But if either of these arguments holds up — and it looks to me like both do — a program that invokes GPLed code is not subject to the GPL just based on those invocations. And that, in turn, would more than imply that MySQL storage engine vendors could use GPLed MySQL-compatible front-ends without being under any GPL obligation themselves.
Comments
10 Responses to “New insights into the GPL vs. MySQL storage engine debates”
Leave a Reply
If integrating some code into a GPL software to build a new software wasn’t a derivative, then LGPL would be useless, the virality of GPL would be useless, all we would need would be BSD licenses.
Your statements aren’t applicable on Thesis WordPress theme because WordPress themes and WordPress aren’t different programs. It’s not because they are in different files that that they are different programs. WordPress and the theme it’s configured to use are a unique program. If you remove some of the theme executable files, then WordPress itself doesn’t work.
If I take a GPL program, change a few lines, and try to sell that, the GPL stops me. That’s clearly a derivative work.
So let’s say that the virality of the GPL is much less useful that Richard Stallman et al. like to think.
IANAL and all that, of course. But basically, the GPL is a big con job and intimidation racket, which has been allowed to persist in large part because the intentions of the perpetrators seem pretty pure. To the extent somebody — e.g. hypothetically Oracle — tries to use the same tactics in pursuit of normal profit, greed and self-interest, I hope the courts would slap them down hard, and I’m available as an expert witness to that side of the case.
[…] a recent comment I pooh-poohed an expansive interpretation of the GPL, even as I supported the GPL in core […]
My view would be that if you create software that invokes GPL code you should have to pay a royalty to organization that manages the underlying code. Given that would be against the principle of the GPL then you have to offer some value to the community. Would it be overly complex to create your software in two layers, a layer that invokes the GPL code which would be subject to GPL and then a layer that was commercial and proprietary. That way their is created value to the community and value to the developer. If perhaps the GPL management layer had to be at least a certain percentage of any overall solution you could ensure the community benefited in line with the commercial value.
Mike,
Is it your contention that every app that invokes Linux should trigger a payment to the developers of Linux? Even commercial operating system vendors don’t demand that.
As for the dual layers thing — GPL extremists dismiss it as ineffectual, at least in the MySQL storage engine case. I forget exactly why, but it’s in comments somewhere on this blog. 😉
Best,
CAM
The difference between the GPL and the LGPL (originally Library GPL, now Lesser GPL) is precisely in the area of linking. According to the FSF (i.e. rms), if for example Linux’ libc.so were under the GPL, it would be essentially illegal to write non-GPLed software for Linux, since nearly all Unix-like code depends on the C library. The LGPL says you can link anything you want to this code, but if you change the library code itself, the changes fall under the GPL — which is reasonable.
Personally, I go along with Linus himself, who has expressed the opinion that software licenses are more like moral exhortations than like legal contracts.
It should also be pointed out that proprietary hardware drivers have been written to run as modules of the Linux kernel for many years, causing grumbling among kernel developers but no legal action.
The most famous and widespread example is the NVidia graphic card driver. NV won’t release the hardware programming specs due to the cutthroat competition in the graphic chip market, but they regularly release X drivers which consist of a layer of source code which links to a proprietary binary library. FSF types don’t like this much, but it’s the fastest X server on the planet short of high-dollar graphics boxes.
Craig,
Thanks for the Linux info! Not an area I know on any level of detail.
[…] debate I wrote about a few days ago over whether or not the WordPress theme called Thesis needed to be GPLed has been resolved in practice – it will be. More precisely, the parts that WordPress […]
[…] View the original article: New insights into the GPL vs. MySQL storage engine debates | DBMS2 … […]