[opensource-dev] LGPL violation

Carlo Wood carlo at alinoe.com
Sat Oct 23 04:27:54 PDT 2010


I am not a lawyer :p, but I think that it is allowed to link an LGPL-ed
library statically against a proprietary executable provided you
provide the object code or source code of the work that uses the library.

In other words, it must be possible to make changes to Qt and *relink*.

Translating that idea to linking statically with a shared library, it
is clear that one still has to be able to make changes to Qt and relink,
or they are non-compliant. This means they must provide all the object
code that was used to create (link) libmedia_plugin_gstreamer.so, or
they must provide the source code so that people can generate this
object code themselves.

Imho, the only practical solution is to make the source code availabe,
and most likely just all the source code of the whole viewer.

On Fri, Oct 22, 2010 at 07:02:18PM -0700, Erik Anderson wrote:
> Not sure this is worth sending to the list, but could you clarify that .so
> files are statically linked to the executable that they are loaded into?  This
> is a bit confusing to me.
> 
> Or are they considered statically linked if you use the default dynamic loading
> logic, rather than hand-coding GetProcAddr calls or equivalent?

Nah - none of that. libmedia_plugin_gstreamer.so (the extension is different
on OS other than linux I guess) is a shared library. However, it is constructed
by linking statically with a modified version of Qt that was created by LL.
Obviously, the users need to know what those mods are and they should be
allowed to make changes of their own.

For example, someone who already made changes to this version of Qt would
not be able to use the mesh viewer until LL releases the full source code,
so they are non-compliant if they release a 'beta' version of a viewer without
providing the means to re-link libmedia_plugin_gstreamer.so with a different Qt.

-- 
Carlo Wood <carlo at alinoe.com>


More information about the opensource-dev mailing list