MySQL and the GPL Interesting read and thoughts and discussion about MySQL and "their" interpretation (backed by FSF) of the GPL on Sterling's Blog

Well it looks like the guys at MySQL AB have made a very bad move re. the MySQL 4.1 client libraries. They have made these libraries GPL as opposed to LGPL (these license format of the prior library releases), which simply means that any application that uses these libraries is now a "derivative work" and basically required to unveil source.
I wonder how the tons of LAMP users and developers feel right now, a change of this magnitude in mid-stream! Nice way to treat a community that has built itself around MySQL's LGPL Client Libraries
A few years ago I had to rescue the iODBC (Independent ODBC) SDK project from the hands of FSF (Free Software Foundation), and this was done solely to prevent what MySQL and FSF are attempting to pull off (FSF had a clear understanding of the inherent importance of data that is not necessarily comprehended by LAMP, or the broader industry).
Unfortunately I couldn't locate the Kingsley Idehen vs. Richard Stallman FreeODBC mailing list debate archive re. iODBC anywhere on the net, so this interview link will have to suffice).
Ironically MySQL as opposed to iODBC|ODBC|unixODBC has come to instinctively define data access in the LAMP world, and in doing so the very essence of the ODBC value proposition has been somewhat lost.
ODBC (Open Database Connectivity) is an API (Application Programming Interface) that enables database independent application development. Its implementation architecture enables Applications to bind to a Driver Manager which in turn loads ODBC Drivers. Now, initially this doesn't look like a big deal, but it is, and the situation re. MySQL 4.1 illustrates the benefit of this architecture by protecting LAMP users and developers from the GPL'd 4.1 Client Libraries since MySQL is accessible via ODBC.
note: ODBC Driver developers that use the 4.1 client libraries are "derivative work" and they will have to release source code which means we won't be updating our MySQL ODBC Drivers because we won't be forced into release the source code of our ODBC Drivers.
LAMP applications that are bound to iODBC|unixODBC|Microsoft ODBC will not be exposed to this stunt by FSF and MySQL AB. Why? Because an ODBC based LAMP solution isn't touching those MySQL 4.1 client libraries!
Now if you think that you are stumped simply because you went innocently down the LAMP path by buying into the "MySQL data access is good enough perception", and now find yourself over invested in MySQL specific code (that is data access code bound directly to the MySQL client libraries), please don't worry! There is an Open Source solution called MySQL2ODBC that is based on the pre 4.1 MySQL client libraries that enables your MySQL specific application (which is typical of LAMP solutions) to become iODBC compliant, and this is achieved without a wholesale rewrite of your application.
I have been an ardent ODBC supporter since its inception simply because data is timelessly important, and ODBC provides a critical solution for separating application logic from data repositories.  There is a lot of SQL data driving mission critical business applications globally, and failure to comprehend ODBC's value proposition ultimately results in loss of control over Data, which is the foundation from which Information and Knowledge are derived.
You should never find yourself locked into any database vendor, programming language vendor, operating system vendor, or business application vendor, simply becuase you want exploit your own data.
Ironically the statement above is for the most part the real reason why ODBC has such a bad wrap!