incubator-ooo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Stein <>
Subject Hauling in third-party code (was: Category B licenses)
Date Tue, 28 Jun 2011 23:19:18 GMT
On Tue, Jun 28, 2011 at 16:10, Michael Stahl <> wrote:
> hi all,
> one thing that is currently unclear to me is whether/how Apache OOo may
> depend on code licensed under a Category B license.
> the most prominent specimen of this category is the MPL.
> first, about OOo:
> how we currently build external libraries:
> the external libraries are not checked into the HG repository; they reside
> (as source tarballs) on some FTP server.
> the repository contains things to build the external library:
> * a script, which is executed as part of "bootstrap"
>  and downloads all the tarballs
> * for every external library, a module, containing:
>  - patches to fix bugs that affect OOo
>  - patches to backport security fixes (taken from upstream)
>  - patches to make it build in our environment (especially on windows)
>  - more bizarre patches :)
>  - a to drive the build: call configure with proper flags,
>    then make, ...
>  - dependency metadata (prj directory)
> during the build, the downloaded external library tarball is unpacked,
> built, and the binaries and headers copied to a global directory.
> one thing should be perfectly clear: if there is an external C/C++ library
> that builds in our environment on all platforms without needing to be
> patched, then i haven't seen it; i don't think such a creature exists.
> of course for all the external modules it's possible to tell configure to
> not build the module in OOo but instead use the library on the system (which
> in many cases of course only works on GNU/Linux or *BSD).

This process sounds exactly like what the "buildout" tool[1] is
designed to handle. It seems like a good opportunity to move from
OOo's homegrown system to something that is supported, documented, and
maintained by others.

Reviewing those patches would also be good. Try and get more of them
upstream. For example, I saw some patches to Neon in there which
should get pushed upstream, and also move to the latest version of




View raw message