You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lucy.apache.org by Marvin Humphrey <ma...@rectangular.com> on 2010/09/07 19:16:51 UTC
[lucy-dev] Grant plan
Greets,
We need to work out a formal plan for the code import. Primary guidance is
located here:
http://incubator.apache.org/guides/mentor.html#initial-ip-clearance
I asked about examples we might reference on general@incubator.a.o a few days
ago, but nobody replied (<http://markmail.org/message/xbs24zrhrio76lgl>), so
we'll just have to follow the instructions as best we can.
I have assembled a list of individuals who have made significant contributions
to KinoSearch and thus must participate in the software grant. All of them
have been contacted privately and expressed their preliminary approval.
I have also been accumulating a list of people who have made small
contributions, which while welcome, may not be significant for the purposes of
the grant. For these individuals, I think we should have them write to
lucy-dev indicating whether they agree with that assessment and whether they
think they need to participate formally. This is what I see that mod_fcgid
did:
http://incubator.apache.org/ip-clearance/httpd-mod_fcgid.html
There are also people in the KinoSearch svn logs who are credited for having
identified bugs or provided ideas, but who did not supply patches or whose
patches were not incorporated into the code base. I don't think we need to
contact these individuals, but we should clarify the status of these commit
messages.
To track all of these issues, I think we should open a JIRA issue entitled
"Software Grant Participants".
Another task that needs to be completed before the code drop is the excising
of materials which cannot be relicensed. For example, the standalone utility
script trunk/devel/bin/dump_index was adapted by Brian Phillips from an
original which was published in the Plucene distribution; it will simply not
be included in the grant.
Lastly, all references to the current GPL/Artistic licensing need to be
excised. My current thought is to remove the licensing information but leave
the copyright notices with my name in place as sort of a "todo" tag.
The result of this process will be a clean tarball that can be unpacked and
committed to an "import" directory in one fell swoop. Then we can proceed by
through the codebase file by file, removing my copyright, moving other
copyright and license notifications to LICENCE and NOTICE, and adding the ASF
headers.
http://www.apache.org/legal/src-headers.html
I am currently reviewing the KinoSearch commit history commit by commit
looking for IP issues and assembling an authoritative list of contributors.
This is laborious, but it is important work; the audit has yielded one
additional name for the software grant participant list (see LUCENE-675,
<http://s.apache.org/HTJ>). I think it will take me another week or two to
complete my review. Once that's done, I'll branch and tag the KinoSearch
repository and prepare the grant tarball and checksum.
It would be nice to begin contacting our small contributors now; if one of
them decides that they need to participate in the formal grant, we need to
know that before we prepare the paperwork. For what it's worth, the
possibility exists that I will identify other contributions during the audit
that were missed during the initial scan, but I don't think we should wait, as
that would hold up the assembly of the grant paperwork (which is supposed to
include all names).
http://incubator.apache.org/ip-clearance/index.html#notes
The alternative is that each party sign its own software grant while
everyone references the same contribution (designated by a URL and an MD5
hash over the ZIP file representing the contribution). It is recommended
that the software grant form is modified in order to have a line for each
party so the completeness of the paperwork can be verified upon receipt.
I'm thinking that I should send a private mail to each of the small
contributors like the following.
Greetings [name of valued contributor],
The KinoSearch project is being assimilated by Apache Lucy
(<http://incubator.apache.org/lucy>), and we are in the midst of preparing
the formal software grant to relicense the code base to the Apache
Software Foundation. We need all significant past contributors to
KinoSearch to particpate in this grant.
So far, we have identified only the contributions below from you:
[link to JIRA comment]
While valuable to the project, the sum total of them may not be
significant for the purposes of copyright. If you agree with that
assessment, it is not necessary for you to participate in the formal
grant; however, we would like to have a public record of your agreement so
that we may use your code freely. Therefore, we would appreciate it if
you would send a message to the public mailing list lucy-dev@
with the following text:
I agree that I do not consider the sum total of the contributions at
[link to JIRA comment] significant for the purposes of the KinoSearch
software grant.
If you have any questions or concerns, please drop a line to lucy-dev@.
Thanks for your past contributions,
Marvin Humphrey
(I'll expand lucy-dev@ in the actual mails, of course.)
Sound good?
Alternatively, we could just list everyone in the grant paperwork, no matter
how small the patch. But then if it takes a while to contact someone, I'm not
sure where that leaves us.
Marvin Humphrey
Re: [lucy-dev] Grant plan
Posted by Marvin Humphrey <ma...@rectangular.com>.
On Sat, Sep 11, 2010 at 11:29:58AM +0200, Simon Willnauer wrote:
> > I have also been accumulating a list of people who have made small
> > contributions, which while welcome, may not be significant for the purposes of
> > the grant. For these individuals, I think we should have them write to
> > lucy-dev indicating whether they agree with that assessment and whether they
> > think they need to participate formally. This is what I see that mod_fcgid
> > did:
> >
> > http://incubator.apache.org/ip-clearance/httpd-mod_fcgid.html
>
> I really can tell but it seems a good way. I don't really know if
> thats practical at all but would it make sense to let those people
> sign their mails with a GPG key or something like that. I mean faking
> an email address is super easy - I don't think that this has any legal
> weight, does it?
Like I mentioned in the reply to Chris Mattmann, there aren't that many people
who fall into this category. If we just err on the side of including them in
the grant, we avoid the identity verification issue you've raised.
> > Another task that needs to be completed before the code drop is the excising
> > of materials which cannot be relicensed. For example, the standalone utility
> > script trunk/devel/bin/dump_index was adapted by Brian Phillips from an
> > original which was published in the Plucene distribution; it will simply not
> > be included in the grant.
>
> I guess that is fine though - for stuff like that we have enough
> knowledge to rewrite. Being on the safe side gets a +1 from me :)
> Is there more stuff like that which needs to be identified?
There are a few snippets of source code taken from the Perl 5 core and
subsequently hacked (this is quite common for XS modules). Reviewing the
commit history provides an extra level of audit protection.
Marvin Humphrey
Re: [lucy-dev] Grant plan
Posted by Simon Willnauer <si...@googlemail.com>.
Hey Marvin,
On Tue, Sep 7, 2010 at 7:16 PM, Marvin Humphrey <ma...@rectangular.com> wrote:
> Greets,
>
> We need to work out a formal plan for the code import. Primary guidance is
> located here:
>
> http://incubator.apache.org/guides/mentor.html#initial-ip-clearance
>
> I asked about examples we might reference on general@incubator.a.o a few days
> ago, but nobody replied (<http://markmail.org/message/xbs24zrhrio76lgl>), so
> we'll just have to follow the instructions as best we can.
I guess that our situation is very complicated from a legal point of
view and folks might rather be afraid of giving you guidance. It is
also above my head to be honest but we are on a good way to sort it
out with legal...
>
> I have assembled a list of individuals who have made significant contributions
> to KinoSearch and thus must participate in the software grant. All of them
> have been contacted privately and expressed their preliminary approval.
Awesome!
>
> I have also been accumulating a list of people who have made small
> contributions, which while welcome, may not be significant for the purposes of
> the grant. For these individuals, I think we should have them write to
> lucy-dev indicating whether they agree with that assessment and whether they
> think they need to participate formally. This is what I see that mod_fcgid
> did:
>
> http://incubator.apache.org/ip-clearance/httpd-mod_fcgid.html
I really can tell but it seems a good way. I don't really know if
thats practical at all but would it make sense to let those people
sign their mails with a GPG key or something like that. I mean faking
an email address is super easy - I don't think that this has any legal
weight, does it?
>
> There are also people in the KinoSearch svn logs who are credited for having
> identified bugs or provided ideas, but who did not supply patches or whose
> patches were not incorporated into the code base. I don't think we need to
> contact these individuals, but we should clarify the status of these commit
> messages.
>
> To track all of these issues, I think we should open a JIRA issue entitled
> "Software Grant Participants".
+1 - easier to track
>
> Another task that needs to be completed before the code drop is the excising
> of materials which cannot be relicensed. For example, the standalone utility
> script trunk/devel/bin/dump_index was adapted by Brian Phillips from an
> original which was published in the Plucene distribution; it will simply not
> be included in the grant.
I guess that is fine though - for stuff like that we have enough
knowledge to rewrite. Being on the safe side gets a +1 from me :)
Is there more stuff like that which needs to be identified?
>
> Lastly, all references to the current GPL/Artistic licensing need to be
> excised. My current thought is to remove the licensing information but leave
> the copyright notices with my name in place as sort of a "todo" tag.
Can you elaborate this a bit more, what is the reason for removing the
licensing info and leave a TODO tag? I guess I don't understand this
completely.
>
> The result of this process will be a clean tarball that can be unpacked and
> committed to an "import" directory in one fell swoop. Then we can proceed by
> through the codebase file by file, removing my copyright, moving other
> copyright and license notifications to LICENCE and NOTICE, and adding the ASF
> headers.
>
> http://www.apache.org/legal/src-headers.html
Makes sense to me. There should be a JIRA issue to and we should
really take the time and do that with patches so folks can review and
comment...
>
> I am currently reviewing the KinoSearch commit history commit by commit
> looking for IP issues and assembling an authoritative list of contributors.
> This is laborious, but it is important work; the audit has yielded one
> additional name for the software grant participant list (see LUCENE-675,
> <http://s.apache.org/HTJ>). I think it will take me another week or two to
> complete my review. Once that's done, I'll branch and tag the KinoSearch
> repository and prepare the grant tarball and checksum.
Awesome - seems like we are moving forward!
>
> It would be nice to begin contacting our small contributors now; if one of
> them decides that they need to participate in the formal grant, we need to
> know that before we prepare the paperwork. For what it's worth, the
> possibility exists that I will identify other contributions during the audit
> that were missed during the initial scan, but I don't think we should wait, as
> that would hold up the assembly of the grant paperwork (which is supposed to
> include all names).
>
> http://incubator.apache.org/ip-clearance/index.html#notes
>
> The alternative is that each party sign its own software grant while
> everyone references the same contribution (designated by a URL and an MD5
> hash over the ZIP file representing the contribution). It is recommended
> that the software grant form is modified in order to have a line for each
> party so the completeness of the paperwork can be verified upon receipt.
>
> I'm thinking that I should send a private mail to each of the small
> contributors like the following.
>
> Greetings [name of valued contributor],
>
> The KinoSearch project is being assimilated by Apache Lucy
> (<http://incubator.apache.org/lucy>), and we are in the midst of preparing
> the formal software grant to relicense the code base to the Apache
> Software Foundation. We need all significant past contributors to
> KinoSearch to particpate in this grant.
>
> So far, we have identified only the contributions below from you:
>
> [link to JIRA comment]
>
> While valuable to the project, the sum total of them may not be
> significant for the purposes of copyright. If you agree with that
> assessment, it is not necessary for you to participate in the formal
> grant; however, we would like to have a public record of your agreement so
> that we may use your code freely. Therefore, we would appreciate it if
> you would send a message to the public mailing list lucy-dev@
> with the following text:
>
> I agree that I do not consider the sum total of the contributions at
> [link to JIRA comment] significant for the purposes of the KinoSearch
> software grant.
>
> If you have any questions or concerns, please drop a line to lucy-dev@.
>
> Thanks for your past contributions,
>
> Marvin Humphrey
sounds good to me! go for it!
>
> (I'll expand lucy-dev@ in the actual mails, of course.)
>
> Sound good?
+1 from my side and thanks for all the hard work!
simon
>
> Alternatively, we could just list everyone in the grant paperwork, no matter
> how small the patch. But then if it takes a while to contact someone, I'm not
> sure where that leaves us.
>
> Marvin Humphrey
>
>
>
Re: [lucy-dev] Grant plan
Posted by "Mattmann, Chris A (388J)" <ch...@jpl.nasa.gov>.
Hi Marvin,
> For instance, there's a fellow named Edward Betts who's credited 4 times in
> the SVN logs. Edward submitted several test cases which exposed low level
> bugs. However, as hard as he worked on those test cases, they were never
> integrated into the code base, because the test cases themselves were all high
> level; the final commits typically include either a test I wrote for the
> failing lower level component or no test at all.
If you didn't integrate his patch, then what's the problem?
>
> I don't think we need to contact Edward; if he doesn't participate in the
> grant, there are no commits that need to be backed out. However, since I
> didn't clearly differentiate in the commit messages between when a patch was
> integrated into the code base (requiring participation in the grant) versus
> when someone simply reported a bug, I thought it would be worthwhile to enter
> that information into the public record.
Entering = fine.
Waiting on them to reply or confirm that you entered it = waste of time,
IMO.
>
> [...]
> Bugzilla #43835:
> Added some cool new feature.
> Submitted by: John Doe <john.doe.at.null.org>
>
> Basically, names should be listed in SVN logs if and only if there is a
> copyright interest. For moral credit, the mailing list archives suffice.
>
> (I thought I'd seen a note about that somewhere in the dev documentation, but
> I can't seem to track it down right now.)
FYI, this isn't a rule set in stone -- most of the time in SVN logs I just
say:
- fix for JIRA-ISSUE-ID <short desc>
Then, in JIRA I always make sure to resolve with:
"Patch contributed by Person X and applied in rY. Thanks Person X!"
The combination of JIRA + SVN is fine as well. In short, credit the person,
but there is not just one way to credit them.
>> OK, when you are ready let me know. I think having someone besides you do
>> the import is critical (remember: single point of failure?) :)
>
> Agreed.
>
> I believe that as a matter of formal process, the Incubator PMC has the
> binding vote on accepting the software grant. However, I think we should also
> consider holding a lazy-consensus vote of the Lucy PPMC as to whether we
> accept the grant. Nobody else on the PPMC is going to be reviewing the commit
> history like I have been, but as a collective we should be making an effort to
> follow along with the process.
Hmmm, I'm thinking overkill again. The Lucy PPMC and IPMC mentors watching
it can preside over this import and it's a good sign of community growing to
follow the SGA process, and then to evolve the resultant code base into
something that's releasable under the Incubator guidelines. We don't need a
formal vote on this. The vote will come when we try and release the
resultant downstream Apache Lucy product.
>
>> I'll throw my name into the hat to svn import it, since I worked with Joe S.
>> to get it done on OODT. Any other mentors want to do it, just let me know
>> and I'll stand down.
>
> This step is pretty much mechanical, though, right? It's just verifying the
> MD5, unpacking the tarball into an "import" directory, doing a big "svn add"
> and committing everything. In the proposal, we mention that the code source
> will be a "snapshot" from the KinoSearch repository -- we're not planning to
> import the entire SVN history.
Right, it's mechanical, all the easier for a mentor to do it since we're
busy :) If it was more than mechanical I might not have time *grin*.
+1 to pulling in a snapshot. Fine by me.
> OK, then how about we just scratch the email plan and err on the side of
> putting people into the grant if they supplied any IP that was integrated into
> the project? We're only talking about 10 people or so anyway, since most
> people who made drive-by contributions went on to make bigger ones later.
>
> If I understand correctly, if some grant participants fail to send in their
> SGA forms, we just have to reverse their contributions before we can make a
> release -- it doesn't invalidate the whole grant. However, since that
> assertion only appears in the Mentor documentation, I'm not 100% certain of
> that...
Yep, set some realistic expectations.
1. if they don't reply in a week, reverse their code out of the code drop.
2. if they do reply in a week, include them in the grant.
3. after a week, make the snapshot, get the SGA signed and work with a
mentor to submit the SGA to the Apache secretary. Then, code drop, and away
we go.
Cheers,
Chris
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Chris Mattmann, Ph.D.
Senior Computer Scientist
NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA
Office: 171-266B, Mailstop: 171-246
Email: Chris.Mattmann@jpl.nasa.gov
WWW: http://sunset.usc.edu/~mattmann/
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Adjunct Assistant Professor, Computer Science Department
University of Southern California, Los Angeles, CA 90089 USA
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Re: [lucy-dev] Grant plan
Posted by Marvin Humphrey <ma...@rectangular.com>.
On Sat, Sep 11, 2010 at 10:02:35AM -0700, Mattmann, Chris A (388J) wrote:
> > There are also people in the KinoSearch svn logs who are credited for having
> > identified bugs or provided ideas, but who did not supply patches or whose
> > patches were not incorporated into the code base. I don't think we need to
> > contact these individuals, but we should clarify the status of these commit
> > messages.
>
> To be honest -- I think that's pushing it and not necessary. We don't need
> to contact every person that's ever posted a JIRA comment or provided an
> idea.
I meant that I would document the commits in question, not that we would
contact the individuals.
For instance, there's a fellow named Edward Betts who's credited 4 times in
the SVN logs. Edward submitted several test cases which exposed low level
bugs. However, as hard as he worked on those test cases, they were never
integrated into the code base, because the test cases themselves were all high
level; the final commits typically include either a test I wrote for the
failing lower level component or no test at all.
I don't think we need to contact Edward; if he doesn't participate in the
grant, there are no commits that need to be backed out. However, since I
didn't clearly differentiate in the commit messages between when a patch was
integrated into the code base (requiring participation in the grant) versus
when someone simply reported a bug, I thought it would be worthwhile to enter
that information into the public record.
I think that in addition to Edward, there are two other people who's names are
in the SVN logs but who never had IP integrated: Andreas Koenig and Marco
Borromeo. There's also one more in a similar situation, though he's only
credited in the Changes file: Henry Combrinck. Henry and Edward in particular
have been valuable community members; that doesn't change even if there's no
requirement that they participate in the grant.
Note for fellow Lucy podling committers: it's theoretically possible to avoid
such murkiness going forward by adhering to some best practice recommendations
from the Apache developer documentation:
http://www.apache.org/dev/committers.html#applying-patches
You need to make sure that the commit message contains at least the name of
the contributor and ideally a reference to the Bugzilla or JIRA issue
where the patch was submitted. The reasons: this preserves the legal trail
and makes sure that contributors are recognized. Obviously, the latter
doesn't mean it's not a good idea to list the names of all contributors
somewhere on the website. To make it easier to "grep" for commits with
patches from contributors, always use the same pattern in the commit
message. Traditionally, we use "Submitted by: <name>" or "Obtained from:
<name>".
Here's an example of what such a commit message could look like:
Bugzilla #43835:
Added some cool new feature.
Submitted by: John Doe <john.doe.at.null.org>
Basically, names should be listed in SVN logs if and only if there is a
copyright interest. For moral credit, the mailing list archives suffice.
(I thought I'd seen a note about that somewhere in the dev documentation, but
I can't seem to track it down right now.)
> > To track all of these issues, I think we should open a JIRA issue entitled
> > "Software Grant Participants".
>
> +1, done, here [1]. I also cleaned up JIRA a bit, changing the Lucy URL to
> [2], and adding components for documentation, the website and a few other
> things so that we could classify issues better.
Sounds good, thanks.
> One thing I did was remove "Core -" in front of all of the comps -- I think
> it's pretty clear that they are core.
OK, works for me.
> > Lastly, all references to the current GPL/Artistic licensing need to be
> > excised. My current thought is to remove the licensing information but leave
> > the copyright notices with my name in place as sort of a "todo" tag.
>
> You can do an SVN import with the GPL license header in the source code and
> in the license files, it's fine. This should *not* prevent us from doing
> that. We just can't release software with these tags in them at Apache. So,
> before making an Incubation release, the tags need to be removed. My
> recommendation:
>
> 1. svn drop as is
> 2. create JIRA issue (similar to OODT-3 [3]) to fix license headers/etc.
> 3. work on JIRA issue and resolve it before releasing.
OK, sounds good. I was unclear based on those enormous threads in
legal-discuss from 2008 and 2009 about the status of Subversion as a
distribution. After going back to review them one more time, I see that we
are legally OK with GPL'd code from an imported tarball; it's just an ASF
*policy* (not a legal requirement) that everything in SVN be ASL'd...
http://markmail.org/message/jafc4uinbelqclkz (Sam Ruby)
Legally, if we follow the terms of the applicable licenses, we can
distribute artifacts that are not compatible with the Apache License,
Version 2.0.
... and the Incubator makes an exception for imports.
> > I am currently reviewing the KinoSearch commit history commit by commit
> > looking for IP issues and assembling an authoritative list of contributors.
> > This is laborious, but it is important work; the audit has yielded one
> > additional name for the software grant participant list (see LUCENE-675,
> > <http://s.apache.org/HTJ>). I think it will take me another week or two to
> > complete my review. Once that's done, I'll branch and tag the KinoSearch
> > repository and prepare the grant tarball and checksum.
>
> OK, when you are ready let me know. I think having someone besides you do
> the import is critical (remember: single point of failure?) :)
Agreed.
I believe that as a matter of formal process, the Incubator PMC has the
binding vote on accepting the software grant. However, I think we should also
consider holding a lazy-consensus vote of the Lucy PPMC as to whether we
accept the grant. Nobody else on the PPMC is going to be reviewing the commit
history like I have been, but as a collective we should be making an effort to
follow along with the process.
> I'll throw my name into the hat to svn import it, since I worked with Joe S.
> to get it done on OODT. Any other mentors want to do it, just let me know
> and I'll stand down.
This step is pretty much mechanical, though, right? It's just verifying the
MD5, unpacking the tarball into an "import" directory, doing a big "svn add"
and committing everything. In the proposal, we mention that the code source
will be a "snapshot" from the KinoSearch repository -- we're not planning to
import the entire SVN history.
> > I'm thinking that I should send a private mail to each of the small
> > contributors like the following.
> >
> > Greetings [name of valued contributor],
> >
> > [...]
>
> My honest assessment of this step: *overkill*. You know who the significant
> contributors to Lucy are, I would imagine by now. Just get them to sign the
> SGA and we're fine.
>
> I think going through the tedious process of sending these emails over the
> fence, then waiting for them to throw one back over will only continue to
> delay, and the risk of a contributor getting angry over not being part of an
> SGA when her major contribution was a comment on a JIRA issue, or an email
> RE: design sent to an ML, is little to none.
>
> OTOH, if you feel the person has contributed more than a comment or two, or
> a design email or two, then by all means, include them in the SGA.
OK, then how about we just scratch the email plan and err on the side of
putting people into the grant if they supplied any IP that was integrated into
the project? We're only talking about 10 people or so anyway, since most
people who made drive-by contributions went on to make bigger ones later.
If I understand correctly, if some grant participants fail to send in their
SGA forms, we just have to reverse their contributions before we can make a
release -- it doesn't invalidate the whole grant. However, since that
assertion only appears in the Mentor documentation, I'm not 100% certain of
that...
http://incubator.apache.org/guides/mentor.html#initial-provenance
It may take some time to track down all contributors. It is not necessary
to have paperwork on file for all contributions before the code is
imported. It may be necessary to reverse some patches and rewrite areas of
code if contributors cannot be found or at not happy about given Apache
written permission to use their code.
... and it might conflict with the docs the IP clearance page:
http://incubator.apache.org/ip-clearance/index.html#notes
It is recommended that the software grant form is modified in order to
have a line for each party so the completeness of the paperwork can be
verified upon receipt.
Hopefully all these folks can all be contacted and will get on board anyway so
we won't have to worry about reversing their contributions.
Marvin Humphrey
Re: [lucy-dev] Grant plan
Posted by Michael McCandless <lu...@mikemccandless.com>.
I'm happy to do the initial code import! It's the least I can do (I
can't keep up w/ all the threads here!)....
Mike
On Sat, Sep 11, 2010 at 1:02 PM, Mattmann, Chris A (388J)
<ch...@jpl.nasa.gov> wrote:
> Hi Marvin,
>
>> I asked about examples we might reference on general@incubator.a.o a few days
>> ago, but nobody replied (<http://markmail.org/message/xbs24zrhrio76lgl>), so
>> we'll just have to follow the instructions as best we can.
>
> +1
>
>>
>> I have assembled a list of individuals who have made significant contributions
>> to KinoSearch and thus must participate in the software grant. All of them
>> have been contacted privately and expressed their preliminary approval.
>
> Great.
>
>>
>> I have also been accumulating a list of people who have made small
>> contributions, which while welcome, may not be significant for the purposes of
>> the grant. For these individuals, I think we should have them write to
>> lucy-dev indicating whether they agree with that assessment and whether they
>> think they need to participate formally. This is what I see that mod_fcgid
>> did:
>>
>> http://incubator.apache.org/ip-clearance/httpd-mod_fcgid.html
>
> +1
>
>>
>> There are also people in the KinoSearch svn logs who are credited for having
>> identified bugs or provided ideas, but who did not supply patches or whose
>> patches were not incorporated into the code base. I don't think we need to
>> contact these individuals, but we should clarify the status of these commit
>> messages.
>
> To be honest -- I think that's pushing it and not necessary. We don't need
> to contact every person that's ever posted a JIRA comment or provided an
> idea.
>
>>
>> To track all of these issues, I think we should open a JIRA issue entitled
>> "Software Grant Participants".
>
> +1, done, here [1]. I also cleaned up JIRA a bit, changing the Lucy URL to
> [2], and adding components for documentation, the website and a few other
> things so that we could classify issues better. One thing I did was remove
> "Core -" in front of all of the comps -- I think it's pretty clear that they
> are core.
>
>>
>> Another task that needs to be completed before the code drop is the excising
>> of materials which cannot be relicensed. For example, the standalone utility
>> script trunk/devel/bin/dump_index was adapted by Brian Phillips from an
>> original which was published in the Plucene distribution; it will simply not
>> be included in the grant.
>
> Great, so let's just not include it.
>
>>
>> Lastly, all references to the current GPL/Artistic licensing need to be
>> excised. My current thought is to remove the licensing information but leave
>> the copyright notices with my name in place as sort of a "todo" tag.
>
> You can do an SVN import with the GPL license header in the source code and
> in the license files, it's fine. This should *not* prevent us from doing
> that. We just can't release software with these tags in them at Apache. So,
> before making an Incubation release, the tags need to be removed. My
> recommendation:
>
> 1. svn drop as is
> 2. create JIRA issue (similar to OODT-3 [3]) to fix license headers/etc.
> 3. work on JIRA issue and resolve it before releasing.
>
>>
>> The result of this process will be a clean tarball that can be unpacked and
>> committed to an "import" directory in one fell swoop. Then we can proceed by
>> through the codebase file by file, removing my copyright, moving other
>> copyright and license notifications to LICENCE and NOTICE, and adding the ASF
>> headers.
>>
>> http://www.apache.org/legal/src-headers.html
>
> -1.
>
> Just import as-is, or we'll never get anywhere. Like I said the license
> stuff can be done post import, with a JIRA issue.
>
>>
>> I am currently reviewing the KinoSearch commit history commit by commit
>> looking for IP issues and assembling an authoritative list of contributors.
>> This is laborious, but it is important work; the audit has yielded one
>> additional name for the software grant participant list (see LUCENE-675,
>> <http://s.apache.org/HTJ>). I think it will take me another week or two to
>> complete my review. Once that's done, I'll branch and tag the KinoSearch
>> repository and prepare the grant tarball and checksum.
>
> OK, when you are ready let me know. I think having someone besides you do
> the import is critical (remember: single point of failure?) :) I'll throw my
> name into the hat to svn import it, since I worked with Joe S. to get it
> done on OODT. Any other mentors want to do it, just let me know and I'll
> stand down.
>
>>
>> I'm thinking that I should send a private mail to each of the small
>> contributors like the following.
>>
>> Greetings [name of valued contributor],
>>
>> [...]
>
> My honest assessment of this step: *overkill*. You know who the significant
> contributors to Lucy are, I would imagine by now. Just get them to sign the
> SGA and we're fine.
>
> I think going through the tedious process of sending these emails over the
> fence, then waiting for them to throw one back over will only continue to
> delay, and the risk of a contributor getting angry over not being part of an
> SGA when her major contribution was a comment on a JIRA issue, or an email
> RE: design sent to an ML, is little to none.
>
> OTOH, if you feel the person has contributed more than a comment or two, or
> a design email or two, then by all means, include them in the SGA.
>
> Cheers,
> Chris
>
> [1] https://issues.apache.org/jira/browse/LUCY-122
> [2] http://incubator.apache.org/lucy/
> [3] http://issues.apache.org/jira/browse/OODT-3
>
>
> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> Chris Mattmann, Ph.D.
> Senior Computer Scientist
> NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA
> Office: 171-266B, Mailstop: 171-246
> Email: Chris.Mattmann@jpl.nasa.gov
> WWW: http://sunset.usc.edu/~mattmann/
> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> Adjunct Assistant Professor, Computer Science Department
> University of Southern California, Los Angeles, CA 90089 USA
> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>
>
>
Re: [lucy-dev] Grant plan
Posted by "Mattmann, Chris A (388J)" <ch...@jpl.nasa.gov>.
Hi Marvin,
> I asked about examples we might reference on general@incubator.a.o a few days
> ago, but nobody replied (<http://markmail.org/message/xbs24zrhrio76lgl>), so
> we'll just have to follow the instructions as best we can.
+1
>
> I have assembled a list of individuals who have made significant contributions
> to KinoSearch and thus must participate in the software grant. All of them
> have been contacted privately and expressed their preliminary approval.
Great.
>
> I have also been accumulating a list of people who have made small
> contributions, which while welcome, may not be significant for the purposes of
> the grant. For these individuals, I think we should have them write to
> lucy-dev indicating whether they agree with that assessment and whether they
> think they need to participate formally. This is what I see that mod_fcgid
> did:
>
> http://incubator.apache.org/ip-clearance/httpd-mod_fcgid.html
+1
>
> There are also people in the KinoSearch svn logs who are credited for having
> identified bugs or provided ideas, but who did not supply patches or whose
> patches were not incorporated into the code base. I don't think we need to
> contact these individuals, but we should clarify the status of these commit
> messages.
To be honest -- I think that's pushing it and not necessary. We don't need
to contact every person that's ever posted a JIRA comment or provided an
idea.
>
> To track all of these issues, I think we should open a JIRA issue entitled
> "Software Grant Participants".
+1, done, here [1]. I also cleaned up JIRA a bit, changing the Lucy URL to
[2], and adding components for documentation, the website and a few other
things so that we could classify issues better. One thing I did was remove
"Core -" in front of all of the comps -- I think it's pretty clear that they
are core.
>
> Another task that needs to be completed before the code drop is the excising
> of materials which cannot be relicensed. For example, the standalone utility
> script trunk/devel/bin/dump_index was adapted by Brian Phillips from an
> original which was published in the Plucene distribution; it will simply not
> be included in the grant.
Great, so let's just not include it.
>
> Lastly, all references to the current GPL/Artistic licensing need to be
> excised. My current thought is to remove the licensing information but leave
> the copyright notices with my name in place as sort of a "todo" tag.
You can do an SVN import with the GPL license header in the source code and
in the license files, it's fine. This should *not* prevent us from doing
that. We just can't release software with these tags in them at Apache. So,
before making an Incubation release, the tags need to be removed. My
recommendation:
1. svn drop as is
2. create JIRA issue (similar to OODT-3 [3]) to fix license headers/etc.
3. work on JIRA issue and resolve it before releasing.
>
> The result of this process will be a clean tarball that can be unpacked and
> committed to an "import" directory in one fell swoop. Then we can proceed by
> through the codebase file by file, removing my copyright, moving other
> copyright and license notifications to LICENCE and NOTICE, and adding the ASF
> headers.
>
> http://www.apache.org/legal/src-headers.html
-1.
Just import as-is, or we'll never get anywhere. Like I said the license
stuff can be done post import, with a JIRA issue.
>
> I am currently reviewing the KinoSearch commit history commit by commit
> looking for IP issues and assembling an authoritative list of contributors.
> This is laborious, but it is important work; the audit has yielded one
> additional name for the software grant participant list (see LUCENE-675,
> <http://s.apache.org/HTJ>). I think it will take me another week or two to
> complete my review. Once that's done, I'll branch and tag the KinoSearch
> repository and prepare the grant tarball and checksum.
OK, when you are ready let me know. I think having someone besides you do
the import is critical (remember: single point of failure?) :) I'll throw my
name into the hat to svn import it, since I worked with Joe S. to get it
done on OODT. Any other mentors want to do it, just let me know and I'll
stand down.
>
> I'm thinking that I should send a private mail to each of the small
> contributors like the following.
>
> Greetings [name of valued contributor],
>
> [...]
My honest assessment of this step: *overkill*. You know who the significant
contributors to Lucy are, I would imagine by now. Just get them to sign the
SGA and we're fine.
I think going through the tedious process of sending these emails over the
fence, then waiting for them to throw one back over will only continue to
delay, and the risk of a contributor getting angry over not being part of an
SGA when her major contribution was a comment on a JIRA issue, or an email
RE: design sent to an ML, is little to none.
OTOH, if you feel the person has contributed more than a comment or two, or
a design email or two, then by all means, include them in the SGA.
Cheers,
Chris
[1] https://issues.apache.org/jira/browse/LUCY-122
[2] http://incubator.apache.org/lucy/
[3] http://issues.apache.org/jira/browse/OODT-3
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Chris Mattmann, Ph.D.
Senior Computer Scientist
NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA
Office: 171-266B, Mailstop: 171-246
Email: Chris.Mattmann@jpl.nasa.gov
WWW: http://sunset.usc.edu/~mattmann/
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Adjunct Assistant Professor, Computer Science Department
University of Southern California, Los Angeles, CA 90089 USA
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++