incubator-ooo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael Stahl <>
Subject Category B licenses
Date Tue, 28 Jun 2011 20:10:12 GMT

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).
i think for some libraries (cairo?) it could be an option to do our 
release builds against system libraries; if i understood correctly it 
should be possible to do this for both Category B and Category X libraries.

while ApacheOOo can never ship Category X libraries, for Category B 
there is this:

"Software under the following licenses may be included in binary form 
within an Apache product if the inclusion is appropriately labeled:
By including only the object/binary form, there is less exposed surface 
area of the third-party work from which a work might be derived; this 
addresses the second guiding principle of this policy. By attaching a 
prominent label to the distribution and requiring an explicit action by 
the user to get the reciprocally-licensed source, users are less likely 
to be unaware of restrictions significantly different from those of the 
Apache License. Please include the URL to the product's homepage in the 
prominent label."

now, some questions:
the sentence on "including only the object/binary form" i don't 
understand at all.
if we ship a binary installation set, then of course it doesn't include 
the source code for anything (except perhaps Python/BASIC code...).

so i guess this refers to a source code release.
but that doesn't make much sense either: what exactly is gained by 
putting binary libraries for a bunch of platforms into a source tarball?
_which_ platforms? all of them? that's going to be huge...
is this sentence perhaps intended specifically for Java libraries?

secondly, "requiring an explicit action to get the reciprocally-licensed 
source", does our existing script qualify?

does an explicit configure flag that enables to fetch 
the Category B source qualify?

would we get any closer to compliance by uploading per-platform binary 
Category B tarballs, which may then fetch and which 
are unpacked during the build?

basically, how can we build an ApacheOOo binary release that includes 
Category B licensed libraries?


"And I don't need to waste my time with a computer just because I am
  a computer scientist.  [Medical researchers are not required to
  suffer from the diseases they investigate.]" -- Edsger W. Dijkstra

View raw message