incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jukka Zitting <>
Subject Re: Binary dependencies in source releases (Was: [VOTE] Release ManifoldCF 0.5-incubating, RC0)
Date Thu, 29 Mar 2012 12:41:02 GMT

On Wed, Mar 28, 2012 at 5:19 PM, Leo Simons <> wrote:
> Shipping a set of CDDL jars out of some projects that oracle
> has all but abandoned is far beyond my imagined threshold of
> reasonable on the scale. Do you actually see that differently?

Agreed. These are exactly the kinds of questions that legal-discuss@
has been working on. I.e. which kinds of dependencies are acceptable,
and how they should be referenced/included/documented/etc.?

It seems like Roy is much more categorical about this. Assuming I
understand his point correctly, *no* binary dependencies are
acceptable within a source tarball.

What I don't quite (yet) understand is how a reference like
"junit:junit:4.10" to a download service maintained by a third party
is more acceptable than directly including the referenced bits. The
only difference I see is whether we have the right to redistribute
those bits ourselves, but that question is already covered by legal.

Another thing I don't understand is how a configure script compiled by
autoconf from sources in and the autoconf distribution is
any less a binary artifact than a dependency jar. Reviewing a ~1MB
configure script is about as easy as reviewing the decompiled contents
of a binary jar.

That's a lot I don't understand. If this is as clear an issue as is
being claimed, I'm sure someone will jump in to educate me.

> What is the alternative you're thinking of? Is it merely about the
> process by which we clean things up, or is there some other kind of
> more fundamental alternative?

The obvious alternative would be to bless the de facto practice from
the past 10+ years as being acceptable also de jure.


Jukka Zitting

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message