Protocols, The GPL, Influences from MySQL

« previous entry | next entry »
Feb. 22nd, 2010 | 11:46 am

I spent my Saturday at the SCALE conference down in LA. Most conferences I find have a meme and for this conference that was "MySQL's longterm influence on the GPL".

MySQL was the company that had the most influence on how companies and investors viewed the GPL.

When MySQL said "we will only take contributions via a contributor agreement", this translated into investors expecting everyone to do this (though requiring contributor agreements destroyed outside MySQL development to the kernel, and left MySQL in a position where no substantial, or many, contributions ever occurred).

When MySQL pushed dual licensing, investors looked for this hook in every business model. I remember standing outside of a conference room in SF a couple of years ago and talking to one of the Mozilla Foundation people. Their question to me was "Is the nonsense over dual licensing being the future over yet?". The fact is, there are few, and growing fewer, opportunities to make money on dual licensing. Dual licensing is one of the areas where open source can often commoditize other open source right out of the market. The dearth of companies following in MySQL's dual licensing footsteps to riches, belabors the point of how niche this solution was.

The influence that MySQL had over the interpretation of the GPL was the topic though that brought out the most serious conversations. The term that was most used was "over reaching". This comment was inspired by MySQL's attitude toward linking, specifically in regards to the MySQL protocol.

For years MySQL published a public domain driver, that was then converted to LGPL, and then finally re-licenced as GPL. The driver was also published under different terms for different languages, all the time being the same protocol/interface (which was originally derived from MiniSQL). Most use of the driver is to simply send an SQL query unmodified to the server. The server then responds back with the information that were generated by the request. When you request a page from a webserver, you send a URL to the server. The server then returns data based on based on this query, where that information could be HTML, plain text, an image, or some binary.

Despite the license change history surrounding the driver, there were often claims made that the protocol was GPL. This one bit of history is probably what created most of the misunderstandings around the GPL that have propagated for the last decade. The MySQL drivers were not the only set you could use to talk to MySQL. PHP and Redhat both distributed drivers for many years that were in the public domain. This went unknown to large companies who had minimal experience with the GPL, or who just didn't do the leg work to find other drivers. If you were using the MySQL drivers then you were including GPL code into your product, but if you were using the public domain drivers no use of the GPL occurred.

The over reaching argument that the GPL works over "protocol" is ludicrous. A protocol is simply an IO path. If the GPL worked via protocol, then every GPL webserver on the planet would infect Internet Explorer, and every GPL browser should be rejected from every non-gpl compliant webserver. If the GPL was this infectious then a GPL based operating system, would not be able to provide files to a non-GPL application. The MySQL/MiniSQL protocol and interface is far less complex then HTTP, the protocol that runs the web.

Beyond the protocol, there are also GPL interface issues that exists for MySQL around the storage engine API. That is of course an entirely different issue, one that Oracle has already weighed into. There were so few storage engine vendors that MySQL influence over GPL interpretation is slight, if non-existent. The market that exists around Linux Kernel drivers, is what shapes the GPL in this arena.

Jonathan's final words to the company "Go home, light a candle, ... “Sun is a brand, Oracle’s my company", apply to MySQL as well.

Being a brand, and no longer an identity, means that reflection on what MySQL brought to the table to define the GPL is now happening. I hope, and expect, to see a rejection occur when the GPL is used for over reaching gains. This would bring back a not only moderate, but accurate, view that will un-sully and un-baggage the GPL from some of the history of the last decade.

Link | Leave a comment | Add to Memories | Share

Comments {29}

Ted Tso

Re: GPL, MySQL and the protocol....

from: tytso
date: Feb. 23rd, 2010 07:27 am (UTC)
Link

> MySQL can publish whatever is wants...

As is often the case, Shakespeare said it best:

MySQL/Sun/Oracle: "I can call spirits from the vasty deep."

Anyone who knows the GPL: "Why, so can I, or so can any man;
But will they come when you do call for them?"

Of course, MySQL isn't the only entity who has tried to play this game. The FSF has for example tried to claim interface copyright (which the LPF rightly fought against when Lotus tried to claim interface copyright) by way of claiming that the GPL infects across a dynamic link, and so a binary which calls a GPL'ed library like readline must be licensed under the GPL.

Oh, really? What if instead of a dynamic link, it's an RPC call, and you're doing this over either a unix domain socket or a TCP/IP network connection? The same claim under which MySQL tried to claim that the GPL infected across a network connection, is not all that different from the FSF's claim that the GPL can infect across a dynamic link and shared libraries.

In fact, copyright law doesn't work that way. If you haven't made a copy, it's hard to claim copyright infringement....

Reply | Parent | Thread

Re: GPL, MySQL and the protocol....

from: anonymous
date: Feb. 23rd, 2010 02:34 pm (UTC)
Link

In fact the legal jargon in GPL does not care much about technical details. "Linking" is a technical term whose meaning may change from time to time. GPL speaks about "derivative works", and yes, a software that requires an RPC service for its crucial functionality can be treated as a derivative work. Linking (both dynamic and static) just usually happens to mean that your software depends on the library. If you can build and run the software without the dependency, and if your users can substitute your proprietary library with a GPL'ed alternative, you are most likely safe.

Reply | Parent | Thread