External dependencies (was Re: [discuss] remove of binfilter module)

[Pedro Giffuni <gi...@tutopia.com>]

 On Wed, 15 Jun 2011 00:58:48 +0200, Kai Ahrens <ka...@ahrens-netz.de> 
 wrote:
> Hi Andrea,
>
> Am 15.06.2011 00:40, schrieb Andrea Pescetti:
 ...<snip>
>> Even though I highly trust the developers when they say that 
>> binfilter
>> is unmanageable, I share these concerns. It would be best to package
>> binfilter as an extension if feasible, or at least to have a simple
>> conversion tool available for download (not an older version of OOo, 
>> but
>> a small, dedicated tool that users could download if needed, and 
>> that
>> can be run separately from OOo).
>
> I'm absolutely fine with this proposal. I just don't want to have 
> this
> code within the bare OOo product itself.
>
> Regards
> Kai

 I think we have to consider making a lot more stuff into extensions
 or whatever means to make the build optional. One "Mike Meeks" found
 that we have to clean up the source of some copyleft components:

 http://people.gnome.org/~michael/blog/2011-05-26.html

 I mentioned in Rob Weir's blog that there are replacements for
 some stuff

 gnu regex --> Google RE2
 Hunspell  --> ispell

 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
 and maybe carried previous openoffice repositories. Perhaps the LO
 guys want to maintain them.

 cheers,

 Pedro

Re: External dependencies (was Re: [discuss] remove of binfilter module)

[Ross Gardler <rg...@opendirective.com>]

On 17 June 2011 13:59, Jens-Heiner Rechtien <jh...@web.de> wrote:

...

> I knew this laziness with the copyright banner on files would hurt as some
> day ... Fixing copyright headers was a never ending task, I guess this will
> get better now :-)

Checking licence headers is one of the due diligence process during
release here at the ASF. We have a tool that helps (might need some
tweaking to make it work on C/C++ files). This tool is integrated into
the continuous integration tools at the ASF. It would be well worth
using it in OOo (when the time is right).

See http://incubator.apache.org/rat

Ross

-- 
Ross Gardler <rg...@opendirective.com>
Programme Leader (Open Development)
OpenDirective http://opendirective.com

Re: External dependencies (was Re: [discuss] remove of binfilter module)

[Jens-Heiner Rechtien <jh...@web.de>]

On 06/16/2011 06:15 PM, Mathias Bauer wrote:
> On 16.06.2011 16:45, Rob Weir wrote:
>> On Wed, Jun 15, 2011 at 11:39 PM, Greg Stein<gs...@gmail.com> wrote:
>>> On Wed, Jun 15, 2011 at 12:09, Pedro Giffuni<gi...@tutopia.com>
>>> wrote:
>>>> On Wed, 15 Jun 2011 10:59:12 +0200, Mathias
>>>> Bauer<Ma...@gmx.net>
>>>> ...
>>>>> 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). 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.
>>>
>>
>> Could you clarify one thing for me, please?
>>
>> I thought we could take the Oracle code as-is, and check it in, verify
>> that it is complete and builds, but that we would then be required to
>> resolve the license issues before could have a release or graduate.
>> Is that incorrect? Are we required to resolve these issues before we
>> even accept the SGA'ed code? It makes it difficult to collaborate on
>> resolving these issues if we cannot get the initial code into SVN.
>>
>> -Rob
>>
>
> The Oracle code as-is will not be sufficient to build anything.
> The initial list of files from Oracle misses several thousand files
> (e.g. nearly the complete build system files) because these files don't
> have copyright headers in them. To the best of my knowledge, they are
> under Oracle's copyright, but it's not up to me to decide on that.

I knew this laziness with the copyright banner on files would hurt as 
some day ... Fixing copyright headers was a never ending task, I guess 
this will get better now :-)

>
> People are working on that, but we obviously have to wait. Let's use the
> time to go through all files where the copyright situation is unclear or
> where we already know that the copyright holder is someone else (I have
> posted a first list already).
>

Heiner

-- 
Jens-Heiner Rechtien
hr@openoffice.org
jhrechtien@web.de

Re: External dependencies (was Re: [discuss] remove of binfilter module)

[Mathias Bauer <Ma...@gmx.net>]

