On Fri, 2011-02-25 at 20:44 -0500, Paul Davis wrote:
True, but there's good reasons those requirements are there. Perhaps
there is use for a "LGPL without relink" requirements, but... oh well.
(Obligatory disclaimer: I am not a lawyer, and the following is not
Note that relinking is inherently trivial with the typical use of LV2,
since it's an interface for dynamically loaded modules, but it is
possible to use the LV2 interface statically, which (though pretty
weird) might make sense in some embedded scenarios.
The LGPL is a tool for keeping your library implementation free. For
lv2.h, there isn't even an implementation to keep free. It's all a bit
silly anyway; you could easily take an LV2 plugin binary and clean-room
reverse engineer a compatible spec without having ever even heard about
lv2.h, let alone seen or copied it. Restrictive licenses have no place
in generic(*) plugin APIs! (yes, I'm looking at you, Steinberg). A more
liberal license seems more appropriate, particularly since widespread
adoption of LV2, including by proprietary software, is desirable, and a
win for free software (and everyone). If this is a blocker for
implementing LV2 on mobile devices or whatever, that's a problem. The
license is just being a nuisance and hindering progress without
protecting anything anyway.
If we want to do it, this is the copyright situation:
Copyright (C) 2000-2002 Richard W.E. Furse, Paul Barton-Davis,
Copyright (C) 2006-2010 Steve Harris, David Robillard.
Everyone here is still active, except perhaps Richard? IIRC his
disappearance became a problem with LADSPA ID allocation...
1) Does everyone present support making lv2.h 2-clause BSD? Some other
alternative, perhaps? (you can also explicitly absolve yourself of the
copyright if you'd prefer)
2) Is Richard contactable? If not, what was his contribution to
ladspa.h, and has it actually made it in to lv2.h? Much has been removed
(lv2.h is roughly half the size of ladspa.h), it's quite possible it has
Personally, I could go either way. I'm down if everyone else is.
(* Note the "generic" part is important, since module and host are not
derivative works of each other, which is not true of all modules)
Linux-audio-dev mailing list