Return-Path: X-Original-To: apmail-incubator-ooo-dev-archive@minotaur.apache.org Delivered-To: apmail-incubator-ooo-dev-archive@minotaur.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id DFF4D48E2 for ; Wed, 15 Jun 2011 16:58:13 +0000 (UTC) Received: (qmail 56697 invoked by uid 500); 15 Jun 2011 16:58:13 -0000 Delivered-To: apmail-incubator-ooo-dev-archive@incubator.apache.org Received: (qmail 56651 invoked by uid 500); 15 Jun 2011 16:58:13 -0000 Mailing-List: contact ooo-dev-help@incubator.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: ooo-dev@incubator.apache.org Delivered-To: mailing list ooo-dev@incubator.apache.org Received: (qmail 56643 invoked by uid 99); 15 Jun 2011 16:58:13 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 15 Jun 2011 16:58:13 +0000 X-ASF-Spam-Status: No, hits=0.0 required=5.0 tests=FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_PASS,T_TO_NO_BRKTS_FREEMAIL X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of Mathias_Bauer@gmx.net designates 213.165.64.22 as permitted sender) Received: from [213.165.64.22] (HELO mailout-de.gmx.net) (213.165.64.22) by apache.org (qpsmtpd/0.29) with SMTP; Wed, 15 Jun 2011 16:58:07 +0000 Received: (qmail invoked by alias); 15 Jun 2011 16:57:45 -0000 Received: from e176051199.adsl.alicedsl.de (EHLO [192.168.1.2]) [85.176.51.199] by mail.gmx.net (mp008) with SMTP; 15 Jun 2011 18:57:45 +0200 X-Authenticated: #17242763 X-Provags-ID: V01U2FsdGVkX1+3ehQ5vFi3plnVh/hzdrTwrr8CeN0AmzGvKPbdbs FM2fre5GX33RMj Message-ID: <4DF8E488.5050601@gmx.net> Date: Wed, 15 Jun 2011 18:57:44 +0200 From: Mathias Bauer User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.17) Gecko/20110414 Lightning/1.0b2 Mnenhy/0.8.3 OracleBeehiveExtension/1.0.0.2-OracleInternal ObetStats/CATCATCATCATCATCAFCATLAF_1292428138647-396660266 Thunderbird/3.1.10 MIME-Version: 1.0 To: ooo-dev@incubator.apache.org Subject: Re: External dependencies (was Re: [discuss] remove of binfilter module) References: "\"<4DF7D090.5090000@lippka.com> <4DF7D79D.9020106@gmx.net> <4DF7DA4C.6080007@gmx.ch> <1308091258.3010.26.camel@localhost.localdomain>" <4DF7E7A8.4090901@ahrens-netz.de>" <4DF87460.4010802@gmx.net> <460ddaf3effcbe50956e5843081688c8@tutopia.com> In-Reply-To: <460ddaf3effcbe50956e5843081688c8@tutopia.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 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? >> >> "In principle yes, but..." >> >> 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 correctly. Regards, Mathias