Tag Archives: gpl

MariaDB C client libraries and the end of dual-licensing

Finally there is an LGPL C client library for MariaDB, and thus also for MySQL. Monty Program and SkySQL have been working on this for some time. Admittedly there was already the BSD licensed Drizzle client library which was also able to talk to a MySQL/MariaDB server, however its API is different. The C client library for MariaDB has exactly the same API existing applications are used to, so you can just re-link and keep going! There is also a new LGPL Java client library for MariaDB.

In case you don’t quite realise: this is actually a major thing.

At MySQL AB, the client library was made GPL and this flowed through to Sun Microsystems and then Oracle Corp. This licensing choice for the client library was the basis of the infamous “dual licensing” model: if you developed a proprietary application to distribute (not just internal or used in a website), you could obviously not just link against the GPL client library was its license explicitly states that whomever receives that code is entitled to ask for the source code. Some describe that as the “viral nature” of GPL – if you want to use such licensed code it prescribes what kind of license you can use for the rest of the code it’s linked to – but in any case that’s how the license operates, following the objective of GPL to promote free as in freedom (for recipients of the programs).

So the way this worked in practice is that MySQL Sales could sell you a non-GPL license for this code, thus enabling proprietary use. It’s legal leverage and not intrinsically bad, but IMHO the way the sales people played this was. Using FUD (fear-uncertainty-doubt) and sometimes misdirection they coaxed clients in to costly licensing arrangements, including in cases where really the GPL license would have sufficed. While this behaviour was by no means corporate policy, the sales people got a lot of leeway – and being paid on commission, these were the consequences.

When the MySQL Network subscription offering (now called MySQL Enterprise) for support was introduced around 2004, the intent was that this new revenue stream would make the dual licensing irrelevant. But that’s not what happened (hindsight gives insight). Since selling non-GPL licenses was a major revenue stream for the sales people, they kept on pushing it. Clayton Christensen and others at Harvard Business School observed years ago that you can’t disrupt yourself, and this might be an interesting example. While the subscription model did take off nicely, the licensing sales were still making lots of money, and thus it did not diminish in importance. Note that this sales model exists until today, see Commercial License for OEMs, ISVs and VARs (Oracle Corp) .

The MySQL Enterprise subscription (which is still sold by Oracle Corp) has had other consequences also. The tools that clients get via that subscription are nice, they provide information on how the server is running and how queries are handled. But it does so at a cost: for some tasks it needs a proxy (sits inbetween app and db server) which of course adds overhead. One simple example is the case where you want to know whether a particular query uses a tmp table or a sort operation, and whether those operations happened in memory or on disk. But the server already knows, so why is a proxy required? Because if the code were in the server, everybody would have it and not just the subscribers. That’s a valid business decision of course, but as you see it has significant technical consequences and someone’s business model should not concern us. In the MySQL 5.0 OurDelta enhanced builds we already applied a patch (an amalgamation of work by several people) to enhance the slow query log, Monty ported it for 5.1 and it’s now a standard part of MariaDB.

For everybody’s sake it would have been great if the dual licensing model had gone the way of the dodo. It had its time (until around 2004-2005, arguably), after which it became a hindrance, actually hurting the MySQL ecosystem – and that situation pretty much persisted until now. That’s why this replacement library is so important, it makes that whole case obsolete. I say horay, and I hope distributions will soon use this library (as apart from anything else, the licensing for it is clear rather than messy).

To summarise, as talks about licensing often confuse (particularly with the amount of FUD and old info around on the net):

  1. GPL v2 only “kicks in” when software is distributed (beyond the boundary of your organisation).
  2. Internal use (which includes the code on running a website) is not distribution.
  3. Whether or not you sell something is irrelevant for GPL: it’s purely about distribution of code, not whether money is involved.
  4. Using MySQL or MariaDB Server is almost always fine under GPL, since you’re not linking against anything else.
  5. The old MySQL client library is GPL, so if you link your app against it you’re subject to GPL, that is, the rest of the app would need to be licensed under something compatible with GPL (typically, GPL itself). Again, this is only relevant if you distribute that app.
  6. The new MariaDB client library is LGPL v2.1, so you are allowed to link it with proprietary application code and then distribute. The recipients must be able to re-link the proprietary code with another version (modified or not) of the client library (easily satisfied if you link dynamically rather than statically).
  7. If someone tells you that use of a wire protocol constitutes linking and that therefore a proprietary app is in essence linked to MySQL/MariaDB Server (which are GPL licensed), this can easily be disputed using the following example (there are many): Microsoft Internet Explorer often talks to an Apache web server using the HTTP protocol, but noone would suggest that these two codebases are in any way linked or co-dependent in a way that would be relevant to their licensing.
  8. While I was one of the people at MySQL AB who dealt with licensing questions and I strongly encourage you to reject FUD (the above info given is no different from what I used to tell while employed by MySQL), I am not a lawyer. Get legal advice if/when you need it, and get it from someone with a serious clue about GPL. Check their public credentials, not just advertising claims.

