On Mar 10, 2008, at 12:43 PM, Henri Yandell wrote:
> On Mon, Mar 10, 2008 at 11:44 AM, David Jencks
> <david_jencks@yahoo.com> wrote:
>
>> Here's what it does:
>> By default, the LICENSE file is the standard apache license. The
>> NOTICE
>> file is generated from a velocity template; here's an example of
>> the output
>> (between ----- lines which are not included)
>> ------------------------------------------------------
>> Geronimo :: Directory Plugin
>> Copyright 2003-2008 Apache Software Foundation
>> This product includes software developed at
>> Apache Software Foundation (http://www.apache.org/).
>> ------------------------------------------------------
>>
>> In the 99% of the time when this is the correct LICENSE and
>> NOTICE, that's
>> all you do. In the remaining 1% of the time where additional
>> information is
>> needed appended to these standard files, you put the additions in
>> src/main/appended-resources/LICENSE
>> and
>> src/main/appended-resources/NOTICE
>>
>> In the remaining 0.1% of the time where the standard files are not
>> correct
>> you can arrange by other means to insert custom LICENSE and NOTICE
>> files.
>
> Looks good to me.
>
> Two thoughts:
>
> 1) How is the end-year of the copyright done? AIUI, that should be the
> year of last edit and not the year in which it is built. So if I build
> something that hasn't been touched in a year, it should still have
> last year's year on it.
I think it is the current year. I could argue that this is only
relevant for releases, at which time the version in the pom has
changed, and the pom is included in the artifacts, therefore
something has changed, but that argument is a bit weak. Personally I
think having a copyright date range from project inception to now is
better than having definitely out-of-date NOTICE files included in
most or all artifacts, which is positively assured if this process is
done by hand.
Is this a blocker?
>
> 2) Add a macro language for the license/notice so it can pull things
> in from the transitives when added in. It should also fail when it
> can't find said license information. At least for the LICENSE part as
> that applies to all licenses etc. I'm not sure we have NOTICEs in the
> Maven repository.
I thought the whole point of the discussion up to now on what goes in
LICENSE and NOTICE files is that they definitely apply to ONLY what
is actually IN the artifact and not any of its dependencies or what
might be required to actually use the artifact in any meaningful
way. Given that I said that rolling up LICENSE and NOTICE files for
artifacts that assemble and contain other artifacts such as wars and
ears is out of scope for this proposal, I'm very confused about what
you might be suggesting. Could you please clarify how this macro
language would apply to this proposal?
I'd really prefer to discuss the actual possibility of using exactly
what I am proposing in this thread on legal-discuss and discuss
possible enhancements and improvements elsewhere. There is a
gigantic tendency on legal discuss to have infinitely long
discussions with no conclusion, but I would like to know if there are
actual problems with using this actual resource bundle right now in
projects I would like to release this week.
Could we restrict all discussion of possible future enhancements to
the maven-dev list?
many thanks
david jencks
>
> Hen
>
> ---------------------------------------------------------------------
> DISCLAIMER: Discussions on this list are informational and educational
> only. Statements made on this list are not privileged, do not
> constitute legal advice, and do not necessarily reflect the opinions
> and policies of the ASF. See <http://www.apache.org/licenses/> for
> official ASF policies and documents.
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
> For additional commands, e-mail: legal-discuss-help@apache.org
>
---------------------------------------------------------------------
DISCLAIMER: Discussions on this list are informational and educational
only. Statements made on this list are not privileged, do not
constitute legal advice, and do not necessarily reflect the opinions
and policies of the ASF. See <http://www.apache.org/licenses/> for
official ASF policies and documents.
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
|