incubator-ooo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dennis E. Hamilton" <>
Subject RE: Category B licenses
Date Tue, 28 Jun 2011 22:42:45 GMT
For the magical case of binaries that are not built from the Apache code, what occurred to
me first were shared libraries (.DLL or .SO, as well as CLASSPATH goodies and .JAR files)
and also executables that could be operated silently from within the Apache-code built software
(crude example: how TortoiseSVN installs SVN in some manner and which it is a form of shell
for).  Another example happens to be over font files, something which has had some folks exercised
on LibreOffice lists recently.

If the external material is statically linked or otherwise integrated into the Apache code
in its build, I think there are concerns, of course and with comingling in source compilations
in some way even more-so.
My suggestion for here (ooo-dev) is that we focus on how to minimize the exposed surface to
run-time access to non-Apache resources (that might be co-deployed) wherever we can, so that
nothing is comingled into the build of Apache-source executable or library code itself.  And
even then maybe we need to go to legal-discuss.

-----Original Message-----
From: Robert Burrell Donkin [] 
Sent: Tuesday, June 28, 2011 14:24
Subject: Re: Category B licenses

On Tue, Jun 28, 2011 at 9:10 PM, Michael Stahl <> wrote:

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

(Apache is mailing-list centric and legal-discuss [1] is where good
answers to questions on this topic are to be found but I'll do my
best. It's also where discussions and decisions about refining policy

[ ... ]

Conventionally at Apache, the "source release" is canonical and is
identical to the tagged source in version control. The downstream
ecosystem typically consumes this source and produces installations. A
"binary release" is a (typically compressed) aggregation derived from
the source by some build process and shipped as a convenience for end

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

Not specifically but dynamic and bytecode languages are more likely to
want to ship this sort of thing

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

Running a script sounds like an explicit action to me but it's best to
open an issue so the documentation can be updated [2]. I'm running out
of my (limited) computer time for today, so hopefully someone will
beat me to it and jump in with the number


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

Am I right in assuming that we're talking about shipping something
that can be used to install ApacheOOo?



View raw message