On Thu, Oct 20, 2011 at 9:06 AM, Robert Burrell Donkin <[email protected]> wrote: > <snip> > > On Tue, Oct 18, 2011 at 5:08 PM, Rob Weir <[email protected]> wrote: >> >> I'm trying, with some difficulty, to interpret what we can do based on the >> description here: >> >> http://www.apache.org/legal/resolved.html#category-b >> >> How does this fit into a release strategy that has both source and >> binary releases. > > Let me turn that around and start to answer "how can an appropriate > release strategy be formulated that abides by these rules?" :-) >
I can't really say yet, since some aspects of those rules are still obscure to me. But let's push ahead with the discussion, and hopefully arrive at clarity. > IMHO understanding the way Apache uses these terms is key > > At Apache, a "source release" is (just) what's in version control when > the release is cut, is canonical and mandatory. Other artifacts follow > the "binary release" rules, are optional and secondary. > OK. So obviously no "weak" copyleft source files in our source release, i.e., in our source tarballs. What was not clear was what we meant, in regards to weak copyleft, by "Software under the following licenses may be included in binary form within an Apache product if the inclusion is appropriately labeled". Does this mean: A) We can include MPL binaries such as a JAR or a native code lib, DLL. or object file in a source release? or B) We can include MPL binary code only in our binary releases? When it says "In an Apache product" is that something different than a release? Is a source release a product? > "Source releases" are aimed at downstream developers. Amongst this > audience are downstream packagers. An important aim of the "source > release" rules is to allow downstream developers to confidently create > derivative works without excessive effort checking licenses. > > "Binary releases" are everything else, including artifacts containing > source code in combination with other works. > > > More explanation? Questions? Opinions? Comments? Objections? > I think it is important that downstream developers can take our source releases and build them without: 1) "Excessive license checking" as you say, 2) But also without excessive downloading of scattered prerequisites from all over the web So there is some tension here, between what we include in the source release, as a convenience to the developer, and what we specify as a pre-req for them to download and provision on their own. The approach we currently have for these components, in OpenOffice, is: 1) The 3rd party components are stored in a separate repository, not with the core product's SVN. So we reduce the opportunity for contamination. 2) The build script downloads the source for these components and compiles them. So we avoid the pre-req/provisioning issue. And we don't need to include the MPL code in the source distribution. It comes down automatically at build time, That may satisfy the letter of what I'm reading. But I'd be interested to hear what you think, whether something like that had been done at Apache before. Maybe it would be better, for example, to allow two build modes, one with and one without the copyleft components, and force the downstream developer to explicitly enable the compilation with weak copyleft components by changing a flag or something? -Rob > Robert >
