Sent from my mobile device (so please excuse typos) On 16 Jun 2011, at 04:39, Greg Stein <[email protected]> wrote:
> On Wed, Jun 15, 2011 at 12:09, Pedro Giffuni <[email protected]> wrote: >> On Wed, 15 Jun 2011 10:59:12 +0200, Mathias Bauer <[email protected]> >> ... >>> Correct me if I'm wrong, but my understanding was that nowhere in the >>> code repository we can have code that links against LGPL code. And of >>> course extensions are part of our code base also. > > The repository can contain code that is licensed with a permissive > license (ALv2, MIT, BSD). See http://www.apache.org/legal/resolved.html Ross > Of course, we try to have only "our" code, > but over in httpd is a copy of PCRE, and APR has a copy of Expat. > Stuff that is not "our" code must be listed in the NOTICE file. > > We cannot have any code in the repository that has a reciprocal license. > >> We can link LGPL'd code (Qt and GTK are examples) we just can't >> carry it. > > We can only link to LGPL'd code *if* directed by a build flag. It > cannot be a required dependency. > > In short: the product must be capable WITHOUT that LGPL'd library. > > That said, I believe that Qt and GTK fall into the "base operating > system library" exclusion to that rule. > >> ... >>> Some filters do it this way, some don't. So some may become >>> extensions, some can't. Usually it is quite some work to do to get >>> filter code into a state that allows to use the filter as an >>> extension. Must be checked for each filter individually. >>> >> >> If we can't move it to extension we may be able to make the build >> conditional anyways. Something like: >> ./configure --with-binfilter > > Right. > >> but LGPL dependencies have to be moved out of the tree. > > They can stay in the tree, as long as they are optional (as you point > out: build flag, or a runtime config or load, or something). > >> ... > > Cheers, > -g