Also see:

On a side-note, perhaps someone can now link the LibreOffice Base code and the native MySQL SDBC driver (written by Georg Richter years ago) with the MariaDB client library, as they’re all LGPL. This would resolve a long-standing issue that Sun Microsystems (when they owned both OpenOffice and MySQL) sadly did not fix. See OpenOffice.org, MySQL… aren’t they both owned by Sun? And there may be other software projects that can now be “fixed up” in a similar way. If you know of any, please let me know!

Oracle Blamed for Laws of Nature

A catchy headline, and I believe more accurate than Oracle Puts the Squeeze on SMBs with MySQL Price Hike (Network World) and MySQL price hikes reveal depth of Oracle’s wallet love [MySQL Jacking up MySQL Prices] (The Register). Slightly more realistic is Oracle kills low-priced MySQL support (again The Register).

First, let’s review what Oracle has actually done: they ditched the MySQL enterprise Basic and Silver offerings. For Oracle, that makes sense. Their intended client base is “enterprise” (high end, think big corporates) and their MySQL sales and cost structure reflects this. It’s not a new thing that came with MySQL at Oracle, because MySQL at Sun Microsystems and MySQL AB before it had the same approach.

A company simply cannot operate below its market – that is not simply a matter of choice, instead it is dictated by their processes and cost structure. Smart people like Clayton Christensen at Harvard Business School have done ample research on this, here I’ll just give one simple example:

If you hire a sales person on commission and their quarterly quota is $100k, then they have to talk with clients that have at least a $10k-$20k potential (qualified leads), and they need to close (sign contract) with at least 10 within the period. They simply cannot spend any time on talking with potential $1k customers.

We may lament this state of affairs, but you can see how, given the choices made (sales person hired, commission system, quota), it’s as inevitable as an apple falling when you drop it. The way I describe this at Upstarta: if a company wants different results, they need to make sure that their business processes and cost structure lead them in that direction. But the simple fact is that most companies don’t have an internal feedback cycle that keeps an eye on these things, so they just go with the flow of consequences of common choices: aim for large(r) clients, grow turnover, get higher operational costs along the way – that in itself is a cycle and the only direction this particular one can go is up. As a natural consequence, over time old low-end offerings and clients need to be jettisoned – one way or another.

I say horay for Oracle to finally acknowledge this, since Sun Microsystems and MySQL AB before it did not (for whatever reason). This is years overdue. Whether the original MySQL company should have aimed to also serve smaller clients also is an entirely separate topic – and one which I covered at length previously (including internally in my time at MySQL AB), but it’s very much a station long passed. Once you float upward in the market, you can’t operate or move downward.

Now, are SMBs using MySQL actually getting squeezed by Oracle? They are not. There is no lock-in. This is about service contracts, not licensing. As we all know, MySQL is GPL licensed and internal use (even on a website or SaaS offering) is well within GPL parameters. There are a number of different companies offering service for MySQL, different types of service and delivery models and a corresponding wide range of pricing. So SMBs and anyone else has a choice, each can pick the type of service most suited to their needs. Let us celebrate and promote that freedom within the MySQL ecosystem, rather than being outraged about dropped apples falling!

Long tails on licensing questions

In my time at MySQL AB in the Community Relations possition (2004-2006) I wrote several articles on MySQL’s licensing for the MySQL web site. The core reason for having to explain anything was (and still is) the dual licensing of MySQL, in particular the client library. I left MySQL AB years ago, but people still ask me licensing questions. Below is an excerpt from one such question, and my response.

> Hi, Found a post on the mysql website from Arjen Lentz to do with the whole
> mysql licensing question.
> Do you know if the issue with, php scripts (that use a mysql database) issued
> under a proprietary license require you to have a commercial license for
> mysql, or will the issues be covered for the GPL version through the fact
> that the scripts run via php which in-turn connects to the GPL mysql server
> for which the FOSS exception applies.

Note: I am not a lawyer; this is not legal advice.

The issue might be a bit fuzzy since you are actually dependent on MySQL server, whether or not you are “linking”. So the linkage could be there anyway (there’s no consensus on this interpretation of “linking”, it is however the viewpoint of some – hence the fuzzyness).

My recommendation to you would be to not fuss with any nasty licensing for the PHP code you create for clients. While this provides the client with more freedom, you are the expert and thus the first choice for any support and future development. Providing clients with freedom tends to bind them more to you, while restrictions tend to make them look around for alternatives.

