incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rob Weir <>
Subject Re: Binary dependencies in source releases (Was: [VOTE] Release ManifoldCF 0.5-incubating, RC0)
Date Wed, 28 Mar 2012 15:25:46 GMT
On Tue, Mar 27, 2012 at 1:16 PM, Roy T. Fielding <> 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)


  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message