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?" :-) > > 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. > > "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? >
Drilling into the details now, but another question has come up related to packaging of the weak copyleft (category b) dependencies in releases, related to header files. If we have a dependency on an MPL component, then we do not include its source in our source release. But what about the component's C/C++ header file, which generally is defining the interface to the module, to satisfy the compiler's, encourage strong type checking, etc. Should we remove the header files from the source release as well? -Rob > Robert >
