Is MySQL Planning a Change of Tune? 403
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."
No, they're just confused by the legalese (Score:3, Funny)
Re:No, they're just confused by the legalese (Score:5, Insightful)
MySQL AB Comments (Score:5, Informative)
Thanks for all the feedback!
Let me here present the background logic behind our licensing policy and software policy in general.
MySQL AB is probably the world's largest company that has published all its software under the GPL licence. Over the years we have expanded and developed the business that David Axmark and Michael "Monty" Widenius started in the 90's.
Thanks to our business model, we have been able to hire more developers and make more code available under GPL. For instance, last year we acquired a highly advanced clustered database from Ericsson which we made available under GPL for the free and open source software (FOSS) communities in the world. Monty and David continue to be in the driving seat in these issues.
While being fully committed to FOSS and to GPL, we get more and more enterprise customers who want us to provide commercial licences and commercial services. They also want easy guidelines on open source licensing and when to do what.
In our attempt to make open source licensing easy to understand for enterprise customers who know little about the topic, we clearly have stated things that have upset those who know the licensing in detail. My apologies for this.
I hope you will have understanding with this, and that you will appreciate that we listen to you and make changes as we go. For instance, a misfortunate wording regarding "distribution" and more specifically "internal distribution" has now been removed from our licensing pages.
But more feedback is welcome, because open source licensing just is not easy to explain. If you have a better wording than we have come up with, please let us know.
It is interesting to debate licensing issues, and we do want to do it right. At the same time, we continue to experience that most practical situations are for the most part clear. FOSS projects and use of MySQL clearly falls under the GPL, and enterprise customers invariably want a commercial relationship with us. There undoubtedly is some gray zone, but it is not enormous, and we do all we can to sort it out.
I'd say that our FOSS Exception (which admittely took time to author) is a great example of removing gray zones and impossible situations. Some open source licences are by definition incompatible with each other, but with our FOSS Exception we have made sure that MySQL under GPL can live side by side with open source software of other licences.
There is much more to write on the subject, but I will stop for now. Feedback continues to be very much welcome - publicly or directly to me (I am sure you can guess my email address).
Marten Mickos, CEO, MySQL AB
P.S. Sometimes I see comments about our VC financing and where that may lead us. Here is some info for the interested reader: We brought in some 13.5 million euros last year in venture funding. As of today, we have barely touched the money. We are growing fast, but we don't want to grow too fast and risk losing the unique culture of our company. Monty and David and the other founders continue to be the biggest owners in the company. And to be on the safe side, we have made sure through a shareholders agreement that all shareholders stay committed to our open source / free software philosophy. I would claim that MySQL AB could serve as an example of how open source and VC funding can work well together. And I hope the world will see a whole armada of successful open source businesses in the next years. The market is in need of disruptive technologies, and this community has them.
Re:MySQL AB Comments (Score:5, Informative)
The only valid complaint here is that your marketing person claimed that connecting to the database via a socket was a "grey area" in regards to linking. It is not a "grey area", and never has been - doing so makes the client no more of a derivative work then IE is a derivative work off Apache. Claiming otherwise is downright deceitful.
Re:MySQL AB Comments (Score:5, Informative)
Thx for the comment. We (MySQL AB) are not the judge on this. Therefore we are careful not to make statements that may be oversimplifications, as that may mislead our customers. Our comment on connections was based on the GPL FAQ on FSF.org:
http://www.fsf.org/licenses/gpl-faq.html#MereAggr
It says this (boldfacing by me):
"What constitutes combining two parts into one program? This is a legal question, which ultimately judges will decide. We believe that a proper criterion depends both on the mechanism of communication (exec, pipes, rpc, function calls within a shared address space, etc.) and the semantics of the communication (what kinds of information are interchanged)."
and this:
"By contrast, pipes, sockets and command-line arguments are communication mechanisms normally used between two separate programs. So when they are used for communication, the modules normally are separate programs. But if the semantics of the communication are intimate enough, exchanging complex internal data structures, that too could be a basis to consider the two parts as combined into a larger program."
But, again, lets remember that only a court of law can take an affirmative position on this. FSF and MySQL AB can only provide their best advice and their presentation of their intent.
Please also note that we are very happy when our users use MySQL under the GPL (as
I hope this sheds some light on our logic. Many people look to us as the foremost authorities on the GPL. But that's not what we are. We are a software development organisation that provides software to the FOSS community and to commercial users, and that provides additional commercial services to the commercial users. We hope we can be a role model for other open source developers who want to stick to their FOSS principles and ALSO build a great and lasting business.
Marten
Re:MySQL AB Comments (Score:5, Interesting)
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.
Re:MySQL AB Comments (Score:5, Informative)
The client libraries are licensed under GPL.
In addition we have issued a FOSS Exception which states that you are free to mix our client libraries (under GPL) with other FOSS licensed stuff, such as PHP.
Marten
Re:MySQL AB Comments (Score:4, Informative)
Briefly:
* we have had tremendous benefit in the enterprise market of just having the money (not using it)
* we have got great value out of our VCs (advice, introductions, etc.)
* any company will need cash reserves for unforeseen situations and for being able to act fast if an opportunity emerges
* as we continue to expand, we will be making investments out of the funding we received
Re:No, they're just confused by the legalese (Score:3, Insightful)
First Useful Post (Score:3, Insightful)
Re:First Useful Post (Score:5, Funny)
Brings to mind a question.... (Score:3, Interesting)
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
Re:Brings to mind a question.... (Score:3, Insightful)
Where this gets dicey, though, is if MySQL contains any code which is owned by someone else. For example, if I make an improvement to MySQL, and
Re:Brings to mind a question.... (Score:4, Insightful)
Isn't FSF's asking people to give them the copyright just the same as MySQL does, the only difference being thar MySQL is a commercial entity?
Email the FSF (Score:3, Informative)
Re:Brings to mind a question.... (Score:5, Interesting)
I'll give you my reading, because the other followup didn't catch all your questions:
You are welcome to license your new versions or the same version under licenses other than the GPL, because the GPL is non-exclusive. You can re-license the original code to yourself, if you feel like getting that far into it, under any license you like. What you cannot do is revoke the GPL rights on copies already distributed. This parallel licensing, where projects are released under the GPL and then sublicensed to private entities under non free licenses in exchange for bling is probably ( imho ) the best way to make money on a free software project.
Anyone else have a better grasp of the issues?
YLFIRe:Brings to mind a question.... (Score:4, Funny)
Re:Brings to mind a question.... (Score:5, Insightful)
Horse-puckey...
It's a conflict of interest that consistently leads to abuses.
In the present case MySQL is pretending that GPL software is basicly non-commercial use only. It's a straight out lie, no matter how they dance around the issue. The Free Software Foundation is being very kind in stating that MySQL "marketing literature" isn't their concern.
MySQL AB isn't alone though.... Trolltech advances the idea that software you create using the GPL version of QT can't be reused in a commercial product. Their wording is careful, but the idea is wrong. You own the code you write, regardless of what libraries you used. Remove those libraries and you can do whatever you want. Their dual-licensing has also resulted in Linux PDAs which can't be synced to Linux desktops. Way to go...
PHP-Nuke has tried to pretend that various bits of code and advertising constitute a license declaration under the GPL. Basicly, GPL == adware. It's nonsense. Moreover, the PHP-Nuke advertising makes no mention that PHP-Nuke is itself a fork of Thatware.
ReiserFS, like PHPNuke wants to pretend that GPL software is adware for commercial products. Hans flipped out when Debian trimmed the marketing spiel out of mkfs.reiserfs. It's obviously not the intent of the license text clause of the GPL to advertise the benefits of non-free versions of GPL software.
Dual licensing is a bad idea. The only way you sell the commercial version is to make the GPL version unfriendly to business. Since the GPL was intended as a business friendly license, you're forced to misrepresent the GPL to sell licenses. If you want a dual-licensing business, don't use the GPL as the free license. Pick something that lets everyone know, from the get-go, that you're a commercial house intent on selling commercial software.
Re:mysql's GPL != REAL GPL (Score:3, Informative)
That is not true. You can modify GPLed software any way you want for your own use. It is distribution (whether you modified it or not), not modification that makes your obligations under the GPL kick in.
MySQL's opinion on what constitutes derivative work has always been stricter than most though. Most database suppl
Re:Brings to mind a question.... (Score:5, Insightful)
Firstly, certainly all previous versions of the software licensed under the GPL can continue to be used under the GPL.
Secondly, if the copyrights to the software are all solely owned by one company or by a small group of people then they can re-release the software under as many different licensing schemes as they want. They own the copyrights to the code, so they could decide to make all future versions of the code closed-source, or whatever. Anyone in the free software community would be free to create a "forked" version of the software based on the last GPL version and continue to develop it independently and release it under the GPL.
Thirdly, if the developers have accepted contributions from GPL folks without also getting ownership of the copyrights to the contributed code, then they probably are not allowed to take the current code based and make a version of it with any license that's more restrictive than the GPL, since the only license they have to the other people's code is the GPL itself, which forbids adding restrictions.
Finally, this is all a red herring in this particular case because the MySQL folks are just publishing their take on what the GPL means on their web site - they're not actually adding any restrictions. Of course, any company that sells software for a living will bias the explanations of the GPL on their web site as far as they can towards making you think that you have to buy their software, but the real license is still the GPL, and their "interpretation" of the GPL holds little or no legal standing.
What's GPL'd Stays GPL'd. (Score:3, Insightful)
From then on, they can license it however they please under any license they see fit.
However, what was GPL'd *stays* GPL'd, so you can restart a fork of it with all new developers if you so choose. Also, if you have many copyright holders (e.g. as with Linux), you effectively cannot change the license, because it would probably be impossible to get the consent of enoug
Re:Brings to mind a question.... (Score:5, Informative)
This is actually an unfortunate misconception about the GPL. By releasing code under the GPL, you are by no means giving up your ownership over the copyright under that code. As the owner of the copyright, you're welcome to do anything you want with it, including licensing it under any other license you see fit, and MySQL does just this. They offer MySQL under two separate licenses, one GPL, one not, and you can pick which one you want to use.
Re:Brings to mind a question.... (Score:3, Informative)
A project released under the GPL stays under the GPL. No retroactive licensing may be applied to the code. This does not prevent me (the author/copyright owner) from re-licensing the code under any other license that I deem useful.
Yeah, but since the original author still retains copyright over the work, he has the right to say, from this point on, this work will be completely closed source. The older versions, are still GPLd, and someone else may take over mante
Re:Brings to mind a question.... (Score:3, Interesting)
That's true of anything copyrighted, not just computer code under the GPL. Once you release it under copyright X, you can't further restrict that release in the future - although you can relax restrctions, if you so desire.
Unless, of course, you're Disney and can buy congress critters to grandfather whatever inane copyright schemes your lawyer-weasels have dreamed up during their luncheon crack sessions.
Max
Re:Brings to mind a question.... (Score:3, Informative)
For example, let's say Company A makes Program 1.0, and releases it under the GPL. Everyone likes the program, people use the GPL'ed code to make new programs, etc. Then, the OS-friendly management gets replaced by some unscrupulous types, and they decide to make Program 1.1 closed source.
Now, provided that they own all the copyrights to the Program 1.1 code,
Re:First Useful Post (Score:2)
I'm going to snag the sourcecode right now. but probably will use the fork that is created the very second they pull that trick.
That's the great part about the GPL, they can try and take their ball and go home, but as long as I have a snapshot of how the ball is made, I can make a LumpySQL that will seamlessly replace theirs and continue along happily.
I dont care what they do, they cant take mySQL away from me.
Strange really.... (Score:3, Insightful)
Re:Strange really.... (Score:3, Insightful)
If the F/OSS world loses MySQL, and there isn't a satisfactory fork of the GPLed version, why wouldn't we all switch over to the superior power of PostgreSQL?
Re:Strange really.... (Score:3, Insightful)
Ah yes... you ask the question that can only be answered in a way that must be marked as Flamebait...
Because, unlike MySQL, PostgreSQL is a real RDBMS. It didn't kludge things into the main system like the InnoDB/MySQL fiasco. It supports a MUCH, MUCH more powerful, rich subset of SQL. It does, basically, what a RDBMS should do, whereas MySQL only does as much as it needs to get by.
Interestingly, this gave MySQL a niche in the small/medium website market. People who couldn't justify the complexity of earl
Re:Strange really.... (Score:2, Insightful)
Re:Strange really.... (Score:5, Insightful)
And you guys are yelling awful loud to have anything meaninful to say.
Re:Strange really.... (Score:3, Insightful)
If you have to rewrite 250,000 lines of code just to change to a real RDBMS, your code must particularly aweful. We typically isolate all database specific code in appropriate classes and stored procedures (after all, that's one of the things stored procedures are for... to help abstract the database specific code from the rest of your code) and it isn't bad at all to port to a new RDBMS, as long as it has the features we need (referential integrity
Re:Strange really.... (Score:3, Interesting)
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 sear
Re:Strange really.... (Score:3, Informative)
Documentation.
At first, anyway.
I don't do a great deal with databases, but I did briefly look at using them alongside PHP a year or two ago. The majority of resources I looked at (both online and dead-tree) covered accessing a MySQL database to the exclusion of anything else. There were references to other databases, but no actual details on how to use them.
A quick check on Google reveals that not much has changed. Default "How to u
Re:Strange really.... (Score:3, Insightful)
PostgreSQL also has support for Ruby (and Python) which is sufficient to write a lot of useful scripts.
Re:Strange really.... (Score:3, Informative)
RESPONSE: What are you talking about?
2) lack of atomic commits (still??)
RESPONSE: They are called transactions and PSQL has had them for much longer than MySQL.
3) exponential degradation of performance with simultaneous accesses
RESPONSE: I have never seen this in production, any links to back this up?
4) multi-threading issues on multi-proc/distributed systems
RESPONSE: See #3
5) no graphical interface (necessary to "visualize" the table formats)
RESPONS
Re:Strange really.... (Score:3, Insightful)
Re:Strange really.... (Score:2)
Examples: the necessary steps to modify or backup SPs; debugging and repair of of SPs that are damaged/disabled.
Simplistically speaking, for every administration tool, there is at least 1 potential problem that the tool is used to correct. How many more tools are going to be included with MySQL when SPs are introduced?
Short answer, I prefer to use and teach
Re:Strange really.... (Score:3, Insightful)
(1) triggers
(2) constraint triggers
(3) functional indexes using a user-defined function, or indexing a user-defined data type
(4) user-defined aggregate function
(5) user-defined data types
Those are very difficult problems to simply work around. For #3 you just have to take the performance hit and not use the index. For #4 you have to read the entire amount of data into the application and post-process it to get the data you actua
Re:Strange really.... (Score:3, Interesting)
fools! those who do not learn from history.... etc.
Re:Strange really.... (Score:3, Informative)
Re:Strange really.... (Score:2)
I get around most of mySQL's "limitations" in TCL.
Re:Strange really.... (Score:2)
Re:Strange really.... (Score:2)
Oh really? I'd like to see someone run a major MMORPG off of a flat text file and Perl. Mythic's "Dark Age of Camelot" uses MySQL on Linux for its database.
Re:Strange really.... (Score:3, Informative)
Good question. At the moment, the things that are keeping me from switching over, are:
* Unbuffered queries
- When you're returning a result set that might be (literally!) gigabytes in size, storing the results in RAM is unfortunately, not an option.
* MYSQL's optimised count() function.
- "Select Count(*) from table" is very fast on mysql due to internal jiggery-pokery. Postgres is a touch slower unfortunately.
* Insert LOW_PRIOR
PostgreSQL (Score:4, Insightful)
Forking? (Score:5, Interesting)
Re:Forking? (Score:3, Interesting)
really, I'd like to know.
Re:Forking? (Score:2)
Re:PostgreSQL (Score:5, Insightful)
I reckon that now that MySQL is dealing with one of the big boys (SAP) they think they're the shiznit. They think they have the PHP and web server-side arena sewn up, so now they're trying to assert themselves in the larger market.
Roughly put, they're setting themselves up for a fall. MySQL database might be owned by a company, but it was tested and supported by the wider community. If MySQL starts screwing with their supporters they'll lose them to Postgresql, Firebird, or whatever. Much of the software using MySQL is opensource, and it can be ported to another database just as soon as the need is there.
Nothing new here. (Score:5, Informative)
Nothing to be concerned about here, folks. Move along. Move along.
We will just fork it (Score:4, Insightful)
Re:We will just fork it (Score:5, Funny)
Re:Who the hell is we? (Score:2)
Re:Who the hell is we? (Score:3, Interesting)
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 rig
Re:Who the hell is we? (Score:5, Funny)
Commercial Software
a few guys then
a few products then
early success then
money! then
more guys then
a few more products then
more money!
then more products (some good some bad) then
more money! then
more guys then..
OSS:
a few guys then
a few products then
early success then
fame and glory for a few guys then
more guys then
a few more products then
some fame for more guys then
maybe some people will join here and there then
a few bug fixes and patches then
not really any fame for the new guys then
people just stop caring because..
it suddenly dawns the german dork who spent 3 months in his basement writing a slighly faster screen refresh algorithm for some OSS spreadsheet program that has 1% market and that is pretty much only due to some for-profit entity working to the letter but not the spirit of the GPL that a) deep down, nobody gives a damn about where their spreadsheet screen refresh algoritm comes from and b) that there is an outside, and that even chasing girls unsuccessfully is better than working for redhat/ibm/whatever without getting paid.
Well... (Score:5, Insightful)
I can't get to the article (/.), but assuming this is not FUD:
With all the "Postgres is so awesome" stuff I keep reading (well okay, mostly on here), if MySQL backs away from open source, it could be the beginning of the end for them with "the geeks" (ie. us).
I'm not that familiar with Postgres, but I just checked and their website says:
The above is the BSD license, the classic open-source license. It has no restrictions on how the source code may be used. We like it and have no intention of changing it.
Sounds good to me!
Re:Well... (Score:5, Informative)
Well... I did read the article, and it sounded to me that some web page author got overly enthusiastic about when people ought to buy a license for MySQL. Reading anything more into it would seem to be sensationalism to drive people to the clipping (IMHO).
Good for them... (Score:5, Interesting)
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.
Re:Good for them... (Score:5, Interesting)
MySQL has made sure to cement their interpretation in two ways:
1. They "purchased" the LGPL JDBC driver and relicensed it as GPL. This ensures that physical linking will occur with their software (and thus the warning in the article about "circumventing" the drivers).
2. They keep their own variation of SQL (with the #$^@ing backticks) so that software must be designed for use with MySQL. While some of us use config files on a per driver basis, many software developers have fallen for the bait and tied their software to MySQL. Doing so invalidates certain GPL clauses that may allow you to get around the "linking" issue.
Re:Good for them... (Score:2, Informative)
You can still use the doublequote if you run with
--sql-mode="ANSI_QUOTES"
Re:Good for them... (Score:2)
Hasn't hurt Ghostscript [artifex.com] that I'm aware of.
It's MySQL (Score:5, Funny)
If they wanted you to own it, they would have named it that way.
Re:It's MySQL (Score:5, Interesting)
You just named the fork.
Re:It's MySQL (Score:3, Informative)
Re:It's MySQL (Score:3, Funny)
Well, sounds better than NotTheirSQL.
Re:It's MySQL (Score:5, Funny)
This SQL is MySQL
MySQL's changin' Licenses
YourSQL's a G P L
This SQL was made for you and me.
Great! (Score:4, Insightful)
Seriously, if you haven't used PostgreSQL, consider it for your next project. I use both, but have ended up using PostgreSQL a lot more. It's a much more serious database, and really isn't any more difficult to setup and manage than mySQL.
8.0's introduction of point-in-time-recovery is going to be a huge boost to enterprise applications of PG!
Re:Great! (Score:3, Informative)
MySQL doesn't feature anything remotely like ANSI-standard SQL behavior. Migrating from MySQL to any other SQL DBMS is much harder than migrating between all the other major DBMS's put together. MySQL is the odd man out, here.
"Distribute Interally" (Score:2)
Re:"Distribute Interally" (Score:2)
You've obviously never worked on a classified project.
I guess this would make it... (Score:5, Funny)
*snicker snicker*
No great loss (Score:2)
License of MySQL (Score:2, Insightful)
MySQL is a great product, as well as Postgres, but a change in licensing for MySQL will not be as bad as it may sound...
Postgres will rrule then (Score:3, Informative)
I can't wait till 8.0 when I can start writing my stored procedures in Java. W00t.
Error in Logic? (Score:2, Insightful)
MySQL is licensed with a "dual licensing scheme":
1. If your product talks to MySQL, you must release it as GPL.
2. If you don't want to GPL your product, pay MySQL $450.
So... according to the GPL, can't I fork the GPL version of MySQL, not change a thing, and allow companies to use "HerSQL" for free, keeping "HerSQL" as GPL?
Further, don't a lot of web applications that are not GPL interface with MySQL? Doesn't this violate their license?
Re:Error in Logic? (Score:3, Insightful)
Yep.
Further, don't a lot of web applications that are not GPL interface with MySQL? Doesn't this violate their license?
It's in the gray area. A bit closer to the "okay" side than, say, Java's dynamic binding (which is another 'can we combine GPL and nonGPL code). That's what the guy is talking about in the article about developers should abide by
Devs move to Postgre (Score:2, Insightful)
Read the article folks (Score:5, Insightful)
That said, this statement made me chuckle a bit:
Let me get this straight. Because it allows linking with PHP and Apache -- two systems which incidentally are fundamental to MySQL's continued success -- this is proof of their love of free software and freedom? Call me cynical, but it sounds more like proof of their love of avoiding irrelevance.
Can you imagine?
MySQL AB: We are pure GPL!
Developer1: Isn't the GPL incompatible with the Apache/BSD style of license?
Developer2: According to the FSF it is.
Developer 1: Aren't the Apache web server and PHP under Apache/BSD styles of license?
Developer 2: PHP used to be GPL, but yeah, now they're both like that.
Developer 1: So if I sell a complete package with all three, I'm legally in trouble?
Developer 2: Looks like it.
Developer 1: Well, I guess I'll install PostgreSQL then.
MySQL AB: MySQL FOSS exception!
Developers 1 and 2: Wow! What nice guys. They're really sticking their neck out for us on that one. Thanks!
Don't be such sheep (Score:5, Insightful)
the sky is falling
MySQL is going to screw everyone.
Just because one person's twist on that interview says that MySQL is about to turn evil, doesn;t mean it's true. Read the article, not just the /. headline
I actually think that the article is very fair, but it's considerably more in depth than most people who only read the /. headlines will know.
Article text (currently /.ed) (Score:3, Informative)
The MySQL License Question
By Timothy R. Butler
Editor-in-Chief, Open for Business
August 13, 2004, 11:15:53 EDT
MySQL AB's namesake database is a package that many would list among the crown jewels of Free Software. The Swedish company's database has been deployed over five million times by the company's own count. Yet, some, quite legitimately wondered if certain wording on the MySQL site might indicate the company is backing away from Free Software, and, more specifically, the GNU General Public License. We wanted to know if this was an actual concern or simply a misunderstanding, so OfB contacted MySQL AB to find out more information.
The whole question arose from the text MySQL AB publishes on its web site concerning why one would need to purchase a commercial license for its software. "When your application is not licensed under either the GPL-compatible Free Software License as defined by the Free Software Foundation or approved by OSI, and you intend to distribute MySQL software (be that externally to customers or internally within your organization), you must first obtain a commercial license to the MySQL product," the site explains. At press time, the remark concerning internal distribution had been removed after the commercial licensing page was revised based on user feedback, MySQL AB told OfB.
At first glance, this might not catch anyone's attention, but after considering it, it becomes apparent that this sounds like stricter requirements than those laid down by the General Public License. For example, the Free Software Foundation's documentation on the General Public License, which they wrote, explains that "[y]ou are free to make modifications and use them privately, without ever releasing them." The document then continues, "This applies to organizations (including companies), too; an organization can make a modified version and use it internally without ever releasing it outside the organization." If this is the case, a company desiring to keep its code private would not need to purchase a commercial license as the MySQL site indicates.
The information on MySQL's commercial license page also seems to be a bit far reaching when it suggests that one's program must be licensed under the GPL or another Free Software license if MySQL is distributed with the product. A good analogy here is that it is legal for a proprietary web browser to communicate with a GPL licensed web server, and vise versa -- the programs are communicating to each other, but not actually combining code together. In the same way, it is theoretically possible to communicate with the MySQL server either using a third party Free Software tool that allows linking to proprietary packages, such as one licensed under the LGPL or BSD licenses or by developing a proprietary program that can communicate with MySQL through networking protocols. In plain English, this means there are ways that one could have a proprietary program communicate with a GPL licensed program without violating the GNU General Public License. Furthermore, simply distributing a proprietary product and GPL licensed product together is called "mere aggregation," something explicitly permitted by the GPL.
One developer from a small consulting firm who requested anonymity explained his concerns about the issue and how it had led the company he works for to have all of its clients purchase MySQL licenses out of fear of litigation. "MySQL AB has bent the intentions of the gpl to say that any proprietary application I write that causes my customer to have to install a copy of MySQL, whether or not it uses the MySQL client libraries, must be licensed under [the GPL]."
We wanted to know if this assertion was correct or if MySQL's site was simply a bit confusing on the point of when licensing is required, so we contacted them. Zack Urlocker, MySQL's vice president of marketing, agreed to answer our questions on the matter.
The big question we wanted to know was if
Free software (Score:5, Informative)
Re:Free software (Score:5, Interesting)
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.
Recent Changes to Client License (Score:5, Insightful)
On the other hand, I do think MySQL really wants to push their commercial license as they "recommend" it for everyone who use MySQL in a commercial environment, even though their dual licensing scheme only requires the purchase of a license if you plan to be distributing MySQL itself. It'll be interesting to see how this all unfolds, but I don't think the GPL version of MySQL is going to go anywhere, at least not for non-commercial users. While commercial users may face stronger "recommendations" to purchase licenses, I don't see any actual changes to the license requiring a license for commercial use without distribution. Doing this would shut out millions of entry level hosting providers, and it wouldn't be long until MySQL's massive market share fell to alternatives such as Postgres or SQLite.
Re:Recent Changes to Client License (Score:5, Insightful)
One more reason to use standard interfaces (Score:5, Insightful)
There are other ways of doing the same task, such as using wrapper functions for your DB calls.
This approach isn't appropriate for every project, but before you start coding, you should ask yourself "will this ever be used on another DBMS, what can I do now to save myself work later, and what will it cost me in terms of schedule, functionality, performance, etc."
ODBC is not "circumvention" (Score:5, Insightful)
Communicating with a database via "TCP/IP or another protocol," such as ODBC, is not in any way a circumvention of the GPL. This is what ODBC is for, for heaven's sake, there's nothing sneaky about it.
Following MySQL's moronic licensing innuendo, you would be required to use GPLed software to talk to a GPLed web server. Unfortunately even the unixODBC guy who was quoted didn't make the point that connecting to a database server from a client program (on a remote machine or on the same machine) using ODBC is morally equivalent to connecting from a client program to a web server using HTTP, and so the same rules must apply. The FSF guy didn't make that point either. I can understand why these free software folks feel some need to stick up for each other but someone needs to drive a stake through the heart of all this licensing idiocy, it doesn't help anyone.
"New Offerings on the Horizon" (Score:5, Interesting)
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.
Re:"New Offerings on the Horizon" (Score:3, Interesting)
In fairness to MySQL AB, I think they still feel that, for example, foreign keys are unnecessary. I just think they've put them in because they kept hearing "your program sucks 'cuz it doesn't support foreign keys" and (more importantly) "Gee, we'd like to use your product, but we insist that we must have foreign keys so we can't", so they gave in and added them.
I wonder, though. Any chance PostgreSQL might add a "MySQL-compatible" client library? There seem to be quite a few programs that currently onl
MySQL compatibility layer (Score:4, Insightful)
The bad habits people learned on MySQL would perpetuate. After all, why code for database abstraction if the two main OSS databases share the same API?
I'd much rather MySQL tightened things up a bit. Optionally of course as I understand they have a large installed base, but I'd like to see the MySQL version of Perl's "use strict". If MySQL did that, I hereby proclaim to all around me that I will no longer bash MySQL. I won't necessarily prefer it to PostgreSQL, Firebird, or SQLite, but I won't flat out trash talk it for being a loose piece of crap data trashcan that silently ignores obvious errors in the name of efficiency while blaming the programmer even though one of its primary selling points is that it's easy for beginners.
'The fuzzy elephant' is NOT a valid integer nor is it a valid timestamp nor is it appropriate for a varchar field constrained to 10 characters! NOT NULL means "I require a value," not "I'll put the non-specified default in there despite you passing a NULL." It's not like these checks require a great deal of processing power after all. If it made more than a blip on the speed of MySQL, I would be truly astonished.
Once MySQL's "use strict" is in there, I will accept the mantra that it's the programmer's fault for not using it.
Re:"New Offerings on the Horizon" (Score:5, Insightful)
Then I worked for a company that required Oracle for its database, because nothing else on the market could possibly handle what they needed done. And they put me to work on some of their stored procedures. ouch.
I learned what I needed about database normalization, and I realized just how much of a toy MySQL was.
That they added essential features is great, but that they still think they're unnecessary shows they have NO CLUE what challenges you get in big developments. And if they flip-flopped on the features, will they change the license?
The most promising db right now for people like me is obviously PostgreSQL. No license hassles is just gravy.
What about the $19.5 million funding? (Score:3, Informative)
That's gotta do something...
Comment removed (Score:5, Interesting)
It is extremely simple... (Score:3, Informative)
It is not considerably different from most other projects. If you don't like the rules of contributing, fork your own. That e.g. the kernel is GPL, doesn't mean I have any right to get my code in Linus' code tree.
Kjella
Re: (Score:3, Informative)
Re:It is extremely simple... (Score:3, Informative)
I'm coming to this discussion a day late, and I can't believe no one has answered your questions, greggman. In any case, here it is: their commerical version is 100% free of any GPL'd contributions. You clearly wonder how a product that huge, with that many contributions, can manage such a thing. It's simple. They do the same thing that the FSF d
Re:It is extremely simple... (Score:3, Informative)
That's the gamble every GPL project makes. My own phpBB Blog software is GPL, and I run the risk of a fork just like everyone else. In fact, possibly more so -- I specifically ask users to post patches and even entirely recoded pages. I guess my project lumbers from one fork to the next, integrating code as I'm allowed. The MySQL team doesn't really have much to worry about, though. They are doing right by their users for the most p
Did anyone ready the article? (Score:5, Informative)
Whats interesting is that this affects open source, but not necessarily GPL projects. Asterisk [asterisk.org] which use a different lisence have removed MySQL libraries because of this conflict.
From their documentation:
"We were recently contacted by MySQL and informed that the MySQL client
libraries are now under GPL license and not LGPL license as before.
Since Asterisk does allow exceptions to GPL, we are removing MySQL support
from standard Asterisk. We will, where appropriate, make it available via
a separate package which will only be usable when Asterisk is used completely
within GPL (i.e. not in conjunction with G.729, OpenH.323, etc). We
apologize for the confusion.
Is this a case of the GPL being a bad thing?
cluge
I don't think so... (Score:3, Informative)
Re:Please stop (Score:5, Insightful)