Forgot your password?
typodupeerror
Databases Open Source Oracle Sun Microsystems

Why You Shouldn't Panic About Closed Source MySQL Extensions 171

Posted by Soulskill
from the time-will-tell dept.
jfruhlinger writes "Oracle has released proprietary extensions to the open source MySQL database, seeming to reinforce the worst fears of those in the open source community who opposed Oracle's acquisition of MySQL in the first place. But open source observer Brian Proffitt urges you not to panic: This dual source strategy really isn't unusual in the commercial open source world, Oracle has already released a bevy of open source improvements to the database, and anyway the EU extracted a commitment to keep MySQL open for another four years when it approved the Sun-Oracle merger."
This discussion has been archived. No new comments can be posted.

Why You Shouldn't Panic About Closed Source MySQL Extensions

Comments Filter:
  • lol (Score:4, Funny)

    by Alex Belits (437) * on Tuesday September 20, 2011 @05:15AM (#37453750) Homepage

    open source observer Brian Proffitt

    lol

  • by unixisc (2429386) on Tuesday September 20, 2011 @05:18AM (#37453758)
    ... after which Oracle will be @ liberty to digest MySQL as closed, and the EU will have nothing to say about it.
    • by d4fseeker (1896770) on Tuesday September 20, 2011 @05:21AM (#37453766)
      And, as with OpenOffice, the community will fork the Database and add a bunch of useful features to it.
      Finally Oracle will either "donate" MySQL back to the community or keep it closed source and everyone will move over to PostgreSQL.
      4 years is 2 Server and, depending on your scneario, 1-3 Software Generations away so let's not panic before Oracle has committed to anything.
      • by Anonymous Coward on Tuesday September 20, 2011 @05:23AM (#37453784)

        Its already forked :)
        http://mariadb.org/

      • by AliasMarlowe (1042386) on Tuesday September 20, 2011 @06:40AM (#37454050) Journal

        And, as with OpenOffice, the community will fork the Database and add a bunch of useful features to it.
        Finally Oracle will either "donate" MySQL back to the community or keep it closed source and everyone will move over to PostgreSQL.

        I suspect the binary-only extensions from Oracle are part of an attempt to prevent that sort of thing. After all, if a large part of the user base becomes reliant on non-forkable proprietary extensions during the next few years, then forking MySQL when Oracle's commitment to keep it FOSS expires would be largely fruitless. Moreover, relying on these extensions may also make it harder to port one's DB and related applications to Postgres or other alternatives. Furthermore, a MySQL donated to the community would be worthless to those who need the extensions (and nothing prevents Oracle from making those extensions quite expensive later). Conceivably, the extensions could even make it easier to port to a commercial DB offering from Oracle, if they are cunning enough.

        For this reason, I'd say Mr. Proffitt is utterly wrong: there is much to worry about in these extensions. Each proprietary binary extension is potentially a poisoned chalice, and should be viewed as such.

        • by znrt (2424692)

          I suspect the binary-only extensions from Oracle are part of an attempt to prevent that sort of thing. After all, if a large part of the user base becomes reliant on non-forkable proprietary extensions during the next few years, then forking MySQL when Oracle's commitment to keep it FOSS expires would be largely fruitless.

          That's an obvious possibility but for now its just "extensions": monitoring and and mostly fancy stuff for enterprise dba. Nothing the big majority of mysql base can't live without (if of any real interest at all). Anyway if your software depends critically on this kind of stuff (or any other propietary candy) then you have bigger problems to worry about than Oracle.

        • I don't think it is as bad as you think.

          The part of the user base that would become dependent on these extensions would be the same users who are already OK with the idea of paying for MySQL. Isn't this a very small fraction of MySQL users? None of the myriad FOSS projects that depend on MySQL would be affected, and few (if any) of those FOSS projects would ever move over to the proprietary version since it would force them to adopt a dual-license model as well (which is darned near impossible to do retroac

          • The only people who get screwed are the people who signed up for the proprietary version up front.

            And, in theory, the only people who get screwed by Microsoft are those who signed up for Windows. But it turns out that if you have a large enough impact on the software ecosystem, you can make life miserable for those around you, even though your neighbors want nothing to do with you.

            (It works that way for actual ecosystems, too.)

            • I fail to see how the proprietary version of MySQL could ever have a large impact on the software ecosystem. The Open Source version will remain free now and forever (as a fork if necessary); there's an excellent FOSS alternative (PostgreSQL); users who are accustomed to paying for DBs will mostly continue to use MS SQL Server, the full-blown proprietary Oracle database product, or DB2 (possibly with a tiny minority of them jumping ship for the proprietary MySQL); and Oracle simply does not -- and will not,

          • by skids (119237)

            The part of the user base that would become dependent on these extensions would be the same users who are already OK with the idea of paying for MySQL.

            The way it works is this: some highly specialized commercial product that you DO pay for decides to use/bundle these extensions. Then your systems department, being innately cowardly, gets uber-paranoid about doing anything at all to MySQL that might affect the stability/suportability of these extensions. Suddenly, magically, you essentially have a closed-source system. Sure you have the MySQL source, but you dare not do anything with it.

            • OK, but under this scenario you're already locked into a closed-source solution anyway (this hypothetical other commercial product). I don't see how something that solution depends on also being closed-source makes things any worse.

              I still fail to see how this move by Oracle represents a serious (or even moderate) threat to FOSS. MySQL has been dual-licensed since day 1. Are people just now waking up to the fact -- 16 years late! -- that whoever owns the MySQL code base is allowed to have their own propriet

        • This sounds like a rather week strategy to me. Presumably anything they can make proprietary extensions do will have an OSS alternative before too long. That having been said, anyone who uses these proprietary extensions knows that Oracle can make them expensive if they want to - so if that really is a problem, they just wont be used.

          I do however share your concern that Oracle will stop at nothing to milk some money out of MySQL - and unlike OpenOffice.org, MySQL is used everywhere by a very large amount of

      • by Tsingi (870990)
        PostgreSQL rocks, and it is the base of PostGIS. It competes on par with the major commercial databases.

        I used msql back in the day, the precursor of MySQL. But never for anything serious.

        It's good to have competing projects, but I think we need to look to a fork of MySQL rather than something that FOSS developers won't want to get behind.

    • They have no good financial reason to support 2 seperate database systems. In those 4 years they'll simply migrate all their paying MySQL support customers to the Oracle DB and once thats done the MySQL codebase will no doubt be quietly forgotten about.

      • If MySQL is still an important part of the FOSS ecosystem by then, interest will shift to MariaDB (or some other fork), and/or someone else will pick up the FOSS version of the MySQL codebase and maintain it. On the other hand, if the majority of the FOSS community is moving on anyway by that point (e.g. to PostgreSQL), then it won't matter if MySQL is "quietly forgotten about".

      • by GauteL (29207)

        "They have no good financial reason to support 2 seperate database systems. In those 4 years they'll simply migrate all their paying MySQL support customers to the Oracle DB and once thats done the MySQL codebase will no doubt be quietly forgotten about."

        I doubt that. MySQL is nowhere near as complete as Oracle, but on the other hand it is considerably simpler to deal with. Oracle will most likely keep MySQL as an "Oracle Light", which doesn't contain all the fancy enterprise features of Oracle, but is quic

        • by jedidiah (1196)

          If you aren't interested in how well it performs, Oracle already isn't that hard to set up. It's not that expensive either.

    • Why do you care since we have MariaDB, which is already better (multi-threaded), and ABI compatible?
  • I just migrated... (Score:5, Interesting)

    by Kagetsuki (1620613) on Tuesday September 20, 2011 @05:23AM (#37453776)

    from MySQL to PG. It was easy. You should do it too.

    • Ah. And how do you convert the duplicate key / ignore inserts? I looked at postgress, but I did not think it was feasible for agile development.
      • by shish (588640)
        I'm using postgres in what I'd consider an agile way -- I guess if you were typing SQL by hand then its strictness might hold you back (it also ensures that your data is valid, which I consider a worthwhile tradeoff), but we've been using an ORM to handle those sorts of details for us.
        • by myurr (468709)

          It's a very worthwhile tradeoff, and something that we rely upon for the majority of our complex projects. Knowing that your data is always integral and internally consistent, enforced by rules in the database itself, is an enabler for rapid development of the various interfaces and processes that interact with that data. Need to use a better tool for the job for one aspect of the system? No worries, interface directly with the same database knowing it won't break anything instead of being limited to acc

      • I converted using some tools and a short guide, it was simple. I'm also using ORM (ActiveRecord), which brings me to your last statement there: "but I did not think it was feasible for agile development." -- So you are doing so much development IN the DB/DBMS you would even consider something like that? Just what kind of development are you doing? (I'm not attacking you here, I'm honestly interested - I touch the DB and raw SQL as little as possible)

      • by rtaylor (70602)

        You can do something like this:

        INSERT INTO (col1) foo SELECT * FROM (VALUES (1),(2),(3)) AS newdata(col1) WHERE col1 NOT IN (SELECT col1 FROM foo);

        This will create a record for values 1, 2 and 3 if and only if they do not already exist.

        Yes, the syntax is considerably longer.

        FYI, the normal process for scrubbing during dataload is to create a temporary table holding the data, massage it there, then insert into the real structure.

        • by TheLink (130905)
          Try it in two different transactions and you'll find it does NOT work.
          e.g.
          -- Do following in psql #1
          begin;
          INSERT INTO (col1) foo SELECT * FROM (VALUES (1),(2),(3)) AS newdata(col1) WHERE col1 NOT IN (SELECT col1 FROM foo);
          -- then this in psql #2
          begin;
          INSERT INTO (col1) foo SELECT * FROM (VALUES (1),(2),(3)) AS newdata(col1) WHERE col1 NOT IN (SELECT col1 FROM foo);
          commit;
          -- Then go back to psql #1
          commit;

          The way to do this without having to rollback is to use locks (postgresql allows locks that don't block a
          • by nabsltd (1313397)

            In addition, the PostgreSQL syntax gets even uglier if you want to insert a new row if it doesn't exist, but update the existing data if it does. For MySQL, it's (parametrized query):

            INSERT INTO sometable (field1, field2, field3)
            VALUES (?, ?, ?)
            ON DUPLICATE KEY UPDATE field1 = ?, field2 = field2 + 1, field3 = SomeComplexFunction(field3,field4)

    • by buchner.johannes (1139593) on Tuesday September 20, 2011 @07:02AM (#37454140) Homepage Journal

      Migrating from MySQL to PG may be easy, but migrating from MySQL to MariaDB is trivial.

    • by vlm (69642)

      from MySQL to PG. It was easy. You should do it too.

      OK I call forth the combined wisdom of /. to advise me how to do this.

      There's gotta be the perfect wiki / website / script / blog / checklist / incantation / whatever for this, right?

      I am completely uninterested in migrating databases at the level of "SELECT name, phonenumber FROM t_phonebook WHERE name=vlm;". I think I can handle that by myself, thanks.

      I am worried about my replication system, my vast collection of weird indexes and their possible expanding obesity on the NAS, my triggers which are mostly

      • by shish (588640)

        I can't (easily) migrate a couple tables at a time from mysql to pg because that would make joins difficult to impossible across the two DBMS, correct?

        Funnily enough, postgres does actually support foreign tables with mysql as a backend.

        For the few migrations I've done. I've found custom scripts to be the easiest way of getting good results -- you're unlikely to find an automated tool that will look at your VARCHAR(15) column and realise that it should be translated into postgres' native "IP address" data type, or that your column of integers represents a number of seconds so it should really be an "interval" type, or that the "lat" and "lon" columns sho

        • by vlm (69642)

          Funnily enough, postgres does actually support foreign tables with mysql as a backend.

          This could work... then I could gradually move them over into native tables... interesting.... I think I'm developing a plan here...

      • by rycamor (194164)

        Having migrated a few applications from MySQL to Postgres, the truth is, it will be painful, but the result is you will be a LOT more confident in the quality and manageability of your data. Start here [postgresql.org]

        PostgreSQL has all the datatypes that MySQL has, and more (see especially the ), and usually with far less limitations. Any character type can be up to 1GB in size if needed, for example.

        The biggest sources of pain will likely come from character set handling (some MySQL oddities there) and MySQL's ready accep

  • because (Score:3, Informative)

    by roman_mir (125474) on Tuesday September 20, 2011 @05:24AM (#37453786) Homepage Journal

    because of postgresql?

  • by KiloByte (825081) on Tuesday September 20, 2011 @05:25AM (#37453792)

    By "keep MySQL open for another four years", they mean "pay lip service to its life support, then on day 1462 stop even that". Sorry, but unless one of independent forks really takes off, I'm not going to even look at something else than Postgres. For that "bevy of open source improvements", what exactly has been added? Heck, MySQL development has been dormant even during Sun days.

    • by mwvdlee (775178)

      How long did it take for LibreOffice to take over from OpenOffice?
      You'll probably see a perfect replacement fork for MySQL the day it's open source life ends.

      • How long did it take for LibreOffice to take over from OpenOffice?
        You'll probably see a perfect replacement fork for MySQL the day it's open source life ends.

        Perhaps the binary-only extensions from Oracle are part of an attempt to prevent that sort of thing. After all, if a large part of the user base is hooked on non-forkable proprietary extensions during the next few years, then forking MySQL when Oracle's commitment to keep it FOSS expires would be largely fruitless. Moreover, relying on these extensions may also make it harder to port one's DB and related applications to Postgres or other alternatives.

        For this reason, I'd say Mr. Proffitt is utterly wrong

        • by idontgno (624372)

          I agree. They're such amazingly obvious traps that you don't even need to be a Mon Calamari flag officer to spot them.

          Any organization inclined to pay for MySQL official support or non-free extensions is probably 3/4 of the way to buying the entry level of full Oracle anyway. Whatever you say about MySQL, the probable market for that strategy already doesn't care about free-as-in-libre and will probably just shrug and open the wallet wider when free-as-in-beer goes away. They've already drunk the kool-aid;

        • Wouldn't anyone who cared about this issue enough to switch to a fork also avoid binary extensions in the first place? It's not as though they are essential to MySQL - or if they are, their functionality will be replicated in forks soon enough.

    • by hholzgra (6914) on Tuesday September 20, 2011 @06:46AM (#37454080) Homepage

      As if PostgreSQL didn't have it's own ecosystem of commercial-only extensions, too (EnterpriseDB, GreenPlum, just to name a few) ... the big difference here is that in the MySQL ecosystem Oracle is the only one that can do such dual-license stunts while in the PostgreSQL ecosystem anybody can ... (whether that's good or bad is a different story)

      For "improvements"/"what's been added":

      * lots of multi CPU scalability work (although part of it came from Google/Facebook and other sources where Sun/Oracle 'just' did the integration work)
      * MySQL Cluster got a *lot* better in Sun/Oracle days
      * the InnoDB plugin improved InnoDB affairs a lot (and this has been Oracles baby even in the Sun days)
      * connectors, e.g. PHP/mysqlnd
      * more interesting InnoDB improvements (e.g. fulltext indexes, finally) are in the queue, how these are going to be licensed remains to be seen though

      It's not that everything is going into the optimal direction with MySQL under Oracle (i'm not working for them anymore for a reason), but saying there has been no development ever since the Sun acquisition is not fair, and i don't see any reason to believe that things will radically change on day 1462 either ...

    • Heck, MySQL development has been dormant even during Sun days.

      And yet it still seems to be the most popular FOSS database, in spite of this. I'd say this is an indication of a mature product that already meets many users' needs. Even if Oracle orphans it, the situation going forward won't be much (if at all) worse than it already was under Sun. Users who had a problem with the stagnation of MySQL have already moved on (or are in the process of moving on) to something else.

  • by eexaa (1252378) on Tuesday September 20, 2011 @05:49AM (#37453866) Homepage

    ...because if you aren't already running some better DBMS, chances are that you are probably generally unable to panic about any DBMS quality.

  • What happens after that fourth year? Pull your head out of the sand.
    • Thats the point - four years is plenty of time to migrate to one of the forks, or off of the MySQL platform altogether.

      If it takes a fork more than 4 years to become viable, chances are its never going to become viable - so start supporting the forks now if you absolutely need to remain on the MySQL platform.

      This whole rigmarole has amused me from the start - there has never, ever been any guarantees that Sun would have kept MySQL going as a commercially supported project (lots of periods with very low rate

      • by rnturn (11092)

        "This whole rigmarole has amused me from the start - there has never, ever been any guarantees that Sun would have kept MySQL going as a commercially supported project (lots of periods with very low rates of activity while Sun was in charge)..."

        I always thought the Sun/MySQL arrangement was odd from the start. I've seen full Solaris installations include a "postgres" user and the PostgreSQL database software (which I was glad to see) so Sun was already working along side an open source database. So what w

  • Free software is about setting minimum levels of respect: the four freedoms.

    Many projects go beyond this, by using copyleft, by assisting community participation, by being transparent, etc.

    By abandoning this standard, Oracle shows itself as just another free software freerider, not to be trusted and not worthy of community support or good will.

    • by pongo000 (97357)

      If only I had mod points...

      You express a thought that is lost on so many here: It's the spirit of F/OSS that is being violated here. You nailed it on the head calling Oracle a "freerider," because that is exactly what they are doing, leeching off the work of others for their own gain (whether present or future).

      If any post sums up this what Oracle is doing wrong, the parent is it.

    • Interesting. Possibly this is a case that demonstrates why BSD/MIT/Apache licenses are superior to GPL? When Oracle acquires a copyright title on a product such as MySQL released under GPL license, they can release closed source mods to the code and convert the community to a locked-in position, whereas no other player can do the same? Everyone but Oracle is "stuck" with a viral license now and so Oracle has a huge advantage in terms of controlling the community with proprietary extensions? Hmm.

      • When a GPL'd project gets bought out, we can end up with one freerider: the purchaser.

        With BSD/MIT/Apache licences, we get lumped with unlimited freeriders, no purchase necessary. That's why companies who aren't interested in freedom put so much work into advocating those licences.

        • So companies who create/sell GPL aren't trying to benefit from freeriding on GPL? Like SugarCRM, Compiere or "old MySQL?" My experience is that (some) GPL software is released by companies who want to specifically prevent other companies from horning in on their business by re-using their codebase in a competitive way (no one but the original rights holder can release proprietary extensions or resell the product under other licenses). Not to start and GPL/academic license debate - but can you point to some

  • VirtualBox (Score:4, Interesting)

    by AdamInParadise (257888) on Tuesday September 20, 2011 @06:24AM (#37453992) Homepage

    In VirtualBox v4.0, Oracle released the core as an open-source projet and the proprietary extensions as a plug-in. This proprietary extension is free for home use but commercial users must by a licence. The extension is not 100% necessary but does provides some very useful features, such as being able to connect to the "console" of a headless VM. Cool right?

    Well, not really. There is at the moment no way to actually buy such a licence from Oracle, so all the people using VirtualBox v4.0 with this extension in a business are technically out of compliance.

    VirtualBox is cool, but they really need some leadership from Oracle.

    • by Jahava (946858)

      In VirtualBox v4.0, Oracle released the core as an open-source projet and the proprietary extensions as a plug-in. This proprietary extension is free for home use but commercial users must by a licence. The extension is not 100% necessary but does provides some very useful features, such as being able to connect to the "console" of a headless VM. Cool right?

      Well, not really. There is at the moment no way to actually buy such a licence from Oracle, so all the people using VirtualBox v4.0 with this extension in a business are technically out of compliance.

      VirtualBox is cool, but they really need some leadership from Oracle.

      The VirtualBox guest extensions were released under the Oracle PUEL [virtualbox.org]. IANAL, but the PUEL itself doesn't seem to say what you think it says.

      The actual PUEL [virtualbox.org] seems to center around the following restriction (emphasis mine):

      2 Grant of license. (1) Oracle grants you a personal, non-exclusive, non-transferable, limited license without fees to reproduce, install, execute, and use internally the Product a Host Computer for your Personal Use, Educational Use, or Evaluation. “Personal Use” requires that

    • The OSE edition of VirtualBox includes a VNC server (as opposed to the RDP server included in the proprietary extension) that provides similar headless console functionality. The VNC feature appears to be disabled in the binaries they distribute, but is available as a compile-time configuration option if you build from source, or (I believe) enabled by default if you install from your distro's repository.
  • by nzac (1822298) on Tuesday September 20, 2011 @06:33AM (#37454016)

    I would think most distros will have policies that will make this a second class DB or drop it entirely. It rules it out of Debian for the next release, openSUSE will drop it to non-oss, gentoo wont like binaries and so on.

    Having to go the Oracle website to get it would put off the majority of new non-commercial users or anyone wanting automatic update notification.

    • I think just the enterprise features won't be available. So developers won't use them if they can avoid them. What's more, you would have to have an "enterprise" licence for each developer and test machine. Ouch!
    • by hholzgra (6914)

      Does it rule out PostgreSQL from being released with Debian as there are commercial/non-oss extensions to it like EnterpriseDB?

      Sure, the non-GPL "Enterprise Edition" will not make it into any distribution, but for the GPL edition licensing would not be the reason for not distributing it any longer (although other reasons may lead to one of the forks becoming the default and Oracles GPL version only an alternative, but this will for sure be not for license reasons alone if/when it happens ...)

      • by nzac (1822298)

        You are right the the core is still good (so I guess GP was alarmist) but the moment new releases are not GPL it will be rejected as foreign by a lot of distros*. Yes there are some that wont care as well i guess.

        Forking mySQL is not as likely as OO as there are other alternatives that could be work on instead and will not have the trademark.

        openSUSE has switched java versions due to lack to openness.

    • Ummm... what? Debian has no problem distributing dual-licensed code, as long as one of the licenses (the one which applies to the version in their repositories) is GPL-compatible. Oracle can't "take back" the GPL-licensed version, so where's the problem for Debian?

      • by nzac (1822298)

        Well it appears there is still at least 4 more years for the base package. I should read the article and the extent of the extensions. But that does not change that some distros might use this as an excuse to drop the oracle product from first class support and the default install.

        Unless half the dev team defect there will be no devs able to release patches and security updates let alone new versions so it falls behind and will be less secure. There are no patches to from upstream.

  • a commitment to keep MySQL open for another four years

    If four years are rated a long time I wonder about the implications regards short term memory, assuming a universal scaling factor.

    CC.

  • You can trust Larry Ellison without question.
  • I don't use MySQL. I use MariaDB. I've looked at Drizzle too. Drizzle is "for the cloud".

    For all practical purposes, MariaDB is a binary drop in replacement of the same MySQL version (for example MySQL 5.1 -> MariaDB 5.1, MariaDB 5.2 & MariaDB 5.3 are compatible. MySQL 5.5 will be compatible with MariaDB 5.5). http://kb.askmonty.org/en/mariadb-faq [askmonty.org]

    Please help fund MariaDB.

  • After the release of Postgresql 9.x. MySQL has no place, period. MySQL can't even get UTF-8 right. Bug laden transaction support. TS engine? CRAP. Trash OO wannabe. If you do not need the features, then use mongo or couch. I don't know why anyone would use it knowing Postgresql exists.

    mysql = java = sun = oracle = trash

    • Love it - great post. I'm on this boat too. If your shit is so simple you just want a pile of data in a real fast container, use couch or mongo. If you want SQL b/c you need SQL use Pg. That is all.

  • The proprietary extensions were there before, all the way back to mysql ab. You just had to pay for them before.

    From the article, they are enterprise monitor and enterprise backup. Backup at least has been reimplemented by percona as xtrabackup.

Luck, that's when preparation and opportunity meet. -- P.E. Trudeau

Working...