On 16.06.2011 23:33, Andrew Rist wrote:
>
> On 6/16/2011 9:15 AM, Mathias Bauer wrote:
>> On 16.06.2011 16:45, Rob Weir wrote:
>>> On Wed, Jun 15, 2011 at 11:39 PM, Greg Stein<gs...@gmail.com> wrote:
>>>> On Wed, Jun 15, 2011 at 12:09, Pedro Giffuni<gi...@tutopia.com>
>>>> wrote:
>>>>> On Wed, 15 Jun 2011 10:59:12 +0200, Mathias
>>>>> Bauer<Ma...@gmx.net>
>>>>> ...
>>>>>> 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). 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.
>>>>
>>>
>>> Could you clarify one thing for me, please?
>>>
>>> I thought we could take the Oracle code as-is, and check it in, verify
>>> that it is complete and builds, but that we would then be required to
>>> resolve the license issues before could have a release or graduate.
>>> Is that incorrect? Are we required to resolve these issues before we
>>> even accept the SGA'ed code? It makes it difficult to collaborate on
>>> resolving these issues if we cannot get the initial code into SVN.
>>>
>>> -Rob
>>>
>>
>> The Oracle code as-is will not be sufficient to build anything.
>> The initial list of files from Oracle misses several thousand files
>> (e.g. nearly the complete build system files) because these files
>> don't have copyright headers in them. To the best of my knowledge,
>> they are under Oracle's copyright, but it's not up to me to decide on
>> that.
>>
>> People are working on that, but we obviously have to wait. Let's use
>> the time to go through all files where the copyright situation is
>> unclear or where we already know that the copyright holder is someone
>> else (I have posted a first list already).
>>
>> Regards,
>> Mathias
>>
> I think this is a misunderstanding of "the Oracle code". I think Rob is
> talking about the entire contents of the OOo source control, where
> Mathias is thinking of the files in the SGA.
>
> So the questions are:
> - Is there anything in the Apache process that stops us from pulling in
> the entire source control from OOo?
> - Will that set of files enable us to build OOo (across platforms, etc.)?
> - Is that the best starting place for beginning the code remediation,
> like removing bits that cannot be relicensed, or are not license
> compatible?

That sounds like a great idea that would allow us to work on the 
different duties (checking licences and copyright, bootstrapping the 
build etc.) in parallel.

As Greg pointed out that our incubator status can allow us to do so, I 
would welcome this way of operation. As I wrote in another mail, in this 
case we should export the code from the OOO340m1 milestone, apply my 
list of "naughty" files to remove them and see what adjustments in the 
build this will cause. In the meantime we also can continue to look for 
more "naughty" files.

We also have to check how to deal with "external" source tarballs we 
used to pull in before the build starts (this happens in the "bootstrap" 
step). My recommendation is to do it in the same way: create the first 
build with all of them and remove the LGPL stuff step by step, adding 
configure switches to allow for optional builds in case they don't exist.

Regards,
Mathias

Re: External dependencies (was Re: [discuss] remove of binfilter module)

[Andrew Rist <an...@oracle.com>]

On 6/16/2011 9:15 AM, Mathias Bauer wrote:
> On 16.06.2011 16:45, Rob Weir wrote:
>> On Wed, Jun 15, 2011 at 11:39 PM, Greg Stein<gs...@gmail.com>  wrote:
>>> On Wed, Jun 15, 2011 at 12:09, Pedro Giffuni<gi...@tutopia.com>  
>>> wrote:
>>>> On Wed, 15 Jun 2011 10:59:12 +0200, Mathias 
>>>> Bauer<Ma...@gmx.net>
>>>> ...
>>>>> 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). 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.
>>>
>>
>> Could you clarify one thing for me, please?
>>
>> I thought we could take the Oracle code as-is, and check it in, verify
>> that it is complete and builds, but that we would then be required to
>> resolve the license issues before could have a release or graduate.
>> Is that incorrect?  Are we required to resolve these issues before we
>> even accept the SGA'ed code?  It makes it difficult to collaborate on
>> resolving these issues if we cannot get the initial code into SVN.
>>
>> -Rob
>>
>
> The Oracle code as-is will not be sufficient to build anything.
> The initial list of files from Oracle misses several thousand files 
> (e.g. nearly the complete build system files) because these files 
> don't have copyright headers in them. To the best of my knowledge, 
> they are under Oracle's copyright, but it's not up to me to decide on 
> that.
>
> People are working on that, but we obviously have to wait. Let's use 
> the time to go through all files where the copyright situation is 
> unclear or where we already know that the copyright holder is someone 
> else (I have posted a first list already).
>
> Regards,
> Mathias
>
I think this is a misunderstanding of "the Oracle code".  I think Rob is 
talking about the entire contents of the OOo source control, where 
Mathias is thinking of the files in the SGA.

