On Fri, Aug 7, 2009 at 9:28 AM, jaromil<jaromil(a)dyne.org> wrote:
in a past thread (feb. 2004) on the piksel list
regarding licensing of
video plugins, i've asked the FSF regarding this issue and got this
reply:
"Legally speaking, there's never been a case which discussed
this. FSF believes that dlopen operates the same way as
compile-time linking." Dave Turner GPL Compliance Engineer
which of course is both correct and incorrect. the end result of
calling dlopen() is the same in terms of code execution possibilities
and pathways.
but compile-time (dynamic) linking on any modern system creates
unavoidable dependencies that means that the linked code cannot
execute without the required libraries. this is not true of dlopen(),
at least for the cases we are interested in for the plugin situation.
ardour's code contains no references to any LADSPA plugins (or LV2 or
LV2 or AudioUnit etc). it can, at the user's discretion, load and
execute these plugins. if the user never takes an action that
explicitly indicates that they want to use a plugin, then ardour will
function exactly the same on a system that has the plugins installed
and one that does not. i cannot understand how the FSF can possibly
equate this with dynamic compile time linkage, in which the program
cannot startup or function normally in the absence of the correct
version of all the linked libraries.
the problem with the GPL in this context is mostly that its unclear.
ardour uses libfftw which is GPL'ed. does this mean that we violate
the GPL license of FFTW when we allow users to load non-GPL'ed plugin
code even though the plugin code doesn't use FFTW in any way? and if
this is a violation, when does it occur? what happens if we create a
"mere aggregation" of ardour plus 1 or more non-GPL'ed plugins and
distribute that? does distributing that violate the GPL on FFTW, even
though ardour has not been linked against the plugins?
--p