openoffice-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mathias Bauer <>
Subject Re: External dependencies (was Re: [discuss] remove of binfilter module)
Date Wed, 15 Jun 2011 16:57:44 GMT
On 15.06.2011 18:09, Pedro Giffuni wrote:
> On Wed, 15 Jun 2011 10:59:12 +0200, Mathias Bauer
> <> wrote:
>> On 15.06.2011 04:36, Greg Stein wrote:
>>> On Tue, Jun 14, 2011 at 21:50, Pedro Giffuni<>
>>> wrote:
>>>> ...
>>>> But some of that stuff is actually bloatware. I think libwpd, libwps
>>>> and libwpg are basically in the same boat as binfilter: the
>>>> functionality shall me made optional as external modules in the
>>> By moving these importers over to *optional* extensions, then we can
>>> do several things:
>>> 1) simplify the initial build and dependencies, moving us towards a
>>> buildable and useful package
>>> 2) add the functionality back in over time as developers' interest
>>> focuses on it
>>> 3) retaining the optional status allows linking to LGPL and similar
>>> weak-copyleft libraries
>> 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.
> We can link LGPL'd code (Qt and GTK are examples) we just can't
> carry it.
>>> This goes back to a question that I had before: can file importers fit
>>> into OOo's extension system?
>> <radio Erewan>"In principle yes, but..."</radio Erewan>
>> Here's the "but": "real" extensions must use stable APIs based on UNO
>> when the call into OOo and they also must export all their
>> functionality through such APIs.
>> 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
> but LGPL dependencies have to be moved out of the tree.
>> BTW: none of our current filters has code not (co-)owned by Oracle,
>> IIRC, so all existing filters could be made available under the ASL.
> If libwpd and others can be relicensed they are not a problem (yet).

Sorry, of course I was wrong. There are some filters that we can't use 
with ASL as the code of the filter depends on LGPL libs. But that is 
true for extensions we have in our repository also, if I understood 


View raw message