Re: legalities of jar publishing
Seems a key point to me. So can we say that these artifacts are NOT considered release? I would say so, yes. Gump creates artifacts that should *NOT* be considered released and officially endorsed by the ASF, any use of those artifacts, if made available, should come with a big WARNING label that should discouradge people from using them in any requirements where trust is an issue. I think this is what I need, but I'll continue below. Interesting. Yes, I see that. Hmm, say one creates a bogus jars that (perhaps) overrides or subverts some Ant task, and hence local (by user) builds of tomcat now have such back door. Surely ASF isn't liable there, and surely CVS|SVN isn't something to shut off (allowing only releases we sign). Hmm, also, what is a committer is tricked into submitting a bogus jar into CVS, so home done builds are again not trustworthy. Surely we are primarily responsible for things we label as releases. I'm sorry, I'm not sure I follow you here 100%, could you please elaborate more. This is a critical issue and I don't want to misunderstand you. I was merely trying to build upon your argument, stating that we can only really trust what we build, and we approve/release, and that Gump was just (in Leo's words) an automated developer. My argument was merely that we can't trust what users build, and Gump is just an automated user. I'm not trying to stretch, but I'm asking -- if we are 100% clear that these are untrustworthy, and NOT releases, could we do this? [See why below] Releasing executable artifacts by gump will have my permanent -1 *FOREVER*. The way gump works is intrinsically unsafe, but this is not a problem if what gump is producing is metadata about code, not executable code directly. Yes, that is true. So, are these releases? what releases? I'm sorry, I can't contextualize what you're saying :-/ I have my answer -- they are NOT releases, they are however (unfortunately ... executable) artifacts. I have a serious problem if we can't do this. I wish to deploy cascaded Gumps, Gumps that download the 'latest Gumped jar' from other Gumps. The purpose of these jars is almost metadata, it is a compile/run interface so the downstream Gumps do not have to replicate cycle can focus on their own work. If we can't allow these artifacts to be downloaded (even by other Gumps) we can scale nicely like this. As I said, I have no problem in *making artifacts available* for download as long as they have WARNING signs all over the place. Ok, good. NOTE: again, this is just my personal opinion, the board will have the final say on this matter and I don't know their opinion on this since it was never discussed. How would you suggest that I raise the issue? I don't want to be opening a hole, so am glad to go along w/ ASF's decision. So, as long as those jars are available, you can let other gumps download them. This is a perfect example of a need for such jars that is just used as a preparatory artifact for the generation of some other metadata. As long as these jars are not officially supported, branded, signed and released by the foundation, I see no problem in allowing them to be made available. Perfect. What I have a problem in using gump as an automatic build system that will generate jars that will be released officially by the foundation. That, IMO, will never be acceptable, unless gump stops building projects that the foundation doesn't control (which would be a severe limitation of gump functionalities). Agreed. As for making gump both a nightly build and a continuous integration system, I think projects should be allowed to specify their preferred checkout tag of any dependency, that would allow gump to be *way* more useful. I could look at this w/ a repository of built releases. Things would scale a lot better if I could download those previously built. :-) [That said, we can do that from a repo of releases.] Very much agreed. Ok, I will look at this as part of Gump/Depot repository work. I would like to hear comments from others and when we reach consensus I can run this thru the board and see what they think. Ok, this is the process I asked about above. I'll wait and see what others say then leave it to you. Thanks for your help. regards, Adam - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: legalities of jar publishing
Sebastian Bazley wrote: I agree with Leo that the problem of jar distribution is absolutely not technical, it's legal and security. Gump executes code downloaded from repositories that the ASF doesn't consider legally trustful. say I was the author of a weird library that some weird commons code depended on, it is entirely possible to write a task in a build.xml file that recompiles a class in tomcat and opens a back door, it might take a while to notice. One of the Gump Wiki pages - http://wiki.apache.org/gump/BrutusConfig/RequestANightlyBuild - states You can set up your own nightly builds in your shell account on minotaur. Is the output from such builds publishable? that is at the discretion of the relevant governing PMC. Like also detailed on the wiki, I'm figuring out how to set this up on brutus (without having to create 200 accounts). Infrastructure will /not/ be pleased if dozens of people start doing this. Especially not for code that has tests that opens up ports, looks for X, etc etc etc. In fact, I'm going to remove that notice now :-D The builds need not automatically fetch software from anywhere but the Apache CVS, which means that the backdoor scenario above should not happen. well, that's still a bit of a risk. If someone's account is hacked, a backdoor is introduced, and is fixed 24 hours later, there'll be a nightly build containing the backdoor. Etc etc. Learn to be paranoid. - LSD - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: legalities of jar publishing (was: Re: [VOTE] retire java gump)
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]
Re: legalities of jar publishing
One of the questions that haven't really been answered/resolved by the board (IIRC) is whether automated snapshots are considered releases. If so, you can forget the whole business of nightly builds being distributed from ASF hardware - no matter whether they've been built by Gump or any other mechanism - since even those nightly builds would require active PMC approval. Each nightly build. On Mon, 21 Jun 2004, Leo Simons [EMAIL PROTECTED] wrote: 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. I agree. Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: legalities of jar publishing
On Mon, 21 Jun 2004, Martin van den Bemt [EMAIL PROTECTED] wrote: 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, That's you. Ant used Gump to create nightly builds until Sam's machine broke down. So did Cactus and JMeter. Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: legalities of jar publishing
As does commons: http://cvs.apache.org/builds/jakarta-commons/nightly/ S. -Original Message- From: Stefan Bodewig [mailto:[EMAIL PROTECTED] Sent: 21 June 2004 12:32 To: [EMAIL PROTECTED] Subject: Re: legalities of jar publishing On Mon, 21 Jun 2004, Martin van den Bemt [EMAIL PROTECTED] wrote: 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, That's you. Ant used Gump to create nightly builds until Sam's machine broke down. So did Cactus and JMeter. Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] ___ This e-mail and the documents attached are confidential and intended solely for the addressee; it may also be privileged. If you receive this e-mail in error, please notify the sender immediately and destroy it. As its integrity cannot be secured on the Internet, the Atos Origin group liability cannot be triggered for the message content. Although the sender endeavours to maintain a computer virus-free network, the sender does not warrant that this transmission is virus-free and will not be liable for any damages resulting from any virus transmitted. ___ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: legalities of jar publishing
Commons nightlies uses the dependencies specified by the developers. (unless the script changed) Mvgr, Martin On Mon, 2004-06-21 at 13:46, BAZLEY, Sebastian wrote: As does commons: http://cvs.apache.org/builds/jakarta-commons/nightly/ S. -Original Message- From: Stefan Bodewig [mailto:[EMAIL PROTECTED] Sent: 21 June 2004 12:32 To: [EMAIL PROTECTED] Subject: Re: legalities of jar publishing On Mon, 21 Jun 2004, Martin van den Bemt [EMAIL PROTECTED] wrote: 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, That's you. Ant used Gump to create nightly builds until Sam's machine broke down. So did Cactus and JMeter. Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] ___ This e-mail and the documents attached are confidential and intended solely for the addressee; it may also be privileged. If you receive this e-mail in error, please notify the sender immediately and destroy it. As its integrity cannot be secured on the Internet, the Atos Origin group liability cannot be triggered for the message content. Although the sender endeavours to maintain a computer virus-free network, the sender does not warrant that this transmission is virus-free and will not be liable for any damages resulting from any virus transmitted. ___ - 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]
Re: legalities of jar publishing
One of the questions that haven't really been answered/resolved by the board (IIRC) is whether automated snapshots are considered releases. This is really a big deal (for me probably others). If so, you can forget the whole business of nightly builds being distributed from ASF hardware - no matter whether they've been built by Gump or any other mechanism - since even those nightly builds would require active PMC approval. Each nightly build. Yup. That would be a lot of impact on developers/development. I sure hope not! But, I guess we need to bite the bullet and initiate a conversation (somewhere general, or with the board) on this matter. If we made it clear (in the jar name, in the manifest?) that these were nightly builds and not releases, I'd sure hope we could redistribute. On Mon, 21 Jun 2004, Leo Simons [EMAIL PROTECTED] wrote: 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. I agree. Oops, I missed this, I see you know. I assume it is being (and ought be) sat upon until we resolve the legality. regards, Adam - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
