Wednesday, 26 July 2006

Code Contributions & Consideration

Consider this:

You create a piece of code that is truly valuable for MySQL. We give you a T-shirt. Does this feel right?

Of course it doesn't. The CLA (Contributor License Agreement) just contains the T-shirt as a default so-called consideration and a token of appreciation. Several people rightly reacted to the imbalance of T-shirts versus valuable code in my original CLA post.

The legal concept of "consideration" in American or English law means more-or-less compensation, i.e. a countercommitment to make the contract not just balanced but enforceable. Wikipedia's definition of consideration starts like this:

Consideration is defined as a bargain for the exchange of something of value. An example of consideration is the sale of a car for payment (e.g. the sale of a Toyota for $3,000). Consideration is a central concept in the common law of contracts. Under classical contract theory, consideration is required for a contract to be enforceable.

In several cases during the history of MySQL, consideration for code contributions has been money and shares of MySQL AB. On a case by case basis, serious money can move hands. We don't mind paying good money for good contributions. MySQL AB is not a charity, nor do we expect code contributors to be charities towards us.

For quite a number of contributors, I still expect the major consideration to be that we take over the maintenance burden of the patch. And for many contributors, the code contributed may be interesting for some MySQL users, but not for large enough numbers to merit "serious money".

Some contributions are just the starting point of code patches that can be accepted into the code base, complying to coding standards and having gone through the scrutiny of reviews. But rest assured, if you fix bugs in the form of acceptable code patches, there will be much more than just T-shirts coming your way!

With contributors of gems, we have not just agreed for them to join MySQL AB (like Mark Matthews for Connector/J) but compensated them with cash and/or shares in MySQL AB. Such transactions happen after relations have been built up long-term.

Sunday, 23 July 2006

How to Now Contribute Code to MySQL

While most of the code in MySQL is written by employees of MySQL, we are open to contributions by companies and individual contributors. In an attempt to make it easier to contribute to MySQL, we have created the MySQL Code Contribution Program.

MySQL Forge is a collection of projects based on MySQL. The Code Contribution Program is one step beyond that: It's for code that goes directly into the MySQL-owned and managed code base.

As such, MySQL has accepted contributions before. Through the Contributor License Agreement (now released as beta), we have streamlined the legal aspect of the process.

Beside the legal side of the contributor program, there is the development aspect. Contributors may need help and guidance from MySQL developers. For both the legal and development aspect, the MySQL Community Team is the proxy. Potential contributors can reach us through the mailing list, where you can approach us with specific questions.

Here is the beginning of a simple FAQ we are starting:

What is the purpose of the Code Contribution Program for MySQL AB?

From our own perspective, the purpose of the "MySQL Code Contribution Program" is

  1. to drive more fixes by the community to simple bugs, i.e. fix more bugs quicker

  2. to get more contributions in the form of new features, i.e. offer more features for our users

  3. to breed a larger recruitment base of devs familiar with MySQL both for our customers and ourselves

What are the benefits to the developer contributing to MySQL?

I believe that people contributing to MySQL are somehow scratching their own itch. Likely reasons why developers contribute to MySQL are

  1. to avoid having to maintain their patch, which they wrote just in order to fix their own problem with MySQL

  2. to increase their market value for recruitments, not just by MySQL AB but by any company

  3. to get feedback and users for their projects, by using MySQL as the wide-spread fundament of their (academic, research) project

We acknowledge that especially Category 1 people (and companies) consider all admin work to be bureaucracy. This is why we keep the paperwork and legalese to a minimum. But we cannot go below the minimum. Our paying customers are sensitive to our IP rights. They are entitled to know for sure that we as their suppliers own what we sell them.

What are the terms of the CLA?

The MySQL Contributor License Agreement (CLA) means, in simple terms, that:

  • The developer assigns and transfers the copyright of the contribution to MySQL. In return, the developer receives back a broad license to re-use and distribute the contribution.

  • The developer grants a patent license to MySQL and its users, in the event that the developer owns a patent that covers the contribution.

  • The developer represents that he or she coded and owns the contribution, and is legally entitled to grant the assignment and license.

  • The developer may provide support for free, for a fee, or not at all.
  • MySQL has no obligation to accept or use the contribution.

If MySQL accepts and maintains the contribution, and it is deemed of material value to the Project, the developer's benefit is that we relieve the developer of the burden of maintaining the contribution and will provide the developer attribution in the GA release notes (unless the developer asks not to be mentioned). The developer may also select two of the following items: a MySQL Press book, a MySQL shirt, a US $100 rebate to a conference or training class, or a US $100 donation to the Free Software Foundation (FSF) by MySQL AB.

Why does MySQL AB require copyright transfer? Red Hat does not!

The GNU Project does.