Your clients are in whatever business they’re in, which is probably not PHP code development; it’s not in their interest to go spend time on that or undermining you, unless you were to provide bad service.

If you approach your software in this way with your clients, you can generally GPL it and do equal or better business while not having to worry about nettly licensing questions. You don’t want to base your business on a legal argument, as you just don’t want the question to get raised to begin with… it’d be costly and distracting (if not destructive).

EU probes Oracle’s bid to buy Sun

It appears that little MySQL has just become a disproportionally big player in the Oracle-Sun takeover deal…. article by Associated Press: EU probes Oracle’s bid to buy Sun notes:

EU Competition Commissioner Neelie Kroes said Thursday that regulators needed to examine the effect of a deal “when the world’s biggest proprietary database company proposes to take over the world’s leading open-source database company.”

Ah, Neelie Kroes. Dutch lady from the liberal (that’s seriously right-wing in NL, my American friends ;-) party, formerly minister for infrastructure in NL, long time ago.

So what can happen now? The EU can (and I’m skipping a few steps for brevity here) force the MySQL part of Sun to be auctioned separately, to allow the remainder of the detail to go through. One thing is fairly predictable, the price is probably not going to be $1 bln. As far as it wasn’t overpriced back then, a fair amount of talent and activity is not actually inside Sun any more. Less predictable, who might buy what is now there?

And on a side note, where will Drizzle fit… would be regarded as part of the MySQL bundle as it uses its IP for its foundation? If MySQL goes, and Drizzle stays, then Sun(/Oracle) will have a project for which it does not own the core IP. That can be perfectly fine, but that’s not what it’s been aiming for: Drizzle accepts contributions under BSD license, which means that the core IP owner (currently Sun) is actually able to dual-license it just like MySQL. Not saying that’s what it intends with Drizzle, but the arrangement currently makes Drizzle a potential net asset rather than merely a cool/useful project.

There’s plenty of independent interest (not just intellectual but business/money) in MySQL and Drizzle. I for one prefer that angle in the ecosystem now, it might be better off without core IP ownership. Dual licensing was ok for a time in MySQL’s history, but it’s fairly irrelevant and mainly a nuisance.

In any case… who would have thought, that little database originally written by Monty in Helsinki, causing so much trouble ;-)

MySQL docs freedom

As you may or may not know, long long ago (in this universe) I used to be the MySQL documentation team ;-)  Yes, a team of one. This was 2001. It was a great and interesting time. The current much extended team is doing a great job with the now much bigger set of docs!

Today, I find myself disagreeing with my former colleagues on one particular aspect, namely its licensing. You see, the documentation has never been released under an open license, it used to be plainly copyright all rights reserved, and later some rights were granted to distribute the docs together with the server.

Statements made earlier by Karen Padir regarding possible opening up of the docs license filled us with hope. Then, Stefan Hinz (the current docs team lead) wrote a blog entry MySQL documentation: no license change. Some of the arguments there we can just plainly disagree on, but fundamentally Sun wants to discourage forks and basically says that if you want to fork the code, you have to write your own docs. Of course they’re entitled to that position, it’s theirs to make. So what’s my problem with this? Of course I’m going to tell, that’s why I started this post.

While the MySQL codebase is GPL and cannot be “taken back” and closed regardless of who owns it. However, the documentation is not protected in this way to guarantee its continued availability to the community.

People have no implicit trust towards big companies (or even smaller corporations), whether it’s the old MySQL AB, Sun Microsystems, Oracle, or another organisation. Their track record is such that at any point strategic decisions can be made that go against everything they were professing the previous week. Which, by the way, I completely appreciate from a business perspective – whether I fundamentally like it or not.

But if you have a business partner, someone you trust, you don’t just shake hands on a critical arrangement, you establish a binding contract so that the terms are laid out clearly, can’t be reinterpreted later, and can’t just be revoked except within the prescribed terms. Still there’s plenty of litigation about contracts, but that’s a whole other matter. Situations change, people responsible change to different people, and companies change owners.

So, the only thing that makes people trust such organisations is a guarantee that has been externalised and thus can’t be revoked unilaterally. The GPL license satisfies that very well for code. Regardless of who owns the code, the fact that it’s GPL means that it can’t be closed up again retrospectively – at least the codebase up to the point where the license changes (if the company owns all the copyright to the code) will always be free.

With the documentation, it’s copyright Sun/MySQL all rights reserved and while certain grants have been made, those restricted liberties are not implicitly irrevocable, i.e. they have not been granted in perpetuity. As it stands now, the current or future owner of that IP could change the license, and hunt down any outstanding copy to enforce the new arrangement. I’m not suggesting they will change anything, but there is no externalised guarantee they won’t.

I believe this is a serious concern for the product as a whole, and hope this concern will be addressed by Sun Microsystems very soon – with action.