So the questions are:
  - Is there anything in the Apache process that stops us from pulling 
in the entire source control from OOo?
  - Will that set of files enable us to build OOo (across platforms, etc.)?
  - Is that the best starting place for beginning the code remediation, 
like removing bits that cannot be relicensed, or are not license compatible?

Andrew

Re: External dependencies

[Dave Fisher <da...@comcast.net>]

On Jun 17, 2011, at 12:13 AM, Mathias Bauer wrote:

> On 17.06.2011 00:40, Greg Stein wrote:
>> On Thu, Jun 16, 2011 at 12:15, Mathias Bauer<Ma...@gmx.net>  wrote:
>>> ...
>>> The Oracle code as-is will not be sufficient to build anything.
>>> The initial list of files from Oracle misses several thousand files (e.g.
>>> nearly the complete build system files) because these files don't have
>>> copyright headers in them. To the best of my knowledge, they are under
>>> Oracle's copyright, but it's not up to me to decide on that.
>>> 
>>> People are working on that, but we obviously have to wait. Let's use the
>> 
>> Woah. Wait a second... What people?
>> 
>> As far as I was aware, you're the only person assembling a list of
>> files that we need, which we don't already have under Oracle's SGA.
>> 
>> Cheers,
>> -g
>> 
> 
> I'm just the one who assembled lists. I'm not the one to use them. But the discussion in other threads meanwhile showed what is going on.

We are working on the sub-domain / openoffice project list.[1]

The external project's purpose is to track IP that does not follow the standard license [2]

I hope that this is helpful.

Regards,
Dave

[1] https://cwiki.apache.org/confluence/display/OOOUSERS/OpenOffice+Domains
[2] http://external.openoffice.org/

Re: External dependencies (was Re: [discuss] remove of binfilter module)

[Mathias Bauer <Ma...@gmx.net>]

On 17.06.2011 00:40, Greg Stein wrote:
> On Thu, Jun 16, 2011 at 12:15, Mathias Bauer<Ma...@gmx.net>  wrote:
>> ...
>> The Oracle code as-is will not be sufficient to build anything.
>> The initial list of files from Oracle misses several thousand files (e.g.
>> nearly the complete build system files) because these files don't have
>> copyright headers in them. To the best of my knowledge, they are under
>> Oracle's copyright, but it's not up to me to decide on that.
>>
>> People are working on that, but we obviously have to wait. Let's use the
>
> Woah. Wait a second... What people?
>
> As far as I was aware, you're the only person assembling a list of
> files that we need, which we don't already have under Oracle's SGA.
>
> Cheers,
> -g
>

I'm just the one who assembled lists. I'm not the one to use them. But 
the discussion in other threads meanwhile showed what is going on.

Regards,
Mathias

Re: External dependencies (was Re: [discuss] remove of binfilter module)

[Greg Stein <gs...@gmail.com>]

On Thu, Jun 16, 2011 at 12:15, Mathias Bauer <Ma...@gmx.net> wrote:
>...
> The Oracle code as-is will not be sufficient to build anything.
> The initial list of files from Oracle misses several thousand files (e.g.
> nearly the complete build system files) because these files don't have
> copyright headers in them. To the best of my knowledge, they are under
> Oracle's copyright, but it's not up to me to decide on that.
>
> People are working on that, but we obviously have to wait. Let's use the

Woah. Wait a second... What people?

As far as I was aware, you're the only person assembling a list of
files that we need, which we don't already have under Oracle's SGA.

Cheers,
-g

Re: External dependencies (was Re: [discuss] remove of binfilter module)

