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 [mailto:[email protected]] Sent: Tuesday, June 28, 2011 14:24 To: [email protected] Subject: Re: Category B licenses On Tue, Jun 28, 2011 at 9:10 PM, Michael Stahl <[email protected]> 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 happen.) [ ... ] 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 users. > 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 fetch_tarballs.sh 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 <snip> > 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? Robert [1] http://mail-archives.apache.org/mod_mbox/www-legal-discuss/ [2] https://issues.apache.org/jira/browse/LEGAL
