commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gary Gregory <>
Subject RE: [IO] Planning IO 1.4 release
Date Thu, 10 Jan 2008 17:56:32 GMT
> -----Original Message-----
> From: Stephen Colebourne []
> Sent: Thursday, January 10, 2008 8:23 AM
> To: Jakarta Commons Developers List
> Subject: Re: [IO] Planning IO 1.4 release
> ---- Original Message ----
> From: Jochen Wiedmann <>
> > On 10/01/2008, Stephen Colebourne <>
>  wrote:
> [..]
> > > +1 to this sentiment. I completely reject the notion of generating
>  NOTICE.txt. That is our responsibility here in commons.
> > And I reject the attitude to discard a solution *once and forever*,
> > simply because there is an aspect in the *current* implementation that
> > you dislike.
> This is what I also said, and got snipped:
> "Whether this affects a particular plugin or not is of non relevance to
>  me."
> ie. I personally have no idea what the rest of the plugin does, its not of great
> interest to me. My point is specific to NOTICE.txt. To a lesser degree it also
> affects LICENSE.txt, which should also be in svn IMO.

I've not followed this thread closely until this last paragraph and one point jumped out at
me: When the license is saved in SVN, you know with absolute certainty which license legalese
is associated with any given SVN revision tree and set of files. If not, you just know from
some file headers that this set of files for a given revision is under license foo version
bar. If that is enough, legally and for SVN archeologists, then you should not need the license
file in the repos.


> Stephen
> > The value of the mrr plugin (in the light of the Apache policies) is
> > that it provides the technical solution for a non-trivial task: To
> > ensure that artifacts contain the required files. Having been the
> > person who was forced to implement a comparable solution in the past
> > for a several projects and for several artifacts separately, I am very
> > happy if someone provides a solution that does exactly that and will
> > take care for possible other artifacts in the future. The question,
> > how and from where the NOTICE.txt file is obtained is a minor problem,
> > which can easily be achieved, in the worst case by subclassing the
> > plugin. So, what's the reason to be so gruff?
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

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

View raw message