incubator-ooo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Robert Burrell Donkin <>
Subject Re: Category B licenses
Date Wed, 29 Jun 2011 11:18:37 GMT
On Tue, Jun 28, 2011 at 11:42 PM, Dennis E. Hamilton
<> wrote:
> 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.

IMHO this is an area of shared interest where we should definitely be
talking and working with those folks

IMO this is essential a tooling problem. For projects as large and
complex as office, comprehension of the code base, the build and
assembly starts to become a major issue. A finely grained, loosely
coupled component structure with a simple license for each component
goes some way towards solving this problem by allowing each component
to be small enough to be understood. But this still leaves tooling gap
for a comprehension and verification for the assembled artifact
shipped to end users.

> If the external material is statically linked or otherwise integrated into the Apache
code in its build, I think there are concerns, of course

I tend to think in terms of build and assembly as different activities
requiring different tools and techniques. AIUI (from comments earlier
in this thread) OOo already uses a compositional scripting layer for
assembly which then choreographs the build. IMHO it's not such a long
journey from that towards a compositional assembly tool that automates
and reports the license and provenance wrangling.

> and with comingling in source compilations in some way even more-so.

Mixing licenses in source causes major difficulties for developers and
downstream consumers. Most successful FOSS projects tend to adopt a
homogeneous regime. So FOSS tends to factor along license lines. One
way to look at the Apache categories is that they specify which
licenses are sufficiently compatible with the Apache License to be
included within the source.

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

AIUI to ship artifacts for end users, executables are going to need to
be assembled from a complex mixture of resources. Going forward, IMO
separating these concerns by isolating the assembly is likely to make
everything work more smoothly.

> And even then maybe we need to go to legal-discuss.

Apache policy is evolutionary. OOo brings some new challenges and this
means refinement is likely. It's best to start talking as early as


View raw message