Bug #34209 Inflexibility in Plugin interface could lead to licensing issues
Submitted: 31 Jan 2008 22:53 Modified: 1 Feb 2008 13:12
Reporter: Roland Bouman Email Updates:
Status: Verified Impact on me:
Category:MySQL Server: User-defined functions ( UDF ) Severity:S3 (Non-critical)
Version:5.1.22 OS:Any
Assigned to: CPU Architecture:Any
Triage: Triaged: D4 (Minor) / R3 (Medium) / E3 (Medium)

[31 Jan 2008 22:53] Roland Bouman
The plugin api defined in 


defines constants (defines) for licensing. Apart from the fact that this not very flexible, I believe there is dire need for more licences. In particular, there is need for LGPL license constants. Plugins are shared libraries, and it should be possible for authors to release them under LGPL. 

On a more general note, the current licensing system is not very good - something is wrong when we have to modify the source to accommodate more licenses. 

I'm actually wondering what the value is of pulling this into the interface, esp considering the current implementation. I mean, why can't it be enough for plugin authors to include a license when they distribute source and/or binaries? They have to do so anyhow - it won't be good enough for authors to mark the plugin as say "GPL" in the plugin interface struct and not include the real thing in the source. So why the extra effort?

The problem now is that we can't just ignore the license field. I mean, suppose I want to distribute plugins under say MIT or MPL...or maybe under a license of my own invention. Well, in the interface, there is nothing I can do but mark it as PLUGIN_LICENSE_PROPRIETARY (as the license I want to use is neither GPL nor BSD) - yet at the same time, I may be including a 'real' human readable license that claims to be the opposite of 'proprietary'.

How to repeat:
see include/mysql/plugin.h lines 71..77
and sql/sql_show.cc static my_bool show_plugins(THD *thd, plugin_ref plugin, void *arg), lines 89 and on.

Suggested fix:
Personally, I would argue that obsoletion of this feature would solve it all. If there is a particular reason for keeping this, then at least add LGPL.

I mean, plugins are shared libraries and it would in many cases make a lot of sense to require LGPL rather than GPL. 

I mean, how does this work out for future OEM deliveries...will all our storage engine plugins show up as "GPL" there? So what would the final receiving party have to think of that? That the product they received is GPL? But how can that be...they got it via OEM, so the actual license we used to sell the product is not GPL...