On Tue, Mar 27, 2012 at 1:16 PM, Roy T. Fielding <field...@gbiv.com> wrote:
> On Mar 27, 2012, at 12:57 PM, Jukka Zitting wrote: > > > Hi, > > > > [dropped infra@, I believe most interested people are already on > general@] > > > > Let's decouple this thread from the specific issue of the ManifoldCF > > release. There's a long tradition of Apache releases like the ones > > ManifoldCF is producing, so turning this suddenly into a blocker is > > IMHO bad business, especially since no legal issues are involved (this > > is about Apache policy). If we do come to the consensus that releases > > like this are contrary to Apache policy, then affected projects should > > be given a reasonable amount of time to adapt. > > I don't see where you get the idea that there is a long tradition of > including binary artifacts within the source package releases at Apache. > There may be specific groups who are apparently lacking the appropriate > clue and stubbornly refuse to read the messages I have sent multiple > times to this mailing list, legal-discuss, and members, but there is > no question whatsoever that a source package cannot include binaries. > It would not be a source package otherwise. > > I think this may be overstating things. The issue should be lack of source code, not presence of binary code. For example, I could have a Java code that relies on a native method implemented in C code. I could have a source package that contains the complete Java and the complete C code, all under ALv2. But do we really want to say that we cannot also include, in the source page, the native code, pre-compiled as a convenience for the developer? The alternative would be that a downstream developer who is modifying only unrelated Java portions of the source code would be required to compile the native code on all platforms in order to create a package. (It would also require the PMC to have rather elaborate build rituals to create that JAR, since it would require that we shuffle libraries across multiple buildbots) -Rob
