commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dennis Lundberg <denn...@apache.org>
Subject Re: [IO] Planning IO 1.4 release
Date Thu, 10 Jan 2008 20:11:40 GMT
sebb wrote:
> On 10/01/2008, Niall Pemberton <niall.pemberton@gmail.com> wrote:
>> On Jan 10, 2008 4:32 PM, sebb <sebbaz@gmail.com> wrote:
>>> On 10/01/2008, Stephen Colebourne <scolebourne@btopenworld.com> wrote:
>>>> ---- Original Message ----
>>>> From: Jochen Wiedmann <jochen.wiedmann@gmail.com>
>>>>> On 10/01/2008, Stephen Colebourne <scolebourne@btopenworld.com>
>>>>  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.
>>> My position is that no matter how good the plugin is, the NOTICE file
>>> needs to be generated manually in order to ensure proper oversight. It
>>> seems to me that it should be possible to review the NOTICE file for
>>> compliance without having to generate it.
>> Oversight is the PMC reviewing and voting on the release artifacts and
>> checking the LICENSE and NOTICE files - even if theres a good
>> hand-written copy in svn it makes no difference since its what we put
>> out in our distros.
> 
> OK, point taken.
> 
>> Additionally hand written ones can be just as bad
>> or worse. If a component has the "standard" flavour that most of our
>> components have why does that make you feel confident? For all you
>> know someones just copied another and has given no thought to what it
>> should contain. At least with the generated one it tries to name all
>> dependencies, the author and license - if that doesn't work well then
>> putting in a custom "hand written" one takes precedence over the
>> generated one. So it seems to me this plugin is better IF the
>> dependencies information is up to date.
> 
> AIUI, the NOTICE file is not about dependencies, it is about the
> artefacts that are actually included in the distribution.
> 
> In the case of Commons, dependencies are normally not included in the
> distribution, and should therefore not be included in NOTICE.

Now I better understand why you feel the way you do about this.

The approach that mrrp takes is to inform about software that is either 
included *or* used by the current project. So it behaves differently 
than you expect it to. I don't have much insight into the legal stuff 
surrounding these files, but mrrp is used by lots of ASF project. So I 
suspect that the generated NOTICE files comply with ASF policy.

> Indeed, I suspect that most (possibly all) Commons distributions need
> the same NOTICE file - the only difference being the initial copyright
> year.
> 
> Or have I missed something here?
> 
>> Niall
>>
>>>> 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.
>>>>
>>>> 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: dev-unsubscribe@commons.apache.org
>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>
>>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>
>>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
> 
> 


-- 
Dennis Lundberg

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message