Slashdot Mirror
Sun May Begin Close Sourcing MySQL Features
An anonymous reader writes "From the MySQL User's Conference, Sun has announced, and former CEO Marten Mickos has confirmed, that Sun will be close sourcing sections of the MySQL code base. Sun will begin with close sourcing the backup solutions to MySQL, and will continue with more advanced features. With Oracle owning Innodb, and it being GPL, does this mean that MySQL will be removing it to introduce these features? Sun has had a very poor history of actually open sourcing anything."
Guy n Gals.. Lets just fork the thing.., then we can call it iSQL
Where have you been? Java source code has been available for a long time but after years of people complaining that it wasn't "free enough", Sun fully released Java under a GPL 2 years ago.
OpenOffice not really GPLO.K. so it's LGPL So what, so is Gtk, most of GNOME and probably 80% of what you and joe-sixpack considers to be "opensource" in "Linux". GPL is just one license. GPL was never fully tested in court and doesn't provide patent indemnity as CDDL does. I'd be happier if Java, OpenOffice and MySQL were CDDL but there would be too much gnashing of teeth from the Linux creationists.
OpenSolaris i dont know enough aboutOpenSolaris is licensed under CDDL. Look here for an FAQ which explains in simple terms why CDDL is superior to GPL.
But this is pretty much the end.
You need to get a grip and possibly read for yourself what this is.
Sun is saying that they may (not yet decided) offer some add on components to mySQL backup that may (not yet decided) use a license other than GPL. The add on in question will be integrated through a backup API mySQL has for exactly this purpose (to enable 3rd party extended backup solutions).
What exactly do see wrong with that? First, nothing precludes building open source backup solutions for this API and nothing precludes other 3rd parties from building other solutions. Why should Sun not have the same right?
]{
Alternatively, here's what I do in phpPgAdmin: click Table, click Triggers. There's a list. I can edit it by clicking on a specific trigger. phpMySql has no such interface to triggers, and every view, creation and edit must be done by manually typing in the SQL (but, based on the tone of your reply, I'm sure you knew that). Maybe you have time for that, and it's not a big concern (on what terms do you get paid?). For any serious database development, it strikes me as a grotesque waste of time. I mean, seriously, the CREATE TRIGGER statement is not rocket science. Nobody implied that it was. However, complex trigger statements are what beget the necessity of being able to edit them handily- something that I would imagine you couldn't do with a WYSIWYG (exactly what would a WYSIWYG TRIGGER editor do, anyway?). Wasting 15-20 minutes typing the SELECT/CREATE/ALTER TRIGGERS statement in another editor and then running a blanket update over the whole SQL database strikes me as fundamentally wrong, especially where there is a trivial and effective interface in phpPgAdmin. Besides, creating them programatically is just better business. I can keep a db_setup_triggers.sql in source control and make it part of automatic builds. Who ever suggested or implied that you wouldn't create them programatically? Please, feel free to describe how else you would do it. MySQL is far from perfect. But to criticize it for THIS? I think you're fundamentally confused about what I was criticizing, meaning you either did not take the time to read my comments, are ignorant of MySql/phpMySql, and/or didn't take the time to think about either before you started ranting. If that be the case and you are fundamentally confused, you've contributed little if anything to the discussion, sounded condescending, acted presumptuously, and been indignant about something that does not even exist (a criticism about the lack of a TRIGGER WYSIWYG, the very suggestion of which reeks of ignorance). If indeed that is the case, next time you consider writing something, perhaps you could do us all a favour and not.