[Mathias Bauer <Ma...@gmx.net>]

On 16.06.2011 16:45, Rob Weir wrote:
> On Wed, Jun 15, 2011 at 11:39 PM, Greg Stein<gs...@gmail.com>  wrote:
>> On Wed, Jun 15, 2011 at 12:09, Pedro Giffuni<gi...@tutopia.com>  wrote:
>>> On Wed, 15 Jun 2011 10:59:12 +0200, Mathias Bauer<Ma...@gmx.net>
>>> ...
>>>> 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). 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.
>>
>
> Could you clarify one thing for me, please?
>
> I thought we could take the Oracle code as-is, and check it in, verify
> that it is complete and builds, but that we would then be required to
> resolve the license issues before could have a release or graduate.
> Is that incorrect?  Are we required to resolve these issues before we
> even accept the SGA'ed code?  It makes it difficult to collaborate on
> resolving these issues if we cannot get the initial code into SVN.
>
> -Rob
>

The Oracle code as-is will not be sufficient to build anything.
The initial list of files from Oracle misses several thousand files 
(e.g. nearly the complete build system files) because these files don't 
have copyright headers in them. To the best of my knowledge, they are 
under Oracle's copyright, but it's not up to me to decide on that.

People are working on that, but we obviously have to wait. Let's use the 
time to go through all files where the copyright situation is unclear or 
where we already know that the copyright holder is someone else (I have 
posted a first list already).

Regards,
Mathias

Re: External dependencies (was Re: [discuss] remove of binfilter module)

[Kai Sommerfeld <ka...@gmx.de>]

Hi,

On 17.06.11 00:35, Greg Stein wrote:
> On Thu, Jun 16, 2011 at 10:45, Rob Weir<ap...@robweir.com>  wrote:
>> On Wed, Jun 15, 2011 at 11:39 PM, Greg Stein<gs...@gmail.com>  wrote:
>> ...
>>> The repository can contain code that is licensed with a permissive
>>> license (ALv2, MIT, BSD). 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.
>>
>> Could you clarify one thing for me, please?
>>
>> I thought we could take the Oracle code as-is, and check it in, verify
>> that it is complete and builds, but that we would then be required to
>> resolve the license issues before could have a release or graduate.
>> Is that incorrect?  Are we required to resolve these issues before we
>> even accept the SGA'ed code?  It makes it difficult to collaborate on
>> resolving these issues if we cannot get the initial code into SVN.
>
> Code in our repository must fall under one of several terms:
>
> 1) we have a Software Grant for it
> 2) a committer represents they can commit it under their ICLA
> 3) the code has a permissive license (as I detailed above)
>
> Because there is code in the OO.o repository that does not fall under
> one of the above terms, we cannot import it into the ASF repository.
>
> Now, I should amend my earlier statement. While in the Incubator, term
> (3) is relaxed. We cannot make a release with inappropriate licenses,
> and we certainly can't graduate with code in there that has
> inappropriate licenses. But as long as that stuff is worked out
> *within* the Incubator, then we're good. Post-graduation, all three
> terms will apply in strength.
>
  This sounds really good, as it allows us to work on getting a working 
build in parallel to sorting out the license issues (and other things). :-)

  Regards,
Kai.

> Hope that helps!
>
> Cheers,
> -g
>

Re: External dependencies (was Re: [discuss] remove of binfilter module)

[Greg Stein <gs...@gmail.com>]

On Thu, Jun 16, 2011 at 10:45, Rob Weir <ap...@robweir.com> wrote:
> On Wed, Jun 15, 2011 at 11:39 PM, Greg Stein <gs...@gmail.com> wrote:
>...
>> The repository can contain code that is licensed with a permissive
>> license (ALv2, MIT, BSD). 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.
>
> Could you clarify one thing for me, please?
>
> I thought we could take the Oracle code as-is, and check it in, verify
> that it is complete and builds, but that we would then be required to
> resolve the license issues before could have a release or graduate.
> Is that incorrect?  Are we required to resolve these issues before we
> even accept the SGA'ed code?  It makes it difficult to collaborate on
> resolving these issues if we cannot get the initial code into SVN.

Code in our repository must fall under one of several terms:

