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 <m...@leosimons.com> wrote: > > Shipping a set of CDDL jars out of some java.net 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? > Another thing I don't understand is how a configure script compiled by > autoconf from sources in configure.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. > Have you tried it? At Subversion we use the same autoconf throughout a release branch, so comparing two successive 1.6.x tarballs (expanded tarballs, which include compiled swig and and configure code) wasn't impossible. And for 1.6.0, had I wanted to, I could have run the rolling script myself to generate my own versions of the tarballs locally, and compare those. (Hmm, did you mean 'configure' just as an example? :-)) > 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. > > BR, > > Jukka Zitting > > --------------------------------------------------------------------- > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > For additional commands, e-mail: general-h...@incubator.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
