And what is the use of publishing jars that are built against the latest jars ? They will be useless in a real environment or even test environments and will probably not get any support from the project concerning. It simply is not a nightly build against the dependencies set by the project. Gump "just" points out to a project and it's dependencies when something bad is going to happen. It is looking ahead for us, where we programmers forgot to do that Log4J was a good example of this. So besides legal issues, I would never want a nightly build made by gump for my projects to be used by others, unless gump uses the exact versions for the dependencies I defined, but that defeats gumps main goal, as far as I am concerned.
Mvgr, Martin On Mon, 2004-06-21 at 11:48, Leo Simons wrote: > Disclaimer: IANAL. > > IIRC There is no "board policy" about redistribution of materials by > gump. There is just concern, and the concern is not just with the board. > The Gump PMC is supposed to be protecting the legal interests of the ASF > wrt gump, and it is gump people who disabled jar distribution. I don't > remember any of the details, but here's a few things I do know: > > * the ASF only wants to distribute software written and owned by the > ASF > * the ASF licenses all of its software under the apache license, and > this must be true for all distributions published > * distribution of software by the ASF projects should be done by PMCs > or ASF officers, for legal protection > * the ASF has high standards about releases. We want to provide things > like MD5 files, gpg signatures, etc. Users need to trust that the > things the ASF distributes are high-quality, and for that to be true, > high quality must be consistent. > > * gump builds non-ASF-owned software under other licenses than the > apache license > * the gump pmc does not check the quality or validity of the outputs > of gump, nor take an active approach to publishing those results > * gump does not generate MD5 files, gpg signatures, etc > > From the above it should be clear that we're a bit reluctant about > publishing the jars gump produces! > > People have put in work to alleviate these concerns (the <license/> tag > is one example of that), but I'm not sure where we're at right now. > > Sure, third parties are free to use gump and publish those jars, and > they could do that using python gump. But that's not really what's > happening right now. I think the only host who still publishes jars is > covalent, and that is more like a shared hosting box that covalent loans > to the gump team than a seperate entity. So that repository is likely > going away, too. > > Python gump does generate the jar repository, and publishing it is a > rather trivial task (see http://nagoya.apache.org/jira/browse/GUMP-67). > The issue is not technical. > > > cheers, > > > - LSD > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] -- Mvgr, Martin --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
