incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Emmanuel Lécharny <>
Subject Re: Binary dependencies in source releases (Was: [VOTE] Release ManifoldCF 0.5-incubating, RC0)
Date Thu, 29 Mar 2012 14:21:36 GMT
Le 3/29/12 3:41 PM, Daniel Shahaf a écrit :
> Jukka Zitting wrote on Thu, Mar 29, 2012 at 14:41:02 +0200:
>> Hi,
>> 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.
> junit is only needed for unit tests and not for the software itself; is
> this relevant to the example?
We have *many* external depencies in Directory (like antlr, xpp3, dom4j, 
openSymphony, councycastle, ...) which are stored and managed by Maven. 
When you build the project, all those jars will be pulled from the 
repository, and injected into the binary resulting from the build.

If someone pull the sources from SVN, and build the project, he will get 
the complete working binary. One more step, and he will also get the 
installers (we have one sub-project that build those installers for each 
platform we are supporting - currently windows, linux, mac OSX, and a 
standard jar -.

So far, so good.

Now, building the project is just a nightmare for our users, so we 
provide the binary installers. So are most of the Java TLP, AFAICT, and 
thos binary contains all those external jars.

My understanding is that, as far as we offer our users a way to build 
the binaries from svn, and as far as we don't have included the jars in 
SVN, we are golden. And My understanding is that this is *the release*.
OTOH, the binaries we provide, ie the installers/jars/whatever are just 
convenient deliveries that are not blessed by The ASF.

Those users who chose to pick those binaries, and expect The ASF to 
protect themselves against a trial because the project has badly 
included a binary that is not compatible with the ASL 2.0 licence, will 
not be protected by the ASL 2.0 licence.

Now, the maven repository being hosted at The ASF, the difference is, 
imho, really really thin.

Am I missing something ?

Emmanuel Lécharny

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

View raw message