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."

Comments

No, they're just confused by the legalese

[Anonymous Coward]

Like a lot of us are. Their interpretation is a bit off and I'm sure they'll correct it.

Re:No, they're just confused by the legalese

[cbrocious]

I disagree. I think that they're using legalese to try and mask that they're moving away from true F/OSS. It's been happening for a while now.

Re:No, they're just confused by the legalese

[einhverfr]

All the more reason to use FirebirdSQL or PostgreSQL

First Useful Post

[HappyPerson]

Consistency in licensing is important, whatever they choose I hope they stick with it.

Re:First Useful Post

[borgdows]

Consistency in a database is important too, whatever they choose I'll stick with Postgresql.

Strange really....

[tarquin_fim_bim]

This has been in the offing for sometime now, why would anyone chose MySQL over PostgreSQL if they had to pay for it? It may be faster but it does little more than can be done with a flat text file and Perl. Suicide.

Re:Strange really....

[angst_ridden_hipster]

Those were more or less my first thoughts as well.

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....

[Jack9]

So how long before you give me a MySQL equivalent Perl script? Right. People would choose MySQL for speed and ease of administration (not hard to "administrate" a flat text file over a RDB), like always.

Re:Strange really....

[rokzy]

did Xfree/X.org teach (or even remind) them nothing?

fools! those who do not learn from history.... etc.

Re:Strange really....

[the_mad_poster]

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 earlier builds of Postgres jumped on MySQL because - although it makes the hard things impossible - it makes the most common tasks in a dynamic environment manageable for even the most clueless n00b. As people graduated to a more detailed understanding of things, MySQL offered them the power they needed to grow.

Unfortunately, eventually you will outgrow MySQL and hit the things where MySQL fails miserably at. Then, you need a "real" RDBMS. Alas, most folks using MySQL didn't need to do that, so they're used to the bizarre quirks of MySQL (18 nestings of SELECT anyone?) and struggle with PostgreSQL and other "real" RDBMSs as a result.

That's why.

Re:Strange really....

[Daytona955i]

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. ;-)

Re:Strange really....

[EvilTwinSkippy]

It's not that I "refuse" to learn anything else. It's that 3 years ago when I started my project I needed replication THEN. I needed a windows port THEN. I needed TCL bindings THEN. And I'm not going to re-write 250,000 lines of code because someone tells me my perfectly working system is inferior.

And you guys are yelling awful loud to have anything meaninful to say.

Re:Strange really....

[DAldredge]

Why in the hell did you write 250k line of database dependent code?

Re:Strange really....

[DAldredge]

WTF are you talking about? Please research the current (Last 1000 days or so) PostgreSQL before you speak on this subject again.

Most of what you said is complete and total bullshit.

Re:Strange really....

[nkh]

Atomic commits seems to be called transactions in PostgreSQL. More info can be found in the tutorial.
PostgreSQL also has support for Ruby (and Python) which is sufficient to write a lot of useful scripts.

Re:Strange really....

[DAldredge]

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.

Re:Strange really....

[RedPhoenix]

> 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.

Re:Strange really....

[Daniel Dvorkin]

Aaargh. Can we get rid of this stupid meme, please? I've been making a living as a DBA for almost five years now. I'm 2/3 of the way to a CS Master's. I've used Oracle, Sybase, and PostgreSQL. And I prefer MySQL. The idea that the only people who use MySQL are those who don't know any better has to die.

Re:Strange really....

[fitten]

Heh... I'd be surprised if your system works "perfectly".

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, transactions, etc.)

In fact, in most cases, we can port to a new RDBMS without recompiling our source, just by providing the appropriate stored procedures on the new system.

Re:Strange really....

[kcbrown]

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.

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.

* 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.

Yes, though you can get a quick approximation by querying the PG schema tables directly:

SELECT CAST(reltuples AS integer) FROM pg_class JOIN pg_namespace ON (pg_class.relnamespace = pg_namespace.oid) where relname = 'tablename' AND nspname = 'schemaname'

---

* Insert LOW_PRIORITY - No equivalent in PG

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.

