On Tue, Jun 28, 2011 at 11:42 PM, Dennis E. Hamilton <[email protected]> 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 possible... Robert
