MySQL and SCO Join Forces 516
matchboy writes "CNET is reporting that MySQL and SCO have signed a partnership to work on "joint certification, marketing, sales, training and business development work for a version of the database for SCO's new OpenServer 6 version of Unix." Why would MySQL decide to work directly with a company that has deemed the GPL as unconstitutional?"
Uh - Best of Both Worlds? (Score:5, Interesting)
Why would MySQL decide to work directly with a company that has deemed the GPL as unconstitutional?
Maybe because MySQL doesn't have a dog in this fight?
Blackballed (Score:2, Interesting)
That Answers My Question (Score:5, Interesting)
Giving SCO more rope to hang themselves with? (Score:3, Interesting)
That being the case, is there any chance that IBM could pick up on this and run with it in their case vs SCO?
"look here judge, SCO says the GPL is evil and unconstitutional but they're partnered with a company which uses it."
Re:Uh - Best of Both Worlds? (Score:5, Interesting)
The mysql dual licence was actually hiding a deeper schizophrenia that has just now showed itself. Apparently, they never believed they could really make enough money with GPL'ed software, so now they are doing this.
I'm not sure what the moral of the story might be yet, but quite possibly it is: Beware of what lurks behind the dual licence.
Re:MySQL may be next target of SCO lawsuit (Score:2, Interesting)
Teacher/MySQL champion... now in crisis... panic! (Score:4, Interesting)
I think postgreSQL should change their name to something I can store in my mind without having to "/// ||| \\\" the damn word (if you catch my subtle meaning).
When I first looked at this story, I thought that maybe SCO was trying to buy-in some street cred, but all they have done is ruin MySQL forever, IMHO.
You sleep with dogs, for profit, you deserve to get flees.
MySQL, Qt, and Other Lock-In Scemes (Score:5, Interesting)
Another product that uses the GPL + proprietary lock-in licensing scheme is Qt, by Trolltech. They also use their GPL'd edition as a loss-leader, in order to promote sales of the proprietary edition of Qt.
Note that MySQL and Trolltech are both partly owned by Index Ventures. They also own a piece of Skype. See http://www.groklaw.net/article.php?story=20050524
Index Ventures bought into Trolltech at about the same time that SCO ended its partial ownership of Trolltech. Prior to that, SCO Chairman Ralph Yarro, one of the engineers of SCO's attack on Linux, also sat on Trolltech's Board of Directors.
Any Linux supporter who isn't nervous about this rats nest, and who doesn't wonder about possible Microsoft involvement, given their connection with SCO, is being naive.
What it comes down to is this:
Even those who trust MySQL and Trolltech must realize that their GPL + proprietary licensing schemes lead to future lock-in, and should be avoided for that reason alone.
If you are a MySQL user, and you care about the future of Open Source, you should be looking at alternatives, such as PostgreSQL.
And if you are a KDE developer, and you care about the future of Open Source, you should be looking at porting KDE to other platforms, so you are not dependent on just Qt. Besides, Qt's licensing scheme is limiting your success. You can start by simply layering the KDE code (similar to what Apple did with Konqeror in order to create Safari), which is a good thing to do anyway.
And everyone should be watching out for long term hooks. Remember the early nineties, when the PC was an open platform, that used open, documented hardware interface standards. But then Microsoft introduced Windows, and "free" developer tools, which they gradually used to turn the open PC platform into one which would only run with Windows middleware. All the open PC hardware interfaces were turned into secret interfaces, requiring custom drivers that only worked with Windows.
Microsoft was able to take over the open PC platform because of what is called "network lock-in." This occurs due to the fact that Windows is middleware, which sits in between the PC platform, and the applications that run on top of it. The applications need Windows in order to talk to the PC hardware, and the PC hardware needs Windows in order to talk to the applications -- nobody can move away from Windows without losing access to everything else, hence the network lock-in.
Just like Windows, MySQL and Qt are middleware, with the same potential for network lock-in. Proprietary (non-GPL'd) applications that run on MySQL and Qt depend on them for access to the OS (Linux), and, because they use the proprietary licenses, they don't have the Open Source protection of being able to fork MySQL and Qt.
Think carefully about the future, people. Don't let the astroturfers, and slick salespeople lull you into a false sense of security. Pay attention to how your software is licensed. Pay attention to any dependencies your software has on other software. It's the start of the nineties all over again, and you currently have an open platform, with all the commodity benefits that will bring. You don't want to be foolish and short-sighted, and lose it again.
MySQL is smart (Score:3, Interesting)
Why would MySQL AB work with them? Because SCO's dollars buy as much as anyone else's dollars. MySQL hasn't changed its license from the GPL. If it did, I'd stop using them, and so would many other geeks/nerds out there. Hold your horses. McBride may be a major-league asshole, as our President would say, but that doesn't mean SCO Group as a whole is. With their cases losing ground, they've begun to actually make some innovations. Maybe it's like the early evolution of our species. We were very few and far between living in a desolate climate (deserts in Africa) and therefore Homo sapiens adapted ways of surviving. SCO seems to finally be doing this. I don't favor the company for their stupid litigation, and I think they are still a dying company, but perhaps they will turn away from Satan and find a balance between commercial software and free softawre. One can hope, anyway...
Of course, I wouldn't put it too far out of probability that SCO will accuse MySQL AB of violating trade secrets and breach of contract. Who knows...
Switching to PostgreSQL because of this is silly (Score:3, Interesting)
Re:Just use PostgreSQL... (Score:3, Interesting)
Nick
MySQL AB is an evil company (Score:1, Interesting)
They rode the open source wave but have changed their ways.
They used to release client libraries as LGPL to allow third party developers to connect to MyQL.
Now the C library is GPL, along with the protocol, forcing all non-GPL-friendly licenses (or those wanting to retain their source) to purchse a commercial license, which is over-priced for the MySQL "RDBMS".
They snagged up the most popular Java connector, and changed the license from LGPL to GPLfor the same reason.
They also aquired the Byte.FX
To circumvent GPL's deficiencies, they enacted the FLOSS exception for GPL compatible licenses, provided the source is available.
So they take open source projects and turn around to force money from the developers who aren't GPL/RMS Kool-Aid drinkers.
Amazing how a crappy databse back in the 3.x days gained so much ground, having no true RDBMS features and just simple ISAM-based tables. There were plenty of much better alternatives, but MySQL successed soley because of it's driving front-end, PHP, which is a a whole 'nother post.
Re:One question? (Score:3, Interesting)
People tend to try to make a word out of any acronym they have to use regularly, it's generally easier to say.
Re:WHO CARES (Score:5, Interesting)
Sitting here bitching does a few things. It allows MySQL users a chance to vent a little; it gives MySQL a means to judge user reactions to their collaboration with SCO (they had to expect controversy) and it gives users who might have been unaware of the issues useful information when deciding whether to deploy MySQL. And it gives supporters of MySQL a chance to put the other side of the story.
This is a discussion forum. The point is to discuss issues like this. A lot of that discussion, the side of it that you disagree with, is going to sound like "bitching".
Most of what you say is useful, but STFU is never helpful.
This sort of thing... (Score:3, Interesting)
Although Postgres [postgresql.org] is unfortunately a bit bigger, (the elephant isn't its mascot for nothing
It is unfortunate that MySQL AB have shown such lack of vision in the past couple of years...but methinks they're probably about to find out that commercialistic shortsightedness carries its' own reward:- Eventual irrelevance.
MySQL perform any worse... Ha! (Score:1, Interesting)
After recently building a new Snort-based IDS machine, logging to a MySQL database as my very first adventure into the world of MySQL, I find it hard to believe that MySQL can perform much worse. It's a dog. Once I had 800K event records logged to the database, it totally fell on it's face. Queries were taking 3-5 minutes to complete... even on well-indexed tables. Seriously, I do not understand now what all the hub-bub was about that MySQL was supposed to be some kind of lightweight nimble database. It ain't. It sucks when you try to scale it beyond "toy" sizes. I switched the machine over to become a "Winsnort" box, and logging to an MS SQL server and now I'm getting fairly decent performance, but still not good enough. 800K records is not a "huge" database by today's standards... in fact it's rather small. My next experiment will be to log to an Oracle database to see if I can get some decent Snort/BASE perfromance.
Re:It's simple (Score:2, Interesting)
If someone is a MySQL fan, they may regard this as a troll, but hey. MySQL has long been criticized as both a database and as an organization by many other people besides me.
Plus, they'll never live down their discouraging remarks about foreign keys in the old MySQL manual.
Re:It's simple (Score:3, Interesting)
In SQL NULL represents the the absence of a value. In MySQL an explicit NULL may also represent the next value of a pseudo-sequence and an implicit NULL may represent an implicit default value (a zero or empty string) determined by MySQL. See here [sql-info.de] and this Wikipedia article [wikipedia.org] for more info.
Why do think that this is better? In one case you call the function and then use the value, and in the other case you insert the row and then ask what the new PK is. I'm not sure how one is better than the other. Could you explain?
If you're wanting to know your next ID number before inserting data, you're screwed in MySQL. MySQL uses "auto_increment" fields that just add one to the previous row's value, while PostgreSQL uses what are called sequences which are guaranteed to always return a unique value, and you use those for your ID fields. In MySQL, there's no way of finding out the next value in an auto_increment sequence until you've committed a row to the database, while PostgreSQL lets you peek at the next value in the sequence.
Details please? I'm not trying to pick on you here. I'm just trying to figure out what your complaint is. The MySQL manual is huge, so you can't expect everyone to know what you're talking about.
Here you go. [univie.ac.at] The old manual criticized foreign key constraints and transactions using bizarre reasoning.
For what it's worth, MySQL has some features that we really love, like the binary logs. We have yet to lose a single row because of database corruption.
The issue with MySQL isn't database corruption, it's data integrity. A lot of things in MySQL will happen and not give you any warnings, whereas other databases are very strict about giving you a warning or even refusing the statement with an error so you can respond to it in your code. There are an alarming number of conditions where MySQL inserts things like zeros into fields without telling a single thing. You can't fully trust MySQL.
Re:It's simple (Score:3, Interesting)
I find the NULL argument kind of interesting. I was expecting something like "it doesn't work right when you sum or average". Again, I'm more than happy to let MySQL pick a default value for me if I didn't provide any. I guess that I just don't find it unreasonable that if I don't provide a value for a char/varchar/text that it'll just default to an empty string. Of course you're talking to a guy who thinks that PHP is great because "" == 0 == false.
I'll admit that the first item on the "broken foreign key" list is a little lame. The thing I find with foreign keys is that they have to be used with care. With a given subsystem, foreign keys are great. Where I tend to push back is when they cross subsystems, even when they're valid. The reason that I say this is that I once worked on a project where we had three distinct entities, and we decided that we should be able to modify the code for each of these independent of one another. When I proposed that we break a few FK relationships so that we could break apart the code, I immediately received pushback from the DBAs. I certainly understood their concern, but I didn't feel like they were looking at the bigger picture. Anyways, I lost the argument and the project died, in part because we couldn't fix the problem. (On a related note, I feel the same way about stored procs. There are times when you really need to have them, but the associated penalty is that version control virtually goes out the window. Every time I tell a DBA that I'll use stored procs when they can tell me how to version the code, they walk away without an answer. For as much a DBAs expect developers to work with them to make the database better, it's not unreasonable for developers to ask DBAs to meet their time-tested standards for good code development.)
I guess in general there are two ways to look at the world. One is to trust that everyone knows what they're doing, and what you risk is that something will snap you in the ass later on. (I freely admit to spending time tracking down misspelled variable names in PHP because there is no equivalent to "option explicit".) The other is to trust no one and validate every piece of data that comes your way. I prefer the former, you (appear to prefer) the latter. Each is valid, depending on how you view the world.
I do have one follow up question for you. You mention that you don't like having to get the PK after an insert into an auto_increment field, but I still didn't see any reason why this system doesn't work. Do you have an example where it's necessary to get the PK before the insert? Or is this just a matter of preference?