* phpmyadmin - phppgadmin is nice, but still missing a few nice things (renaming table fields, or changing data types, for example)

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.

* 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.

This sounds very cool, and since it's open source it may be possible to create a PostgreSQL version of it from the source.

Re:Strange really....

[kcbrown]

I'm 2/3 of the way to a CS Master's. I've used Oracle, Sybase, and PostgreSQL. And I prefer MySQL.

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).

Re:Strange really....

[jadavis]

If stored procs are a bad thing, wouldn't the following features also be bad?:

(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 actually need. #1, 2, and 5 all speak for themselves, being basic principles of an RDBMS.

And PostgreSQL 8.0.0beta1 has PITR (point in time recovery) meaning that it should be reasonably simple to revert to a previous state. Hopefully that makes it easier for you to fix it when someone screws it up.

I'd also like to point out that a very advanced replication system, Slony-I, was developed for PostgreSQL using triggers and stored procedures (to work with the replication daemon). So I'm not speaking in abstract terms about potential usefulness, but real-world business needs. What would you do to implement such a replication engine in MySQL? Write some code in the MySQL server and recompile I suppose. Slony actually works across PostgreSQL versions and works on versions of PostgreSQL that were released before Slony was ever conceived. That's the power of stored procedures.

I understand that these features need to be used with care. I understand that some people don't need these features (unfortunately, some people realize they are needed too late). What I don't understand is how software can be missing these features and still call itself an RDBMS. What surprises me even more is when people make a blanket statement condemning these features with absolutely no acknowledgement of their actual uses.

Re:Strange really....

[TiggsPanther]

why wouldn't we all switch over to the superior power of PostgreSQL?

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.

Re:Strange really....

[Daniel Dvorkin]

Would you be so gracious as to say why?

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 ... but twenty years from now, you'll probably have /.ers hashing it out over these competing memes.

PostgreSQL

[thammoud]

People will switch to PostgreSQL faster than the MySQL folks can type GPL back into the license. They will be crazy.

Re:PostgreSQL

[BiggerIsBetter]

There's only one thing that I like about MySQL... SAP-DB. - er, MaxDB, and even that's sufficiently different from MySQL database to avoid the whole PHP/FanBoy mess. However, Postgresql is "good enough" for 90% of apps. Oracle is certainly good enough for the remaining 10%.

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.

[Anonymous Coward]

You've always been able to buy a commercial MySQL license for a commercial app. Personally, I'd be using PostgreSQL for any serious database work in any case (assuming Oracle or other commercial database isn't a requirement) -- it's much closer to what I'd expect from a database than MySQL.

Nothing to be concerned about here, folks. Move along. Move along.

We will just fork it

[Anonymous Coward]

If they change the license, can't we just fork from the last GPL release?

Re:We will just fork it

[VirexEye]

The classic "farewell and fork you!"

Forking?

[headkase]

Couldn't anyone create their own fork from the last GPL'd source?

Re:Forking?

[gl4ss]

patented as in how? and what difference would it make then, to keep using the older version, or keep it under gpl and make everyone pay to them 'for the patent'?

really, I'd like to know.

Well...

[joseph schmo]

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...

[SlowMovingTarget]

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...

[SnapShot]

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.

Re:Good for them...

[AKAImBatman]

See, here's the problem. MySQL AG seems to have reinterpreted the GPL to mean that any use of their software means that your software should be open source. Run a small website with the MySQL database? If all the source to that site is not GPLed, you're in violation. That's despite the fact that your site should be a clear and separate product from MySQL.

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...

[flupps]

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"

Re:Good for them...

[Inthewire]

...am I on crack?

No idea.
Got modpoints?

It's MySQL

[Anonymous Coward]

not YourSQL.

If they wanted you to own it, they would have named it that way.

Re:It's MySQL

[Tokerat]

You just named the fork.

Re:It's MySQL

[ejaw5]

This SQL is YourSQL
This SQL is MySQL

MySQL's changin' Licenses
YourSQL's a G P L

This SQL was made for you and me.

Re:It's MySQL

[agurkan]

I think I would call it OurSQL.

Re:It's MySQL

[Tokerat]

Well, sounds better than NotTheirSQL.

Great!

[The AtomicPunk]

PostgreSQL gets another boost! :)

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!

[rycamor]

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.

I guess this would make it...

[deathcloset]

TheirSQL

*snicker snicker*

Brings to mind a question....

[hot_Karls_bad_cavern]

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.

Re:Brings to mind a question....

[offpath3]

Once they've released code under the GPL, it is always under the GPL. But, because they are the original copyright holders, they may also release it under any other licenses as they see fit (and in this case, MySQL does just that). They could also make a newer version using the old code and not release it under the GPL, since again, they are they copyright holder.

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 they incorporate it into a newer version, they could not release it under any license other than the GPL without my approval, unless they were to remove my code. Strange quirks like this are one of the reasons why the FSF asks people to give the copyright of code over to them rather than to have all of the individual programmers retain copyright.

Re:Brings to mind a question....

[YOU LIKEWISE FAIL IT]

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?

YLFI

Re:Brings to mind a question....

[offpath3]

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 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....

[tomhudson]

I'll give you my reading, because the other followup didn't catch all your questions:

Thanks, because right now Open for Business' server should be renamed Closed for Business (slashdotted).

Re:Brings to mind a question....

[conradp]

IANAL, but...

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.

Re:Brings to mind a question....

[Zangief]

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.

Re:Brings to mind a question....

[lspd]

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.

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:Brings to mind a question....

[joeykiller]

Strange quirks like this are one of the reasons why the FSF asks people to give the copyright of code over to them rather than to have all of the individual programmers retain copyright.

I think the FSF only asks this for GNU products, not for every GPL product that exists.

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?

Re:Brings to mind a question....

[maxpublic]

No retroactive licensing may be applied to the code.

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....

[KewlPC]

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.

License of MySQL

[shawn_f]

Well, if MySQL decides they need to change the license, then fine...I am sure they will loose some users, but it will not be their downfall. Perhaps they could something like http://www.bb4.net/ has done, where they have a fairly functional free, version, which is still open source, and a "professional" version which has some additional features and support. Really not a bad idea...

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

[SQLz]

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.

Error in Logic?

[Anonymous Coward]

Wait, wait.

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?

[EvanED]

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?

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 the GPL and not try to find loopholes.

Devs move to Postgre

[RWaye]

Now, I am not sure if this is true, but since MySQL is GPLed, doesn't that mean that they have some freelance programmers that contribute to the project? If they leave the GPL, that may encourage a devolper move to Postgre, helping it become a better DB.

Read the article folks

[ttfkam]

It went on and on about how much they like the GPL over all other licenses. I'm no MySQL fan, but for fuck's sake...

That said, this statement made me chuckle a bit:

The main point he made to us is that his company believes "strongly in Open Source." The company has actually tried to increase the freedoms provided by the GPL, Urlocker asserted, with the "MySQL FOSS exception" that allows some Open Source Initiative approved licenses, that are incompatible with the GPL, to still make use of the GPL licensed version of MySQL.

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

[fishdan]

I'm not saying that MySQL is the greatest thing since sliced bread, but Open For Business makes their living off of commenting on FREE software, which MySQL is not, nor has every really claimed to be. They sell advertising. They have a financial incentive to claim that

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)

