You are viewing a plain text version of this content. The canonical link for it is here.
Posted to general@gump.apache.org by Leo Simons <ls...@jicarilla.org> on 2004/06/21 11:48:55 UTC
legalities of jar publishing (was: Re: [VOTE] retire java gump)
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: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org
Re: legalities of jar publishing
Posted by "Adam R. B. Jack" <aj...@trysybase.com>.
>
> Ant used Gump to create nightly builds until Sam's machine broke
> down. So did Cactus and JMeter.
>
BTW: We have a task in JIRA that will configure the HTTPD to allow access to
the Jars. They are produced, just not accessible.
regards,
Adam
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org
Re: legalities of jar publishing
Posted by Stefan Bodewig <bo...@apache.org>.
On Mon, 21 Jun 2004, Martin van den Bemt <ml...@mvdb.net> 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: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org
Re: legalities of jar publishing (was: Re: [VOTE] retire java gump)
Posted by "Adam R. B. Jack" <aj...@trysybase.com>.
> And what is the use of publishing jars that are built against the latest
> jars ?
My usage for them is for personal and/or cascaded Gumps. If the root Gumps
build the public projects then I ought be able to NOT build them for my work
Gumps. I'd like to keep current (no point Gumping, unless) so I'd want
automated downloads of the latest Gump'ed jars.
regards,
Adam
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org
Re: legalities of jar publishing (was: Re: [VOTE] retire java gump)
Posted by Martin van den Bemt <ml...@mvdb.net>.
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: general-unsubscribe@gump.apache.org
> For additional commands, e-mail: general-help@gump.apache.org
--
Mvgr,
Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org
Re: legalities of jar publishing
Posted by Leo Simons <ls...@jicarilla.org>.
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: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org
Re: legalities of jar publishing
Posted by Sebastian Bazley <se...@apache.org>.
----- Original Message -----
From: "Stefano Mazzocchi" <st...@apache.org>
To: "Gump code and data" <ge...@gump.apache.org>
Sent: Monday, June 21, 2004 8:01 PM
Subject: Re: legalities of jar publishing
> Adam R. B. Jack 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?
The builds need not automatically fetch software from anywhere but the
Apache CVS, which means that the backdoor scenario above should not happen.
S.
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org
Re: legalities of jar publishing
Posted by Leo Simons <ls...@jicarilla.org>.
Stefano Mazzocchi wrote:
> 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.
I think we are all in agreement that *if* putting in place some
disclaimers and the like makes publishing jars acceptable, we would very
much like to do it. Like many have pointed out, its valuable functionality.
- LSD
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org
Re: legalities of jar publishing
Posted by "Adam R. B. Jack" <aj...@trysybase.com>.
> > 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: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org
Re: legalities of jar publishing
Posted by Stefano Mazzocchi <st...@apache.org>.
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.
OK.
>>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
>>scale.
>
> 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
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.
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
>>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.
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.
--
Stefano.
Re: legalities of jar publishing
Posted by "Adam R. B. Jack" <aj...@trysybase.com>.
Stefano wrote:
> NOTE: board hat off.
Noted.
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
> scale.
Seems a key point to me. So can we say that these artifacts are NOT
considered release?
Note: I am not trying to split hairs, I am trying to understand "the line".
> 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 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?
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 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.]
regards
Adam
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org
Re: legalities of jar publishing
Posted by Stefano Mazzocchi <st...@apache.org>.
Adam R. B. Jack wrote:
>>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).
NOTE: board hat off.
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
scale.
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.
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.
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.
--
Stefano.
Re: legalities of jar publishing
Posted by "Adam R. B. Jack" <aj...@trysybase.com>.
> 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 <ls...@jicarilla.org> 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: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org
Re: legalities of jar publishing
Posted by Stefan Bodewig <bo...@apache.org>.
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 <ls...@jicarilla.org> 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: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org