gump-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <>
Subject Re: legalities of jar publishing
Date Tue, 13 Jul 2004 20:25:50 GMT
Adam R. B. Jack wrote:

> Stefano wrote:
>>NOTE: board hat off.
> Noted.

NOTE: board hat continously off unless explicitly stated. (I do this 
because I use the same email address for all apache communication and 
that might create problems understanding which hat I'm wearing)

apologies if this seems like splitting hair, but I've been flamed in the 
past for having mis-contextualized my comments so I'm overly cautious ;-)

> BTW: I've been quiet on this 'til now 'cos it is now that I need to get past
> this (if possible) again, so I can extend functionality.


>>If a nightly build is a release, then it is a svn|cvs checkout and if
>>you want the PMC to approve any checkout, we clearly kill our ability to
> 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.

> Note: I am not trying to split hairs, I am trying to understand "the line".

No problem.

>>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.
> 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'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 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.

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.

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 

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 

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).

>>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
> 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.

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.


View raw message