[Anonymous Coward]

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

Free software

[Sir Homer]

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.

Re:Free software

[Bastian]

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.

Email the FSF

[Short Circuit]

Maybe you should email the FSF. They're the gurus on all legalese GPL.

Recent Changes to Client License

[Unknown Relic]

Let's not forget about the recent changes of the MySQL client to use the GPL instead of the LGPL, since such a change hardly suggests that they're looking to dump the GPL. This change was widely publicised, as it caused issues (which have now been resolved) with other non-GPL open source applications which previously shipped with the client software - PHP being the prime example.

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

[rhaas]

I think the change from the LGPL to the GPL was designed precisely for the purpose of forcing more people to purchase commericial licenses. Unless I'm misunderstanding the situation, under the LPGL, you can link your (propriety) code against their libraries without having to distribute your source code. Under the GPL, this is not the case - linking is not "mere aggregation" and you now have to distribute the source, cough up $$$, or stop upgrading MySQL. If they were distributing the code ONLY under xGPL, the change would clearly be an endorsement of F/OSS, but because of the dual license, it seems more like an attempt to restrict what users can do with their software.

Re:Who the hell is we?

[Lumpy]

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.

all the better

[ryane67]

ill be happy if they change the license away from the GPL and it happens to run their marketshare to nothing.

