The legal risk involved in downloading and using a jar of code pushed to central under false pretenses is very small. 'Using', as opposed to 'incorporating in your release.'
The appassembler is a weird case. You don't see the JSW as a dependency, exactly, yet you end up with a copy in your distribution. I think that I opened a JIRA on the appassembler a long time ago suggesting that it would be polite for the site documentation to be very explicit as to the license of the materials it stirs into the pot. People who have corporate reasons to be super-careful already have their own mechanism for vetting everything. Normal people really don't have to, so I for one am not very enthusiastic about adding complexity to address it. On Mon, Jun 13, 2011 at 9:55 AM, Robert Burrell Donkin <robertburrelldon...@gmail.com> wrote: > On Mon, Jun 13, 2011 at 1:03 AM, Brett Porter <br...@apache.org> wrote: > > <snip> > >> None of this discussion is really relevant for this list... except maybe >> that pointing to a URL for a license in the POM is not a good idea. > > This is really what I wanted to raise here (just a bit difficult > without context) > >> If someone wants to take up that issue, I would recommend changing it to a >> reference within the repository, so that we can ensure some list of >> immutable licenses. > > I think a limited list of standard licenses would be useful, allowing > automated verification of license policies (for example). > > A key question is whether these license URLs are intended to act as > immutable names or as links to where a license might be agreed with a > vendor. > > AIUI as a user of Maven ATM I have very little control over the > downloads. This means Maven may end up helping me break criminal law > by facilitating the downloading artifacts for which I have no license. > Perhaps a white list of allowed licenses in the configuration would > allow a user to choose the risks they were willing to take. > > Robert > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org