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 fetch_tarballs.sh 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 makefile.mk 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:
http://www.apache.org/legal/resolved.html#category-b
"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 fetch_tarballs.sh script qualify?
does an explicit configure flag that enables fetch_tarballs.sh to fetch
the Category B source qualify?
would we get any closer to compliance by uploading per-platform binary
Category B tarballs, which fetch_tarballs.sh 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?
confused,
michael
--
"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
