the MySQL campaign; my thoughts...

Monty Program and the flying EC petition

[In this article, MP means Monty Program AB, which I believe is the name of the commercial entity behind the campaign to get the EC to stop Oracle buying MySQL as part of the Sun acquisition].

(Disclaimer: I have no connection of any kind with Oracle, MySQL, MP, Sun, or Postgres. I use none of their products myself, although some open source software I use may be using Pg or MySQL underneath. I work for an IT services company that probably has partner agreements with every major vendor of anything, hardware or software, but it's a pretty large company, and I have no visibility into those things. This article has nothing to do with my employer, and I do not speak for my employer. It is the point of view of an individual who is an open source user/enthusiast/evangelist of 15 years standing, has some strong opinions on what is going on and is using blogspot as a pulpit to stand up on and rant).

[Anonymous comments are ok, but please do sign off with a name. If you find any *factual* errors, please also cc sitaramc@gmail.com so I might see it faster.]

---

NQOSS
"infrastructure", vendor lock-in, and fungibility
emulating a US bank :-)
true open source
an open question to MP
the last word

---

MP is appealing to the EC to block the sale of MySQL to Oracle, with arguments of various kinds, all built around the idea that Oracle will have the power to kill MySQL.

Here're my thoughts on this, for what they are worth.

NQOSS

MySQL is an open source product, but the development model is not quite what one normally associates with other OSS products. Everyone is not equal. One single commercial entity holds all the copyrights to MySQL, and requires all contributions to be copyright-assigned to them.

(The word "commercial" is in there to differentiate entities like the FSF, ASF, etc., who have requirements that sound similar, but whose terms are actually much more consistent with the open source ethos, and thus much more palatable to individual contributors).

I call this NQOSS ("not quite open source software") because such products have no (or very few) contributors from the outside world. MP have themselves said (see section 5.3 of this pdf):

[...] MySQL was almost fully developed by employees of MySQL Ab and later Sun's MySQL division.

In fact, from that statement I would even say MySQL has a closed source development model, even if the code is open source.

However, as far as I can find, no one in MP has ever admitted that it is the copyright assignment clause that keeps external contributors away, thus necessitating development to be internal.

As Jon Corbet (whose general clarity of thought and articulation, as seen in his LWN articles, has earned him innumerable fans) says here:

Agreements like Sun's and SugarCRM's are common when dealing with corporate-owned projects; they clearly prioritize control and the ability to take things proprietary over the creation of an independent development community.

That LWN article is more about Canonical, however. For more on the general issue of copyright assignment, see this rather long piece from Michael Meeks. A couple of quotes from that page:

I am not aware of a single project that mandates copyright assignment to a corporation that has a diverse, and thriving developer community.

and

some of the most successful open source projects require no copyright assignment: Linux, Busybox, Xorg, Mozilla/Firefox, GNOME, KDE, GStreamer, and a whole clutch of others too many to mention; indeed this is arguably the normal state of Free software projects

To put it bluntly, there isn't sufficient developer mindshare for MySQL to be a proper open source project because they wanted it that way -- they wanted to be the only one to be able to make money off of it.

infrastructure, vendor lock-in, and fungibility

There is a tacit assumption in all of MP's arguments that people who use MySQL cannot easily migrate to Postgres or something else. That's usually called vendor lock-in. Doesn't matter if it was intentional (as it often is with some other companies one could name) or otherwise. In fairness in this case it was probably unintentional; I have no way of knowing.

Meanwhile, Monty says "MySQL is not an end user application, but an infrastructure project that is quite deep in the system stack".

I don't know about you, but I've always felt that infrastructure should be fungible. You should be able to replace one for another with not too high an effort, for the vast majority of apps using a database.

[There will always be apps that require specific feature(s) and are therefore locked-in to one product; this discussion does not pertain to them. It's not "vendor lock-in" if you walked into it with your eyes open because you like/need something special that only that product has. That's a genuine competitive advantage being used the way it was intended to be. My point is simply that this is not needed for the majority of apps.]

For most apps, though, if you needlessly locked yourself into MySQL, you do have a problem, and sooner or later you'll have to deal with it. Remember that the code is the most important thing -- don't worry about the backend tools; migrating those is likely to be an O(1) effort compared to migrating your application code itself. Keeping your code as db-neutral as possible would make that even easier.

Personal note: Years ago, I used to convert Burroughs DMS-II (a hierarchical database!) apps to IBM DB2 or DB/400, including all the COBOL programs of course. Each of them was a challenge, made worse by the fact that, unlike modern languages like perl or php or even C++ or Java, each COBOL is different in innumerable subtle ways from another -- even within the same manufacturer there would be huge differences between one COBOL and another! I also wrote/maintained tools to convert almost any type of COBOL+ISAM files to OS/400, DB/400, and COBOL/400.

Thankfully those days are gone, and by and large this sort of lock-in has disappeared. I'd expect this to be much simpler today, but I don't have direct, recent, experience of writing an app that uses a db.

emulating a US bank :-)

Consider:

• MySQL creates an open source product
• they make lots of money selling licenses for a few years
• they make even more money selling the whole thing to Sun at some point
• and now they want to prevent Sun from selling it to whomever they want to

Regardless of how you look at it, this is crazy. Once I sell you something, I should not be able to dictate what you get to do with it, should I?

And in this case it's not even anti-trust. Even after they buy it, Oracle is far from being a monopoly in databases.

MP are essentially asking for a bailout. From the effects of their own choices and decisions. Not in direct financial terms, but indirectly, via policy!

true open source

Let's consider what would happen if Oracle bought it, and -- as MP fears -- kills it off:

• someone takes the last GPL version and forks it
• since they do not own the copyright on this, demanding (or even getting) copyright assignment does no good -- they can't dual license anyway.
• Oracle can't demand copyright assignment either, because it's a fork, not their version being changed
• now the external developer community starts trickling in, because it finally makes sense for them to contribute
• all the supposedly great stuff currently being done by MySQL's partners (see that same URL above) comes out into the open, and gets done by the real open source community. Some of it will be slow, some will be fast, but it will happen.

Wait a minute -- am I actually saying that Oracle "killing" MySQL will be a good thing for... MySQL?

Yes :-)

It'll become like Linux. No single company stranglehold. A vibrant, open, development community. And lots of money to be made still, just in a different model, that's all.

Anyone who claims to be an open source evangelist should be happy ;-)

an open question to MP

Feel free to assume the worst that Oracle can do, and analyse the effects on a real, pure open source, project that uses MySQL (and can only use MySQL, for technical reasons). Show how such a project is harmed by this sale. Post the analysis on your site and a link to it as a comment here. (Don't post the analysis here).

That could help your case far more than all the rest of your efforts, as far as I am concerned.

Or... don't...! You don't really have to care what I say and react to it; I'm not really a big fish in any way, luckily for you.

the last word

I'll let Michael Meeks have the last word:

There is, of course hope - that individuals, smaller corporations and consultants will see the dangers, rebel against them and invest and adopt only the truly open technologies.

Amen to that...