maven-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Benson Margulies <>
Subject Re: [REDUX] Java Service Wrappers (JSW) unfortunate license change
Date Mon, 13 Jun 2011 14:09:22 GMT
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

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
<> wrote:
> On Mon, Jun 13, 2011 at 1:03 AM, Brett Porter <> 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:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message