Honestly I never understood what people saw in mySQL other than the FREE aspect, and if that was the only thing they were looking for Postgres, Oracle (for personal use), and MSDE (MS sql server free ver) are all much better tools for the same price.

One more reason to use standard interfaces

[davidwr]

On my last project, I used OBCD specifically so I could use one DBMS today and I or my in-house customers could replace it with another one later with minimal effort.

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."

Re:Please stop

[OmniVector]

i'd rather everyone stop coding strictly towards one database api, and use abstracted interfaces like PEAR, ado.net, jdbc, odbc, etc.

Re:Who the hell is we?

[mumblestheclown]

Shhh! You're exposing the real cracks in the OSS model!

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.

ODBC is not "circumvention"

[justins]

I don't think it would be overstating the case to say that "Zack Urlocker, MySQL's vice president of marketing" is either a liar or doesn't understand the application of the GPL with regards to client/server software:

On the other hand, while Urlocker said the company is not adding restrictions on to the GPL, he felt that attempting to, as he put it, "circumvent" the GPL by communicating with the database using a third-party tool and TCP/IP or another protocol was a gray area and while perhaps following the letter, it was not following the spirit of the General Public License.

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"

[ttfkam]

Speaking of the new releases made possible by MySQL's dual licensing business model [as though they would stop all development otherwise], Urlocker pointed out that MySQL 4.1 is presently in beta and "should be released for production" within four to five weeks. According to information provided by the company, the new release will feature OpenGIS geographical data support [just like PostgreSQL and Oracle have done for some time now?] and the ability to send multiple SQL statements via a C language MySQL API call and receive the results back at once [yup, even though batch SQL processing isn't all that new, just use our proprietary C API and leave that nasty old ODBC behind], among other additions and enhancements [which by and large have been done by every other database vendor before us].

MySQL 5.0, the first major update to the product since the MySQL 4.0 "production" release was announced in early 2003, is presently in the alpha stage of development. "New stored procedures and views" are among the features that this upcoming release will include [even though they publicly made a point of telling developers how little you needed them just a short while ago]. Some other interesting features may also make it into the code before the release, but Urlocker said that his company prefers to "under promise and over deliver." [Well they've certainly delivered on the under promise part.]

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. ...to get the stink off.

Those who forget the past are doomed to extended use of a debugger.

Re:"New Offerings on the Horizon"

[Dr.Dubious DDQ]

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 only support MySQL as a database server - often programs that don't NEED more than basic database support (e.g. GPSDrive's use of MySQL to store its list of waypoints and Kismet-detected WAP's...) If there were a compatibility layer for PostgreSQL such that it could "fill in" for a MySQL server without re-writing the client side program that would be handy. If MySQL continues to expand to the point where it is no longer "leaner" than more heavily-featured database servers then backwards-compatibility will be the main reason left to stick with MySQL...

Re:"New Offerings on the Horizon"

[danharan]

I remember a few years ago, a total nOOb, trying to figure out what's what in the database world. I had read about how we don't really need all those complex features that slow down databases, and believed it.

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?

[freelunch]

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...

GPL and Commerical Licenses Impossible?

[greggman]

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.

MySQL AB Comments

[martenmickos]

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

[martenmickos]

That's an interesting discussion that would warrant more than a Slashdot posting.

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:MySQL AB Comments

[Hobbex]

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

[martenmickos]

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#MereAggre gation

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 /. does!), but we don't see it as our responsibility to provide a detailed legal analysis to every user. We proudly think we have done a fantastic deed in licensing MySQL under the GPL in the first place, and we think it is only fair for us to assume that the free software / open source community needs little help in coming to terms with the GPL.

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

