MySQL+ODBC+Database Connectivity Tool: license problem?

[Nicola Cesca]

I'm trying to understand if there is a licensing problem using MySQL database with the NI DB Connectivity Tool. The ODBC provided with are GPL-licensed and I think that if you link you code with it, there can be a problem if you plan to use a license different from GPL.

Moreover I find that NI DB Connectivity Tool is quite slow.

[Yair]

I don't understand the question. The NI DB toolkit is simply a wrapper for various ADO calls with some added management of its own. It shouldn't matter at all which DB it's working with, because you're using a completely standard interface.

 

That said, if you don't like it, you can always use other methods. I know that people posted implementations which call the SQLite DLL directly and it's possible that there are also some for MySQL. If not, you can find simpler wrappers around the ADO calls which should be more efficient. LabSQL is one which comes to mind, but there should also be others.

[Olivier Jourdan]

I'm trying to understand if there is a licensing problem using MySQL database with the NI DB Connectivity Tool. The ODBC provided with are GPL-licensed and I think that if you link you code with it, there can be a problem if you plan to use a license different from GPL.

Moreover I find that NI DB Connectivity Tool is quite slow.

 Have you try this http://sine.ni.com/nips/cds/view/p/lang/en/nid/210228 ? It's not based on ADO calls and it can work on RealTime target. You should perhaps try the demo version.

 

Olivier

[ShaunR]

I'm trying to understand if there is a licensing problem using MySQL database with the NI DB Connectivity Tool. The ODBC provided with are GPL-licensed and I think that if you link you code with it, there can be a problem if you plan to use a license different from GPL.

Moreover I find that NI DB Connectivity Tool is quite slow.

I think you'll find that "linking" has a very specific meaning for GPL licencing rather than "connecting" which is probably what you are thinking (and what ADO facilitates).

[Nicola Cesca]

Maybe I'm wrong, but can you explain me this http://www.mysql.com/about/legal/licensing/index.htmlhttp://www.mysql.com/about/legal/licensing/index.html

[Rolf Kalbermatter]

I think you'll find that "linking" has a very specific meaning for GPL licencing rather than "connecting" which is probably what you are thinking (and what ADO facilitates).

 

Strictly speaking, GPL indeed could be a problem as it is thought by many that the linking clause in the GPL license applies in fact also to dynamic linking, which the ODBC manager has to do no matter what, if he wants to use any ODBC driver. This is exactly the reason why LGPL was invented, which maintains all the protection of GPL on the library code but allows linking the library with other non (L)GPL based code without breaking the license. Again here some feel that LGPL only really allows dynamic linking and static linking is not really proper. I personally tend to agree with this, mostly to be on the safe side.

 

However considering that myODBC is a shared library and the non-GPL ODBC manager in Windows will have to load it and link to it dynamically in ALL cases, the question rises of course what use the myODBC driver would have on Windows if the GPL license would not allow it to be loaded and dynamically linked to by non GPL software.

 

So either the GPL license has to be interpreted at least in this case to intend to allow dynamic linking or the choice of the GPL license instead of LGPL by the myODBC developers is simply stupid. Unfortunately I can't find any specifics about the license of the Connector/ODBC component, just that MySQL itself is GPL, which indeed would make one assume that Connector/ODBC falls under the same license.

 

In any case the LabVIEW Database Toolkit has no direct relation to the myODBC driver, as there lies in fact at least the Windows ODBC manager and then the Windows ODBC-to-ADO bridge in-between. So if loading and using the driver in any Windows ODBC based application is to be considered alright, then using it with the Database Toolkit has to be alright too.