Work at SourceForge, help us to make it a better place! We have an immediate need for a Support Technician in our San Francisco or Denver office.
Please, consider using patch in:
fixing the dlopen() issue with mp4/m4a support.
Not convinced on this patch...
If a user has a collection of flac files then they are going to want the flac plugin, which is dependent on the flac library. If the latter is not installed then compiling gtkpod will ignore that plugin. The flac plugin is optional and the resulting gtkpod is a perfectly valid gtkpod without it.
So, if and only if the user wants mp4 file support will they ensure that libmp4v2 is installed before compiling. The mp4 plugin is dependent on the mp4 library even though a crazy dynamic loading method is required to avoid direct linkage (due to license issues).
I can though use the patch for updating the so version.
Let me know thoughts
> So, if and only if the user wants mp4 file support will they ensure that
> libmp4v2 is installed before compiling. The mp4 plugin is dependent on the
This is not about users compiling their own version of gtkpod, this is about a distribution package.
> mp4 library even though a crazy dynamic loading method is required to avoid
> direct linkage (due to license issues).
The plugin does not *depend* on the libmp4v2 library, at least not at compile time (not even the mp4v2 headers are included). Instead, it uses the library if found at run-time. However, until now it only looked for libraries with SONAME 0 and 1, whereas Debian has already packaged SONAME 2. That's what the second half of my patch fixed.
The other, more important part of my patch is the removal of the conditional HAVE_MP4 which decides if the patch is built at all. It is only set if mp4v2 is detected at build-time which, as stated before, is not necessary. It is built unconditionally with my patch and relies on dlopen() to load the library when needed.
Then, since dlopen() is used in this plugin, a check for its availability should get added to configure.ac or else you might get confronted with severe portability issues in the future. Then the decision to build this plugin or not should be based on the result of this check, not on HAVE_MP4.
Finally, Debian ftp-masters have decided to reject the package because it is legally impossible to link GPL'ed and MPL'ed code together in the same address space and considered the dlopen() mechanism to do exactly this but circumvent the need to explicitely link the plugin against the library.
So if you want to solve the general underlying issue, please consider relicensing the code for both plugins by (1) either adding a license exception that explicitely allows linking against the MPL'ed libmp4v2 library or (2) chosing a less restrictive license, e.g. BSD. Alternatively, another library could get used for mp4 support, like e.g. libavformat or libgpac.
User considerations and ramifications are still pertinent in this case.
If dl_open is installed, which on distros it probably will be then the mp4 plugin would be installed and enabled. However, the user's expectation is then that he/she can import mp4 / m4v / m4a files. If the libmp4v2 library is not installed then this will fail, with an appropriate message about this library being installed.
For all other plugins in gtkpod the contract is that a plugin is only available if all its requisite libraries have been installed. Now in theory I could avoid initialising the plugin at runtime if there is no libmp4v2 but it sound like there is still a problem with this plugin's licence anyway.
The plugin remains in the gtkpod repository for convenience. I distribute unstable rpms with all optional plugins separated out into their own rpms. Thus, its possible for anyone installing gtkpod to avoid this plugin entirely if they wish.
Is this not possible to do on debian by including all genuine GPL plugins in gtkpod and separating out the mp4 plugin into 'debian-universe' (? not sure if that is the correct name). More hassle for the users to install it separately but would fit with the licence requirements.
Personally, the dl_open workaround is circumventing the spirit of the licence and I would rather have a separately licenced plugin distributed independantly with proper dependences just like the flac, ogg and webkit plugins.
Please come back with further discussion as this problem has been around for a while and really needs a proper resolution.
> If dl_open is installed, which on distros it probably will be then the mp4
> plugin would be installed and enabled. However, the user's expectation is
For the moment, this is not true.
Even the other way round is possible: You can have libmp4v2 installed at build-time, thus the m4a/mp4 plugin gets build, but since it does not explicitely link against libmp4v2, you could remove this library afterwards and the plugins still won't work.
> then that he/she can import mp4 / m4v / m4a files. If the libmp4v2 library
> is not installed then this will fail, with an appropriate message about
> this library being installed
Yes, why not, sounds reasonable.
In Debian, this could get expressed by means of weeks package dependencies, e.g. Recommends or Suggests.
> Is this not possible to do on debian by including all genuine GPL plugins
> in gtkpod and separating out the mp4 plugin into 'debian-universe' (? not
> sure if that is the correct name).
It is possible and the rejected package in question followed this approach. However, it does not help as long as the license of the plugin itself is incompatible to the license of the library it is about to use. The only person who is able to make both licenses fit is the copyright holder of the gtkpod plugins, Jorg Schuler.
In the current situation, it is quite impossible for distributions to package the m4a/mp4 plugins, as they code they load contradicts their own license. It is simply not legal.
> Personally, the dl_open workaround is circumventing the spirit of the
> licence and I would rather have a separately licenced plugin distributed
> independantly with proper dependences just like the flac, ogg and webkit
This is another solution. But it would require to either rewrite the plugins from scratch under another license or to relicense the existing ones. In the latter case, I see no reason not to keep it included in the gtkpod package, as the spirit of the (non-GPL) license would not be tainted.
I'll see if I can get Jorg's approval to relicense the m4a and mp4 plugins to match the libmp4v2 library.
That's said I am a little fuzzy on how that would look in the end:
User installs gtkpod, libgtkpod, libmp4filetype and libmp4v2 with the first two under GPL (from gtkpod.deb) and latter two under MPL. (from gtkpod-mp4-filetype.deb).
At runtime, gtkpod links to libgtkpod which links to libmp4filetype which links to libmp4v2. Now I think that is fine under the GPL, is it?
> I'll see if I can get Jorg's approval to relicense the m4a and mp4 plugins
> to match the libmp4v2 library.
OMG no! Please do not relicense the plugin under the MPL to match the libmp4v2 license!
The MPL must be avoided under all circumstances. One must not link GPL and MPL code, c.f.
"This is a free software license which is not a strong copyleft; unlike the X11 license,
it has some complex restrictions that make it incompatible with the GNU GPL.
That is, a module covered by the GPL and a module covered by the MPL cannot
legally be linked together. We urge you not to use the MPL for this reason."
> User installs gtkpod, libgtkpod, libmp4filetype and libmp4v2 with the first
> two under GPL (from gtkpod.deb) and latter two under MPL. (from
Please choose a license for the plugins that is neither GPL nor MPL but compatible to both, e.g. a BSD license.
> At runtime, gtkpod links to libgtkpod which links to libmp4filetype which
> links to libmp4v2. Now I think that is fine under the GPL, is it?
No, MPL code must not get loaded by GPL code, not by linking and (strictly speaking) not by dlopen()ing. That's what this whole issue is about.
I was thinking more of relicencing the plugin under the LGPL.
However, reading more into this it seems that a similar problem exists with the gstreamer based plugins (http://gstreamer.freedesktop.org/documentation/licensing.html).
Reading http://www.gnu.org/licenses/gpl-faq.html#GPLAndPlugins, it would appear that licencing plugins under the LGPL would at least get us some way forward.
It would also imply that libgtkpod (the gtkpod core library) should in fact be LGPL since the plugins link to it for return communication.
Anything that can be added much appreciated.
> Reading http://www.gnu.org/licenses/gpl-faq.html#GPLAndPlugins, it would
> appear that licencing plugins under the LGPL would at least get us some way
Maybe, but that's another issue and won't help the linking against MPL'ed libraries.
I'd recommend to convince the copyright holder of the m4a/mp4 plugins to add a special linking exception to the GPL license:
"As a special exception, the copyright holders of this library give you
permission to link this library with independent modules to produce an
executable, regardless of the license terms of these independent modules,
and to copy and distribute the resulting executable under terms of your choice,
provided that you also meet, for each linked independent module, the terms and
conditions of the license of that module. An independent module is a module
which is not derived from or based on this library. If you modify this library,
you may extend this exception to your version of the library, but you are not
obligated to do so. If you do not wish to do so, delete this exception
statement from your version."
This is e.g. used in IcedTea.
BTW, the Debian ftp-masters gave a similar advice when they rejected the gtkpod package with this plugin enabled:
"I'm rejecting the package. Even though the plugin does not link the
MPL-licensed mp4v2 library, it uses dlopen() for the same effect.
However I believe shipping GPL-incompatible plugins for a GPL-licensed program
such as gtkpod is okay as long as the GPL part does not depend on the
GPL-incompatible part. That is I would accept the package if the mp4 plugin
was shipped in a separate binary package (as already done) and the license for
the plugin would allow linking the mp4v2 library (ie. a linking exception or a
more permissive license than the GPL)."
Sounds like a good pragmatic way forward.
I have already pinged Jorg about this as a first step so it should get sorted as soon as possible.
Thanks for your help