[jadavis]

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.

Re:MySQL AB Comments

[martenmickos]

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

What's GPL'd Stays GPL'd.

[Xenographic]

Well, for them to change the license, they must have the copyright on that code (or the consent of all those who do hold copyright on it).

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 enough of the copyright holders.

IANAL, but I've spent a lot of time reading US copyright law and Groklaw.

MySQL compatibility layer

[ttfkam]

I had thought about that, and the more I thought about it, the more it seemed like a bad idea. Why?

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.

Did anyone ready the article?

[cluge]

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

Re:Question about the GPL

[FLEB]

The counterpoint to that, though, is that the employee is working as an agent of the company, not as an agent of themselves. If they have been disallowed, as an agent of the company, from distributing the software outside the company, then the company has not "distributed" the software.

Not that I'm a lawyer, or even have an iota of a clue about this subject (hey, this is /.), but I'd imagine that would be the most likely counterpoint.

mysql, postgres... the facts please

[greenail]

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.

Re:mysql, postgres... the facts please

[bucknuggets]

> 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.

It is extremely simple...

[Kjella]

...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

Re:It is extremely simple...

[greggman]

It's the other way around, unless your project is internal only you have no right to keep your changes to yourself or the right to require them to abide by any more restrictive rules than the GPL allows for.

In other words, in order for AB to require you to have a commerical license they would need their commerical version to 100% free of any GPLed contributions. Inserting one GPLed contribution into their code would make the entire thing 100% GPLed and therefore they would have to provide some way of obtaining it.

The fact that the main distro (the one used by 5 million sites) is the GPLed distro would suggest that most contributions are GPLed and that it's unlikely the commerical version has keeped those GPLed contributions out. In fact I believe the are 100% the same code. The only difference is the supposed license. That means requiring a commercial license is violating the GPL.

Re:It is extremely simple...

[Anthony Boyd]

In other words, in order for AB to require you to have a commerical license they would need their commerical version to 100% free of any GPLed contributions.

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 does: they require everyone who contributes code to give it to them under no license. In other words, if I contribute a patch to MySQL, they only include it in their product if I certify that I am the copyright holder of that code, and that I give them ownership. Once MySQL has full ownership, they are free to take what is now theirs and license it under any license they wish. Even dual licenses.

Again, when I give them a patch, I don't say, "here is a patch you can use under GPL." If I do that, they reject it. Instead, I have to say, "here is a patch, I give you full ownership, and I can no longer dictate how my own code will be used. Feel free to license it however you wish." And then they do.

Of course, I don't have to offer my patch to them. The GPL only requires that I get my patch "out there" somehow. So if I only want my code to be available under GPL, I don't have to offer it to MySQL. I can just put my patch up on my own web server, offer it only under GPL, and allow people to download it. But if I want MySQL to incorporate it into the official product, I have to give it to them on their terms. The GPL cannot prevent that. It doesn't force the owner of a product to incorporate patches. If it did, then even the FSF would be in trouble, because they do the same thing (ask that full copyright be assigned to them).

Re:It is extremely simple...

[Anthony Boyd]

AB is gambling that no one will fork MySQL and make them irrelavent?

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 part, and they are better at building and extending the product than most of the users would be. The X Windows fiasco took years of unhappiness to boil over. The MySQL team doesn't have unhappiness bubbling under the surface. This entire story is just a misunderstanding, attributing malice where there is none.

Of course, if I'm wrong about that, then I want a fork (just like I did for X Windows). But right now MySQL is doing fine by me.

I don't think so...

[nsandver]

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.

Trust my answers.

[hummassa]

I know what I'm talking about.

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-notarize 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.

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

Re:mysql's GPL != REAL GPL

[jrumney]

Among other things what GPL boils down to is that you are allowed to use the product in any way you want as long as you do not modify it. If you do, you need to release the cahnges under GPL.

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.

GPL LGPL and Databases

[Britz]

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.