+1 from me.

On Aug 18, 2009, at 2:12 AM, ant elder wrote:

On Mon, Aug 17, 2009 at 4:55 PM, Eric Evans<eev...@rackspace.com> wrote:
On Mon, 2009-08-17 at 13:00 +0100, sebb wrote:
 Given whats being said in the "Thrift release
 legal issues" thread i think it should be ok to have the 3rd party
 licenses separate,

I disagree. It must be possible to find all the LICENSE files starting
at the initial LICENSE file. At the very least, the initial LICENSE
file should have pointers to the other license files.

the NOTICE file looks acceptable to me too.

AIUI, the NOTICE file needs to give attributions to all 3rd party code
included in the propose release.

When preparing for the 0.3.0[0] release I spent a great deal of time
trying to get all of this right. I looked at list threads for both
successful and failed podling release votes, I looked at what top- level projects were doing, and I read through what documentation I could find.
This wasn't as helpful as I'd have liked because the documents are
non-normative and the application is inconsistent, (and occasionally
contradictory). So I did the best I could.

The conclusion I came to with respect to NOTICE.txt was that it existed for purposes of attribution, and was specifically in response to section
4(d) of the Apache License. As a result, the NOTICE.txt in the
(approved )0.3.0 artifacts and the proposed 0.4.0, contains two
attribution statements, one for the Apache licensed Groovy, and one for
"software developed by The Apache Software Foundation" which should
cover everything else that is Apache licensed.

The conclusion I came to for LICENSE.txt was that it was for including
the full license text applicable to the project itself.

Both of the above conclusions seemed consistent with at least some
successful podling releases, and with some ASF top-level projects, and (to the best of my knowledge), all of the license requirements for our
third-party dependencies are being met.

However, I'd be happy to go back and correct any shortcomings and
re-roll the artifacts if that will get us the votes we need to make a
release. I just wish things were more consistent and that the process
required a little less groping around in the dark.


[0]
http://www.mail-archive.com/general@incubator.apache.org/ msg21853.html

--
Eric Evans
eev...@rackspace.com



Ok, +1 from me to release. Happy to reconsider if anyone can find an
actual link to some evidence of specific policy that says how this
release is done is not ok.

  ...ant

--
Ian Holsman
i...@holsman.net




---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Reply via email to