1) we have a Software Grant for it
2) a committer represents they can commit it under their ICLA
3) the code has a permissive license (as I detailed above)

Because there is code in the OO.o repository that does not fall under
one of the above terms, we cannot import it into the ASF repository.

Now, I should amend my earlier statement. While in the Incubator, term
(3) is relaxed. We cannot make a release with inappropriate licenses,
and we certainly can't graduate with code in there that has
inappropriate licenses. But as long as that stuff is worked out
*within* the Incubator, then we're good. Post-graduation, all three
terms will apply in strength.

Hope that helps!

Cheers,
-g

Re: External dependencies (was Re: [discuss] remove of binfilter module)

[Rob Weir <ap...@robweir.com>]

On Wed, Jun 15, 2011 at 11:39 PM, Greg Stein <gs...@gmail.com> wrote:
> On Wed, Jun 15, 2011 at 12:09, Pedro Giffuni <gi...@tutopia.com> wrote:
>> On Wed, 15 Jun 2011 10:59:12 +0200, Mathias Bauer <Ma...@gmx.net>
>>...
>>> 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). 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.
>

Could you clarify one thing for me, please?

I thought we could take the Oracle code as-is, and check it in, verify
that it is complete and builds, but that we would then be required to
resolve the license issues before could have a release or graduate.
Is that incorrect?  Are we required to resolve these issues before we
even accept the SGA'ed code?  It makes it difficult to collaborate on
resolving these issues if we cannot get the initial code into SVN.

-Rob

Re: External dependencies (was Re: [discuss] remove of binfilter module)

[Ross Gardler <rg...@apache.org>]

Sent from my mobile device (so please excuse typos)

On 16 Jun 2011, at 04:39, Greg Stein <gs...@gmail.com> wrote:

> On Wed, Jun 15, 2011 at 12:09, Pedro Giffuni <gi...@tutopia.com> wrote:
>> On Wed, 15 Jun 2011 10:59:12 +0200, Mathias Bauer <Ma...@gmx.net>
>> ...
>>> 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

Re: External dependencies (was Re: [discuss] remove of binfilter module)

[Greg Stein <gs...@gmail.com>]

On Wed, Jun 15, 2011 at 12:09, Pedro Giffuni <gi...@tutopia.com> wrote:
> On Wed, 15 Jun 2011 10:59:12 +0200, Mathias Bauer <Ma...@gmx.net>
>...
>> 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). 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

Re: External dependencies (was Re: [discuss] remove of binfilter module)

[Mathias Bauer <Ma...@gmx.net>]

On 15.06.2011 18:09, Pedro Giffuni wrote:
> On Wed, 15 Jun 2011 10:59:12 +0200, Mathias Bauer
> <Ma...@gmx.net> wrote:
>> On 15.06.2011 04:36, Greg Stein wrote:
>>> On Tue, Jun 14, 2011 at 21:50, Pedro Giffuni<gi...@tutopia.com>
>>> 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 
correctly.

Regards,
Mathias

Re: External dependencies (was Re: [discuss] remove of binfilter module)

[Pedro Giffuni <gi...@tutopia.com>]

 On Wed, 15 Jun 2011 10:59:12 +0200, Mathias Bauer 
 <Ma...@gmx.net> wrote:
> On 15.06.2011 04:36, Greg Stein wrote:
>> On Tue, Jun 14, 2011 at 21:50, Pedro Giffuni<gi...@tutopia.com>  
>> 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).
 
 cheers,

 Pedro.

Re: External dependencies (was Re: [discuss] remove of binfilter module)

[Mathias Bauer <Ma...@gmx.net>]

On 15.06.2011 04:36, Greg Stein wrote:
> On Tue, Jun 14, 2011 at 21:50, Pedro Giffuni<gi...@tutopia.com>  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.

> 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.

But due to my considerations from above I assume that this doesn't help 
us with LGPL code, right?

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.

Regards,
Mathias

Re: External dependencies (was Re: [discuss] remove of binfilter module)

[Greg Stein <gs...@gmail.com>]

On Tue, Jun 14, 2011 at 21:50, Pedro Giffuni <gi...@tutopia.com> 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

This goes back to a question that I had before: can file importers fit
into OOo's extension system?

>...

Cheers,
-g