In his blog Does the GPL Matter? In a Word, Yes, Stephen O'Grady makes the significant point that the dual-licensing model has a major drawback:
Sun/MySQL can only include patches and contributions if they fully own the copyright to those changes.
This gives forks like Drizzle, OurDelta, Percona and MariaDB a major advantage over the Sun version: they can include the best patches from all over. And it is clear that the momentum is building.
In a follow-up blog, Stephen asks: "what would the implications be if MySQL, of all projects, were forced to abandon the dual-licensing model it had long championed?"
Thinking about this, there is something that really bothers me:
Let's assume MySQL took on patches without ownership of the copyright, and thereby lost the ability to provide a commercial license to OEM customers.
According to the GPL this would mean that nobody could ever ship a commercial product with MySQL built-in!
To avoid this possibility from being lost to the world forever, surely MySQL would have to abandon the GPL, and maybe change to LGPL or BSD!
8 comments:
The issue MySQL is facing is that they are loosing control of their own product, and a big part of that seems to revolve around the dual-licensing model, but I think Sun/MySQL has other problems they need to solve as well before they can stop getting stomped by all these forks.
I don't think removing the dual-licensing bottleneck would help Sun/MySQL by itself - it seems they are very reactionary and that is also a serious issue. Take 5.4 - MySQL can spin it all they want, but people in the community have had the performance patches available for a long time. Companies like Percona and ProvenScaling even had ready to go MySQL distributions you could just plop in place and call it done.
It took MySQL months to retaliate, and I feel it was a knee-jerk but also late-to-the-party type of response. Plus, 5.4 is still beta, yet we have performance patches for the current 5.0 and 5.1 branches.
Most companies don't like to run beta software. If a company like Percona is willing to stand behind their patches, then it seems to be a pretty easy choice for a company (and for our customers, it most often is).
I want MySQL to succeed, but I also really like the competition, particularly as a consumer of the product. If Sun/MySQL is actually considering dropping the license, I hope they are also considering how to make their development more open and also expeditious.
From what I understand, though (and I could be totally wrong), Sun/MySQL makes bank on the dual-licensing model. Dropping that could hugely impact their business if they don't figure out another way of making money.
Plus, even if they did all that, Drizzle is still waiting on the side-lines, and if I were MySQL, I would certainly be concerned about it.
@Tim - Sun owns the copyright to the code from which Drizzle was derived. All contributions to Drizzle are BSD. Therefore, Sun can dual-license Drizzle. See http://drizzle.org/wiki/FAQ.
Hi,
I am not a lawyer, and I have yet to meet the lawyer who can fully appreciate the GPL.
If I understand the GPL correctly, the following sentence: "nobody could ever ship a commercial product with MySQL built-in!" -- is misleading.
There is no problem with shipping your product with the MySQL server, since your product does not directly link with the server: it only connects with it via TCP/IP.
What violates your use of MySQL is *the connector*. The connector (whichever) is also GPL, and you link with it. "link with it" means the connector runs from your process' address space, and this makes the GPL magic work.
So, if you can get your hands on an LGPL/BSD connector - you're just fine! The connector talks with the server via TCP/IP, which does not violate GPL (not the same process/address space), and you are allowed to link with the connector.
The connector is (relatively!) a small piece of code. There are non-MySQL connectors of kinds. As far as I know, they are all GPL or PERL-licensed.
So what I would really love to see is someone writing an LGPL/BSD connector for MySQL in Java, in Python, in C/C++ etc.
Tim,
Forks allow innovation in areas where the project maintainer has either no desire or resources to operate.
"It took MySQL months to retaliate, and I feel it was a knee-jerk but also late-to-the-party type of response. Plus, 5.4 is still beta, yet we have performance patches for the current 5.0 and 5.1 branches."
A) It was not a retaliation.
B) It is not knee-jerky if it took months to produce. Knee-jerk would be to integrate the Percona or others patches without sufficient testing.
The beauty of the recent forking is that it allows alternative technology to mature show its merit before being accepted into the mainline. If a company wants to accept the risk of running a fork that is not maintained by the mainline developers, good for them, let them be the incubation chamber for these enhancements.
As you should know many of the Percona enhancements have been included into the InnoDB Plugin 1.0.4, the MySQL performance fixes in 5.4 will be included into the plugin as well. When the plugin is considered GA by InnoDB (which we all expect to be fairly soon) it can be used with the 5.1 release with the full blessing of MySQL.
So I'm not seeing an acceleration of forking but a merging these back into one unified source (the innodb plugin)
@Mark
Ah I didn't know that. I thought Drizzle was GPL but libdrizzle was BSD. Guess I missed that memo :)
Hi Shlomi,
I am also not a lawyer, but I think that we may be entering a gray area in the GPL. I have heard opinions from both sides. As far as I know there has been some contention about this between MySQL and customers.
Personally, I would like to see this issue debated, and settled once and for all.
However, if you are right, then the library you are looking for is libdrizzle:
https://launchpad.net/libdrizzle
This is a C/C++ library with a BSD license that also works with the MySQL server!
@Shlomi
You said:
~~~
There is no problem with shipping your product with the MySQL server, since your product does not directly link with the server: it only connects with it via TCP/IP.
~~~
You seem to be underinformed. The entire MySQL server can be embedded within an application and it will have no external means of communication such as named pipe, unix socket, or TCP/IP. The server, because it runs as a child process to the application, can be started up or shutdown as often as necessary from within the application itself.
This is a very attractive way to incorporate the MySQL server into an applications and many OEM licensees take advantage of it.
Hi Shawn,
You're right: when using MySQL embedded the case is as you describe. I'm however unsure of just how many products use MySQL this way. I think the majority do not work this way; but I don't have the numbers.
Post a Comment