incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Leo Simons <>
Subject Re: Binary dependencies in source releases (Was: [VOTE] Release ManifoldCF 0.5-incubating, RC0)
Date Wed, 28 Mar 2012 15:19:23 GMT
On Wed, Mar 28, 2012 at 11:06 AM, Jukka Zitting <> wrote:
> On Wed, Mar 28, 2012 at 1:16 AM, Leo Simons <> wrote:
>> That said, I'm not aware of us actually having such a release out there?
> Take such fringe projects like Ant, Tomcat, Lucene and Xalan that have
> been shipping releases like throughout the past decade.

For the record, with "us" I meant "incubator"...

> See examples
> dating back at least to [1], [2], [3] and [4]. It looks like at least
> Ant and Tomcat have since opted for downloading dependencies at build
> time, but I must have missed the memo if that change was driven by
> Apache policy requirements rather than just the emergence of the
> central Maven repository making such downloads practical.

I know 'something' about the ant example.

If memory serves me well, alexandria, and from that gump, was
originally created in part to help sort out the ant/tomcat/xerces
build situation. There was at some point a pretty 'interesting'
bootstrap+classpath problem because the xerces build used ant, ant
used (sun) java, and java included xerces. Bootstrapping to a
functional java is still hard today.

The xerces that was shipped with ant from version 1.1 through to
version 1.8.2 (released in 2010, 1.8.3 from 2012 is the first one that
doesn't include a xerces implementation) has pretty clear provenance
though, documented in a README alongside the jars: extracted from a
named xerces binary release (which in turn is built from the xerces
source release), and clearly apache licensed. Giving people a new
xerces jar with ant was better than using a broken/old jdk xerces.

So while that was ugly, and I'm glad we apparently finally are at a
point now where the ant folks feel they don't need to ship xerces, by
itself its not a particularly big threat to bootstrappability and code
provenance and that kind of stuff, and the mess is further mitigated
by also having a 'proper' bootstrap in the shape of gump for ant and

It's a bit like downloading a binary version of libc and gcc to
compile libc and gcc. I doubt many people bootstrap GCC, but at the
same time I think a lot of people are aware it's possible, and a lot
of people (linux kernel developers, for example) would be unhappy if
it would somehow become impossible.

I.e. if you look at ...

> 2. Source Code
> The program must include source code, and must allow distribution
> in source code as well as compiled form. Where some form of a
> product is not distributed with source code, there must be a
> well-publicized means of obtaining the source code for no more
> than a reasonable reproduction cost preferably, downloading via
> the Internet without charge. The source code must be the preferred
> form in which a programmer would modify the program. Deliberately
> obfuscated source code is not allowed. Intermediate forms such as
> the output of a preprocessor or translator are not allowed." the ant case there is a "well-publicized means of obtaining the
source code" for those xerces jars.

I guess there is some amount of judgement as to what is
"well-publicized", what is "product", what is "distribution", and
obviously what is "reasonable", and I can see how the role of apache
policy would be to explain apache's judgement on the matter. Similarly
to how apache obviously (is it obvious? not sure about this now?)
chooses to have one standard "well-publicized means" of obtaining
apache source code, namely "from tarballs downloaded from or its mirrors".

So I guess by some POV there's actually a sliding scale.

I mentioned shipping a custom-ant-task.jar yesterday as something I
could imagine.

Next up, shipping ant.jar, so your users can compile without having
ant installed, seems a little worse, but all in all it's still pretty
obvious what's going on. I wouldn't be happy with it though.

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?

Figuring out which is which on the sliding scale you don't do by
evaluating how you match against a policy, you do it by by applying
the principle.

Explaining how to do _that_ is probably going to prove surprisingly hard.

> So to have anyone call this *not* a standard practice at ASF makes, to
> borrow your expression, my jaw drop. And a board member who's
> threatening to wipe out a decade worth of releases of some of the most
> popular open source projects in the world. Again, to borrow your
> expression, huh?

I imagine Roy is making a point, not making a threat. The way we used
to do this is move the files somewhere where 'normal' downstream
users/developers wouldn't download them (like I
think that can be a pretty healthy way to force action/change. At
least, I imagine Roy doesn't mean to erase anything from archive.a.o!

> As said earlier, I'm fine if people want to clarify our policies
> regarding this and revise current practice. But let's please have a
> proper debate about the merits of the alternatives and give affected
> projects proper time to adjust in case changes are required.

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?



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

View raw message