MySQL is the owner and copyright holder of the entire MySQL product, whereas Linux does not have one single entity as a copyright holder.
This makes the MySQL Dual Licensing model possible. The MySQL users benefit from this in the form of further product development
financed by MySQL (with currently over 80 developers on MySQL's payroll). While MySQL has developed most of the MySQL database itself, and continues to do so, MySQL also wants to simplify the processes for contributors to MySQL.

Caveat for Europe

We received some comments on legal issues related to some European jurisdictions (notably Germany), which might still influence our timetable. This means that the CLA is still in Beta form, and may receive some updates to improve its global reach.

Friday, 21 July 2006

MySQL Max Build Policy

Starting MySQL 5.1 (1), we're simplifying life when it comes to the number of builds for each platform. We will be building only one binary package for each platform (2): the binary known in MySQL 5.0 as "max". The assumption is that users prefer one binary with all options enabled, rather than having to choose the proper version at install time (or worse still, rely on others having made the proper choice on their behalf).

And with only one version, there is no need to call it "max". "The max version is dead. Long live the max version!". Not to speak in riddles, the standard mysqld binary is intended to contain all mysqld-max features. While 5.1.11 e.g. in Linux (x86) package still has three binaries


the plan is to reduce this to two. Already now in 5.1, the only difference between mysqld and mysqld-max is the BDB table handler. The only real difference going forward is removing support of BDB, which is the first step towards removing it also from the source after 5.1.

We think the majority of our users agree that the simplification is beneficial. This way, MySQL will by default contain MySQL Cluster, together with all other functionality we deem stable enough to provide our user base with.

In MySQL 5.0 and earlier, the Standard/Max duality has proven problematic from the user's perspective:

  • The question "Which package should I install?" is a very common one on the mailing list.

  • There is a limit to the number of flavours a user can decide between, more flavours is just overwhelming.

  • The risk of the user picking the wrong binary and then thinking "this is not supported" is high.

  • As we want customers to try new things, we should see to it that they already have them installed.

I imagine the user asking himself or herself questions like

  • Has my DBA installed the version I want and need?

  • Are security functions (such as SSL) available in all binaries?

  • Does the Debug version have the extra debug information on top of Standard or on top of Max?

  • Is MySQL Max somehow related to MaxDB? (Footnote: No, it is not)

I won't hide the fact that our Build team also saves some time by not providing multiple binaries: We get a shorter turnaround time for builds, for tests and for uploads to mirrors. And it helps our commercial Support team, which now needs to ask users to separate between flavours for versions, and keep track of differences between flavours.

However, our simplification is not as much about reducing our own build complexity, as about simplifying life for our user base.

  • Fewer choices means less time spent choosing, simpler lists on the Web.

  • The user/developer is less dependent on which particular version he has, when he uses/develops applications based on MySQL.

  • The developer does not need to convince his DBA or ISP to upgrade into a particular flavour of a release.

  • ISPs and DBAs don't have to make complex decisions on which flavours to support.

  • Distributors will hopefully pick up our choice of configuration, to further reduce the number of different MySQL configurations available (and thereby the confusion).

Like with any decision, we don't have all the facts at hand. So now is the time to let us know if we're on track or not. This can be done on
the forums at, or on the mailing lists at or as comments to this blog (if you register yourself first).


(1) The MySQL 5.1 download pages at say

As we're working on making some changes to how we will provide binary distributions of MySQL 5.1, this release currently only provides "Max" binaries for a few selected platforms as well as the source distributions.

Compare this to the download pages for MySQL 5.0 Community Edition - Generally Available (GA) Release at where we say

The Standard binaries are recommended for most users

The Max version includes additional features that have not been exhaustively tested or are not required for general usage. When these features have matured and proven to be stable, they will be incorporated into future releases of the Standard binaries. The Max version also, for most platforms, contains MySQL Cluster storage node, management server and mysqld/ndb enabling programs.

The Debug binaries have been compiled with extra debug information, and are not intended for production use, because the included debugging code may reduce performance.

(2) A separate server binary with additional debugging support enabled continues to be included.

Tuesday, 18 July 2006

Podcast with Scott Mace available on IT Conversations

During the MySQL Users Conference late April, I had the pleasure of being interviewed by Scott Mace in his ITConversations series. The podcast is now available online.

In his commentary to my podcast, Scott says

Open-source database management software is in millions of hands. Find out how MySQL profitably blazed this trail, and how Kaj Arnö of MySQL is helping define GPL 3.0, and how MySQL lives with the complexity of software patents and multiple storage engines. Kaj also discusses how MySQL both competes and cooperates with Oracle. Also, whatever came out of last year's summit of open source database providers? Arno also discusses the forthcoming Falcon storage engine, MySQL-powered Netflix's lawsuit against Blockbuster, .Net plans, its SCO partnership, and the great vodka chocolate giveaway.

Scott Mace is a writer, editor, analyst and -- as listeners of his podcasts will notice -- expert podcaster. You might also want to listen to the other IT Conversations podcasts with people like Steve Wozniak, Clayton Christensen, Lawrence Lessig, Steve McConnell and Tim O'Reilly.

Wednesday, 12 July 2006

MySQL Lifecycle Policy

Database administrators hate to upgrade their databases. At MySQL, we like to think that we have been early to recognise this, and we have given more or less unlimited support to even very old releases, on a multitude of platforms. However, this has not been without cost to ourselves.

Many of our users know that the cost of maintaining several releases is high. We have thus been asked to clarify our support lifecycle policy. After long internal discussions, that were not always easy, we are now pleased to say that we have an explicit support lifecycle policy. It addresses the timeframes we will provide updates and continued support for current and older versions of the MySQL server.

Keeping older versions alive for a long time is appreciated by our community and our customers alike. However, we are no longer in a position to maintain our older versions without remuneration. This means that those wishing to enjoy MySQL's support in their usage of MySQL 3.23 and MySQL 4.0 need to plan for their future, as our support of these releases will be limited to those covered by a MySQL Network subscription, starting in 1 Aug 2006 (for MySQL 3.23) and 1 Oct 2006 (for MySQL 4.0).

This means that we are no longer offering publicly available binary updates for our 3.23 and 4.0 releases. The sources of these will still be provided. We are also evaluating whether we will continue hosting archived versions of old binaries, as well as the timeline for the support of MySQL 4.1.

We hope the clarity offered by this explicit support lifecycle policy will give a good base to our Customers and Users alike, when planning for their future use of MySQL!