Slashdot Mirror
Is MySQL Planning a Change of Tune?
Iggy writes "After reading the article on 'The MySQL License Question' by Timothy R. Butler at Open for Business I just have to wonder, is this company's wording on the MySQL site indicating the company is backing away from Free Software, specifically, the GPL? Great reading and certainly thought provoking."
did Xfree/X.org teach (or even remind) them nothing?
fools! those who do not learn from history.... etc.
Couldn't anyone create their own fork from the last GPL'd source?
Shh.
If a prorietary software vendor wants to package MySQL with their product I'm glad MySQL AG is getting a few bucks out of it.
It doesn't seem to negatively affect the free software developers.
I've always liked the idea that you could release a product under a Free license but keep the option to sell versions to companies as well.
I realize that this doesn't answer the question of whether the GPL itself allows this kind of dual license but it seems to me that TrollTech does something similar and that has never bothered me either.
Waltz, nymph, for quick jigs vex Bud.
You just named the fork.
CAn'T CompreHend SARcaSm?
Someone help me out, i've poked about in the GPL and *think* i understand what it means, but what happens when:
a package is released GPL style, then the devs decide that's not exactly what they wanted and decide to change the license....er, what happens then? Are the old versions still under GPL? Is the new code, regardless of the newly chosen license still bound to the GPL since it's based on the older code? What about re-writing all the code new - that wouldn't be covered, but how close is too close to the old code?
This article just made me wonder a few things, someone help me (others) out here.
you know nothing about programming I see...
The Blender community that bought the sourcecode to Blender was able to get exactly ONE developer that knew anything about it and they turned blender into a product that surpasses anything that NAN could have hoped that Blender could have become.
programmers with an itch and are pissed off by stupid corperate tricks can outprogram the highest paid code jockeys on this planet easily.
that's just one example, there are more out there I just can not think of them right now.
Do not look at laser with remaining good eye.
This was fun! It kinda makes me want to write a timeline of when MySQL developers would publicly and loudly assert that certain features were not needed and compare it another timeline that proudly announces the formerly useless feature in their newest revision.
Might be as much fun as reading the MySQL gotchas pages. "Foreign keys only serve to slow database engines down." Wait a couple of years... "MySQL 4: Now with new enterprise features like foreign key support!" Wash. Rinse. Repeat.
Those who forget the past are doomed to extended use of a debugger.
- I don't need to go outside, my CRT tan'll do me just fine.
The issue is that the information MySQL AB puts on their site advising people about which license to choose isn't entirely in sync with what the GPL really states. Basically, MySQL AB is trying to scare businesses who weren't planning on violating the GPL into purchasing a commercial license of MySQL just incase.
This even comes out in the article when they talk about applications that talk to a MySQL database but don't actually link against any MySQL (or other GPL) libraries being a gray area. There is no gray area in sight on this issue - if there is no mixing of code, the license is not applicable and there cannot be a GPL violation.
MySQL AB's assertion here is akin to their claiming that you're running dangerously close to violating the GPL when you develop commercial software that runs on GNU/Linux. Yes, your app speaks to GNU software constantly, depends fundamentally on it, and is completely useless without said GNU software, but nobody is claiming you're anywhere near violationg the GPL. It's a pretty damn hypocritical argument for them to make, too, since there is a build of their software that runs on (works closely with) GNU/Linux that they do not release under the GPL. (I consider the GPL and commercial versions of MySQL to be different products because they admit there are minor differences between the two due to licensing issues with the libraries MySQL depends on.)
I understand that MySQL is trying to secure a profit for themselves, but doing it by scaring folks away isn't going to help very much. They'll get more chance of a profit from me by putting out an effort to implement all of the features a lot of corporate users have come to expect from a bunch of their competitors and being a bit more well-behaved in terms of SQL standards compliance, thus making potential business customers more interested in tightly coupling applications with MySQL in the first place.
This whole topic reminds me of question to which I've never gotten a good answer.
One of the supposed benefits of Open Source in general is that lots of people can contribute, add features, fix bugs. This includes the GPL.
GPLed code and GPLed contributions stay GPLed forever.
MySQL is GPLed. MySQL sells a commercial license. Do you really believe the commerical version of MySQL has ZERO GPLed contributions to it? No bug fixes from anyone outside AB? No feature additions from anyone outside AB? While I admit it's remotely possible, if there are no outside contributions to MySQL then what's the point of it being GPLed? If there are then it's illegal for them to redistribute a version of MySQL with the GPLed contributions in it under some other license.
Correct me if I'm wrong, but aren't the client libraries licensed as GPL?
This makes it difficult to develop an application with MySQL support, even under a FOSS license like the BSD license, without paying for a commercial MySQL license. Merely providing a MySQL database driver seems to violate the GPL if the application is not GPL.
As I understand it, this is more restrictive than even proprietary databases. As evidence I point out that PHP includes many database drivers (proprietary and FOSS), but does not bundle the MySQL one anymore.
Also, it creates a significant "grey area" when your language of choice (e.g. PHP) provides a driver. Must the PHP app then be GPL as well?
Am I being confused by FUD or are these real points of confusion and concern?
I am really only concerned with the client libraries. I'm certainly comfortable with the server itself being GPL, and I am grateful to MySQL AB for contributing so much code in a FOSS license. Client libraries are often LGPL, and it confuses me when MySQL AB does not follow that norm.
Social scientists are inspired by theories; scientists are humbled by facts.
I know what I'm talking about.
e d patches [FSF-style or MySQL-style]) -- then he can do whatever he wants with the code, BECAUSE IT's its property. But if he accepted a lot of outside patches, whithout copyright weavers (linux-the-kernel style) he would need the authorization of the patch owners OR he would need to reverse all outside patches (if possible -- in the case of linux, for instance, this is not really practical), or else he would be bound by the GPL because the current work is a derivative work on the GPL'd patches.
1. are the old versions still under GPL?
A. yes.
2. is the new code still bound by the GPL?
A. this depends on who is the copyright owner of the last GPL'd version. if the original copyright owner (the original package owner) is the SOLE copyright owner of the last GPL'd version (as in: he did not accept any outside patches, or if he accepted only copyright-releasing-by-writing-signed-and-notariz
3. how close is too close?
A. to be completely untainted, he would have to write down the complete spec to the work (in English, for example) and would have to get another person -- who had not seen the source code previously -- to re-write it in some programming language. this is what is called clean-room reimplementation.
HTH,
Massa
It's better to be the foot on the boot than the face on the pavement. ~~ tkx Kadin2048
Would you be so gracious as to say why?
;)
... but twenty years from now, you'll probably have /.ers hashing it out over these competing memes.
Since yours is the only non-flame response I've received in the thread, sure, I'll be glad to.
1. Documentation. MySQL's documentation is so much better than PostgreSQL's, there's just no comparison. If there's something I want to do in MySQL that I don't know how to do (which doesn't happen very often these days; I will certainly grant that there's less to learn with MySQL than with a fuller-featured DBMS) I can almost always find out with a few minutes of searching. PostgreSQL's docs seem to have been written by people who take positive joy in making things as obscure as possible. Most commercial DBMS documentation seems to have been written by people who were getting paid by the word.
2. I like MySQL's command-line tool better than everyone else's. [shrug] This is a matter purely of personal preference, I admit.
3. There's no shortage of host language support for either MySQL or PostgreSQL; both have it better than most commercial systems seem to.
4. Speed. Many, many people will tell you that MySQL isn't "really" faster than other DBMS's, and come up with elaborate justifications for why this is so. As far as I'm concerned, they're akin to those who insist that [Linux | BSD | OS X] isn't "really" more secure than Windows: real-world performance proves them wrong.
Do the limitations of MySQL bother me? Sure; every once in a while I grit my teeth at having to write multiple queries, using temp tables and the like, to have to simulate nested queries and views. The lack of stored procedures and transactions can be dealt with in host language apps, but again, it can be a pain in the ass. But for me, the advantages I listed above outweigh all of these problems. Also, I'm willing to wait for the MySQL team to add in the missing features, one at a time, because based on past performance, I have faith that they'll do it right.
Roughly speaking, it seems to me, MySQL and PostgreSQL have followed opposite but converging development paths. The MySQL approach was to start with a very limited feature set, make it fast and easy to use and capable of running on a wide range of systems, and then add features in one at a time, making sure nothing breaks as they go along. The PostgreSQL approach was to start with everything and the kitchen sink, and then work on problems with speed, interface, and cross-platform compatibility.
For F/OSS projects in general, with limited resources to throw at the problem, I don't claim that either approach is better -- just different, is all. And like I said, at this point they seem to be converging
The correlation between ignorance of statistics and using "correlation is not causation" as an argument is close to 1.
> I've been reviewing and making infrastructure architecture recommendations for 6 years. My
> experience has been that the people who can demonstrate scale and efficiency tend to choose
> systems that do not bottleneck the database. I have used mysql, postgres, as well as oracle.
> Generally people say that mysql is limited in
features, but is that a bad thing?
Well, first off I think most complaints about msyql aren't about performance. It has fine read performance, though concurrent write performance seems poor. Haven't been able to run any benchmarks to prove that, just what I'm observing and hearing. MySQL is strangely silent on TCP-Cs. But for many small apps - the performance is good enough. The real problems are licensing, silent errors, non-compatible sql, etc.
yes it's a bad thing - since they aren't complaining about features - like a cup-holder in a car. They're complaining about features like a standard 12v electrical system in the car:
- least portable sql of any common database
- lack of support for basic, 20 year old database features like views
- transactions only available thru third-party product, not seamlessly integrated in mysql, often fails to work silently (!)
mysql ab has often stated that transactions (!), views, subselects, triggers, stored procs are unnecessary for 90% of the users out there. This is deliberate misinformation. Sure, you can live without stored procs, and sometimes triggers. But subselects? views? transactions? Heck, even a simple bowling-score hobby database should use transactions - implementing transactions in your application is *far* simpler than dealing with corrupt data!
> Can someone with the deep experience (in both systems), and some spare time, please create a feature/fault matrix for both production and
> development versions of mysql and posgres and submit the link as a reply? It wouldn't hurt to throw in oracle/DB2 to see what repaying for your
> software every year gets you.
Please, doing that for postgresql, mysql, oracle, and db2 (and for both dev & prod versions) at any level of detail would be extremely time-consuming. The ideal technique here is to score the solutions based upon very low-level critieria (support for super-groups in sql, etc) then roll it up. Since each product does some things a little differently you're looking at 200 hours to pull this off.
This kind of task, along with performance benchmarks (tpc-c & tpc-h) are often done for very large projects. Maybe we'll see at least some benchmarks come from a hardware manufucturer one of these days. Or mysql if it felt that it was mature enough to compete with the commercial databasees - then it would spend some of that investor money to prove it.