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."
Nothing to be concerned about here, folks. Move along. Move along.
why wouldn't we all switch over to the superior power of PostgreSQL?
;-)
1) lack of consistent SQL support (getting better)
2) lack of atomic commits (still??)
3) exponential degradation of performance with simultaneous accesses
4) multi-threading issues on multi-proc/distributed systems
5) no graphical interface (necessary to "visualize" the table formats)
6) no Dylan/Eiffel/Smalltalk/etc. support
7) ???
8) Profit?
Exactly who will fork this, who is this mythical we?
The code is so huge that only the core developers have much of a clue of what is going on. Apart from those few people, there are not many who will be able to get up to speed and take the project in a new direction.
flatfile and perl equal to mysql?!?!? I don't think so. However, mysql vs. postgresql is getting more interesting by the day. Fortunately since I use perl's DBI interface I don't have to change much in my programs to switch to postgresql if I need to jump ship. ;-)
Changing the license at this point will hurt mySQL bad. Postgres has some big backers now and is already more feature rich than mySQL. Take it form me, I was a mySQL addict and then my boss introducted me to Postgres. I look at mySQL as a kids toy now.
I can't wait till 8.0 when I can start writing my stored procedures in Java. W00t.
If they release under the GPL, that code stays under GPL forever. Anyone who has gotten a copy has all the rights and responsibilities to the code as laid out in the GPL.
If no one has gotten a copy of it yet, then they can re-license the code however they want and no one would be the wiser.
This is why the GPL is so good. It gives the authors the Freedom to choose whichever license fits their mindset. If they don't want to use the GPL, the authors are Free to choose any other license they like. The GPL has no restrictions on that!
Interviews
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
The article states that this doesn't effect free software at all. Only commerical software that links to MySQL requires a licence, as it always has been.
Maybe you should email the FSF. They're the gurus on all legalese GPL.
tasks(723) drafts(105) languages(484) examples(29106)
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.
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).
They keep their own variation of SQL (with the #$^@ing backticks) so that software must be designed for use with MySQL.
You can still use the doublequote if you run with
--sql-mode="ANSI_QUOTES"
You can still use the doublequote if you run with
--sql-mode="ANSI_QUOTES"
Note that the above is an option to pass to the SERVER. It does diddly-butkis to help tool vendors. In fact, it only serves to make tools incompatible if it's turned on. A better solution would be to either switch over to ANSI support (the way it should have been in the first place), or allow the setting to be flicked on at the connection level.
I'm not sure what I've misconceived here.
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 manteinership.
In the situation that I released under GPL and then took the code back immediately before anyone had a chance to gain access to it, my GPL'ing of the code is essentially moot. It would be as if I had never released the code under the GPL.
In practice, yes.
1) lack of consistent SQL support (getting better)
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)
RESPONSE: PGAdmin and other tools support PSQL.
6) no Dylan/Eiffel/Smalltalk/etc. support
RESPONSE: Google for them. They exist.
Funny that the article didn't mention the $19.5 million series B round of funding received in June 2003...
That's gotta do something...
> why would anyone chose MySQL over PostgreSQL if they had to pay for it?
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_PRIORITY
- No equivalent in PG
* phpmyadmin
- phppgadmin is nice, but still missing a few nice things (renaming table fields, or changing data types, for example)
* mysqldiff
- An application that takes one database structure, compares it against the current database structure, and outputs the SQL statements required to 'upgrade' the current DB structure to the 'new' DB structure.
A few of these are enough for me to stick with MySQL at the moment, even at a reasonable price.
If you're a little more in touch with PG than I am, and any of the above are no longer valid, please let me know!
Red.
I think I would call it OurSQL.
ato
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.
MySQL Gotchas
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.
It appears that the folks building MySQL are even MORE pro GPL than a rabid /.er! I know it's hard to believe, but unlike the very bad description of the artcle given above (the sky is falling, the sky is falling) the actual text of the article shows that the company is pro GPL. It isn't backing away from the liscence, but tryng to be sure that users of GPL software uphold that very lisence.
Whats interesting is that this affects open source, but not necessarily GPL projects. Asterisk 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
"Science is about ego as much as it is about discovery and truth " - I said it, so sue me.
ok the topic here should be mysql vs postgres but seeing as how it has been trolled to death I though I would add my .02 and a question.
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? When you have a "large system" and outgrow a 24 processor sun or IBM box you start to consider things like multiple database servers, moving cpu load onto the commodity hardware in the application layer, and data partitioning. DR for large system and the cost a site failure and full restore for such a large system are also valid concern. Most sites with the characteristics of a "large system" are Financial, Telco, Data Warehousing, and batch processing fit an Oracle, or DB2 profile very well. Generally internet sites that don't grow so big (>200GB data), or get Tons(>20Mb/s) traffic tend to do fairly well with anything, even M$ SQL.
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.
Storing a result set that's gigabytes in size in RAM is probably not a good idea in any case.
Caching a query result set is incredibly difficult to do correctly in any case, as you either have to invalidate the entire set when any changes are made to the underlying tables, or you have to run the data involved in any INSERTs, UPDATEs, and DELETEs through the search terms used for the query you're caching and modify the cached result set upon a hit. The former is easily replaced by client side caching + rules or triggers on DML (INSERTs, UPDATEs, and DELETEs) to the underlying tables, and the latter is likely to have a significant impact on your database update performance.
Yes, though you can get a quick approximation by querying the PG schema tables directly:
---
And no need. LOW_PRIORITY exists because MySQL does full-table locks for DML against MyISAM tables. LOW_PRIORITY ensures that DML doesn't get priority over SELECTs.
PostgreSQL uses MVCC. This means that writers almost never block readers, and hence prioritization of readers over writers isn't necessary. This is one of PostgreSQL's biggest strengths.
Put in the feature request. Also make sure you check out the current version. PostgreSQL 8.0 will have the ability to change the data type of a column without having to go through gymnastics, but it's possible to make the change even now -- it's just more difficult.
This sounds very cool, and since it's open source it may be possible to create a PostgreSQL version of it from the source.
Use 'slashdot stuff' in the subject line in any email you send me if you want to get past the spam filter.
Would you be so gracious as to say why?
I mean, I've used MySQL, PostgreSQL, SQL Server (very much like Sybase), and Oracle, and I prefer PostgreSQL for most things. And the reason is simple: I can guarantee the integrity of my data with it much more easily than I can with MySQL, and I can afford it. :-)
Not to mention things like the fact that the query language rarely prevents me from doing something I want to do within the database, and when combined with the many languages you can write stored procedures/functions in, there is very little indeed that can't be done with it. I've found MySQL much more limiting.
And as a DBA, PostgreSQL for me is second to none in some situations. Namely, that DDL is transactional! Even Oracle can't make that claim (though I think SQL Server/Sybase can for some DDL, at least).
Use 'slashdot stuff' in the subject line in any email you send me if you want to get past the spam filter.
...if you already have the code base, which is mainly developed in-house. Simply require all contributions to be under dual licence/copyright waiver. Certainly, you're free to create your own GPL fork, but then you're on your own.
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
Live today, because you never know what tomorrow brings
I haven't RTFA yet, but I heard Brian Aker, MySQL's Director of Architecture speak at a local LUG meeting last weekend, and he sure didn't seem to think the company was backing away from the GPL. Quite the opposite. They're getting ready to release some really nice-looking new GUI admin tools, which will be GPL'd. He said (paraphrase), "If you're open source, we're open source, and we'll help you however we can. But if you're using our product in a closed-source way, we have no problem charging you for a commercial license." As I understand it, that's the way they've always been.
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 suppliers (Free or proprietary) would consider ODBC, JDBC and other ways of connecting to the database to be a standard interface, and a clean point of separation between the database and third party software. But MySQL claims that their interface libraries are GPL, and linking to them produces a derivative work. There is also an entry in their FAQ where they state that you need to buy a commercial license if you bundle MySQL on the same CD as your non-Free software, even if your software works without it, and you have bundled it merely for users' convenience so they can use it if they want. They are entitled to their opinion on this, and I personally would steer well clear of MySQL because of it, but on this last point, I don't think they should be calling their license GPL if they are serious about it.
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 use a database" info is still MySQL-centric, and you have to specifically search for PostgreSQL to find anything (and you get a third of the results from MySQL).
It's a pain, sure. But it's a definite drawback - simple lack of mindshare. And as long as dead-tree books on PHP and/or databases mainly/only reference MySQL it's going to continue to be an issue.
Amazon hits for MySQL: 90. Amazon hits for PostgreSQL: 15.
So basically those who already know about PostgreSQL will make an informed choice, and anyone else will stick with MySQL either because they don't know there are alternatives or they can't find documentation.
Tiggs
"120 chars should be enough for everyone..."
First of all MySQL used to be the only choice for OSS developers when it comes to stable database software that could be used in a productive environment with a lot of demand. PostgreSQL used to be more damanding on hardware and hardware (as noone should forget) used to be much slower. Now we have 2 and 3 Ghz for 200 bucks. PostgreSQL also became more stable, robust and less demanding. There are also many new choices out there: MaxDB (formerly known as SAP-DB e.g. Adabas D) is now under the GPL and Interbase became OSS under the name Firebird to name just 2 very famous examples.
So if anyone has problems with the license for any reason they can choose among many other: BSD for PostgreSQL, GPL for MaxDB and the InterBase Public License for Firebird for the three mentioned examples.
Other than that all code released under the GPL can be used under the terms of the GPL and anyone can do whatever they feel like with it. That means that if I choose to take the current MySQL to write my world domination program (the source code to that would certainly remain secret) with it I can do it now or whenever I choose to do that.
Only when I want to distribute said program (what a dumb idea!) I have to make the source code available to anyone who I distribute this program to and I also have to inform that person that they can do anything they want with that code as long as they adhere to the GPL.
The LGPL is a different beast. If I link my program to LGPL libs I can withhold the source even if I choose to distribute my program. If I link to GPL libs I have to give out the source with the program. Only if I use code LGPL itself I need to put the result under the LGPL. But agains only if I distribute it. Many companies used to develope software only for in house purposes. Those could and still can use GPL and LGPL programs and source as much as they like and don't have to give anything back to the community.
There is absolutely no problem here, because anyone can still use existing code with the licenses they were distributed under, e.g. older or the current version of the MySQL client and even fork and patch those with appropriate security patches if necessary (the patches have to be the old license though). So if anyone created a program using the old MySQL then they don't have a problem. If they develope something new then they can choose among many OSS DB (s.a.) and their respective licenses.
So nothing to see here, move along please.
Actually, you can restrict future versions of software released under License X, provided that you own the copyright to all the code in the project.
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, they can do this. They cannot, however, go back and sue the people still using the Program 1.0 source code that was released under the GPL. And, if somebody outside the company made improvements to Program 1.0 that were then rolled into the Program 1.1 code, then Company A would not own all the copyrights to the Program 1.1 code (unless the person who wrote the improvements signed over the copyright), and would therefor not be able to make Program 1.1 closed-source.