But you *can* touch:

"Subject to the Use Limitation, Licensor grants you a non-exclusive, worldwide (subject to applicable laws) license to copy, modify, display, use, create derivative works, and redistribute the Software until the Change Date."

See? "modify" and "create derivated works" is especially allowed.

On the other hand the "free ride" usage condition is actually "less than three database servers", so your "can't even deploy it on more than three servers" is not correct, it actually is "no more than two".

If you buy the product from MariaDB then you are not using it for free, so the usage limitation "Usage of the software is free when your application uses the Software with a total of less than three database server instances for production purposes." doesn't apply to you.

So no different LICENSE.TXT needed. You can use your modified version internally up to the number of instances you've licensed, you can also publish modified source ("fork it on github"), but others who use your fork are still bound to "total of less than three database server instances" unless they also have a license agreement with MariaDB Corp.

IANAL, but I think that basically has it covered. Any license agreement with MariaDB Corp. is an extension to the LICENSE.TXT conditions, not a replacement in my point of view. But again: IANAL

"You cannot fix the software that you currently run." ... but you can. You get the source. BSL is about usage restrictions, not about not getting the source.

I agree that it is not a true open source license (I'd call it "Eventually Open Source").

But it is not a closed source license either.

It's restrictions are about using the binaries produced from the source, not about seeing or touching the source itself. If you have permission to run it you also automatically have permission to modify and fix it in any way you want.

I won't say that I'm a big fan of the idea either, but we should at least stay with the facts ...

This is not about MySQL or MariaDB (the product) source code though. This is about the MaxScale proxy which is a totally different product. It used the original MySQL SQL parser in its 1.x release, which is still released under the GPL. MaxScale 2.0, which is BSL-Licensed, no longer contains any MySQL code any more.

Any changes made to the actual server product will continue to be under GPL for the reason you've given. Nothing needs ot be given back to Oracle though. The changes are obviously available to Oracle to integrate into MySQL Community Server, but Oracle can't simply integrate them in the commercially licensed version ...

So that would be an iron cube with a side length of about 257km hiding in a roundish object with a diameter of about 200km ... that would make it a very interesting thing to explore indeed ...

They are playing a two-way game in Germany,

* running UberBlack in (AFAIK) Berlin only, offering services in compliance with "Mietwagen" regulations
    -> that doesn't seem to work out well for them as the existing competition already coveres that market well

* running UberPop in several cities which doesn't play by the rules at all

And "not playing by the rules at all" on the Pop side is what they currently get slapped for,
the UberBlack offering is not affected, and they would be free to enter the "Taxi" market,
too (available taxi licenses are limited in a way slightly similar to yellow cabs in NYC,
but buying into that market would still be cheaper than the legal charges they are facing
now ...)

And last not least the german transportation law allows for execptinal licenses to
experiment with new models ... that would require negotiating with the authorities
about such an exception, and as far as I know they never even bothered to ask ...

In Socialist Germany, we only now start to discover the concept of minimum wages ... go figure ...

Uber Black was their attempt to play by the rules (well, sort of) ... they only started to push POP after seeing that there's not really that much demand for the the service they offer with Black over here in Germany

easter_days() plus fixed offset will get you a given years Ascension Day (easter_days+39, Withsunday (+49) etc.

strictly speaking easter_date() is indeed redundant as you could as well use easter_days()+0, but its there as convenience function ...

but as far as I remember the main reason for having both was that the C library the calendar extension relies on has both, too ...

Depends on the SQL_MODE settings ... if using backwards compatible settings you'll at least get a truncation warning now, if using more strict modes it will throw errors instead ...

See http://tools.geofabrik.de/mc/

There is no one-size-fits-all rendering, the "official" mapnik style is but one of many ...

e.g. JOSM has icons for benches, waste_baskets and signposts, none of them show up on the "main" map though ... but they are rendered just fine on the more topic specific hike&bike map

That's why our mantra is: "We don't map for the renderer!"

Local to the machine i'm working on, or to the machine in front of me that runs the ssh client?

> Is it truely drop-in replacement as in "you can develop to MySQL, then run MariaDB in production without worrying"?

yes, unless you use some of the non-GPL extra features like e.g. authentication plugins or pool-of-threads. For these MariaDB has GPL replacements but the implementation and configuration may differ ...

> Does it require converting current tables?

Data format of MyISAM and InnoDB tables is the same, so "no" in general. mysql system database may differ a bit, but nothing the mysql_upgrade tool can't fix, and you'll have the same issues when develop against an older MySQL version and deploying to a newer one ...

> Will it take a 10GB database all day to convert or will MariaDB just use the raw MySQL data files automagically?

It will use existing raw files just fine. mysql_upgrade may take a few minutes max., but not all day ... (unless you're migrating from an older MySQL version and mysql_upgrade needs to recreate some indexes ... but that would happen when upgrading to a more current MySQL release, too, and wouldn't be MariaDB specific

The only point where it isn't a simple "try and revert if you don't like it" drop in replacement is if mysql_upgrade changed mysql.* system tables and you want to roll back to regular MySQL ... but then again this is also the case when trying to upgrade to a more recent MySQL release and then deciding to roll back to a previous older one again ... so you should always have a backup to restore the original system tables from ... but you'd do a full backup before any version migrations anyway, wouldn't you?

http://en.wikipedia.org/wiki/CargoLifter - made it about as far as building a small blimp-size prototype and a nice large assembly hangar for "the real thing" ... which is now used as a large indoor beach resort instead

And even back then it was pretty clear that their planned fleet size whould totally exhaust available Helium supplies ...