Luc Maisonobe wrote: > Le 08/06/2010 23:07, Bill Rossi a écrit : >> Luc, >> >> I'm OK with providing an ICLA or SGA or both. A bit of history on the >> project to help you decide what is appropriate: >> >> While working for my employer some last year we noticed some of these >> functions were slow. I quickly wrote a couple of faster replacements. >> >> Seperately I decided to take the idea and see how far I could push it. >> On my own time I developed an new implementaion that had all the >> characteristics I described earlier. >> >> Although it seemed unlikely that my employer would try claim ownership >> of software that I didn't write for them, I have asked for and obtained >> a written declaration from them saying they have no claim on it. > > Then I would ask you if you could provide a Software Grant Agreement, > signed by yourself. > >> It was an interesting project and I'm just tring to solve this problem >> so others won't have to deal with it again. I'm happy to help maintain >> it, but I do have a limited amount of time available for that. > > We all have limited time, so we would be happy with someone like you > helping us.
+1 - welcome, Bill! > >> As for the size of the project, the software itself is 2690 lines. The >> test cases and tools used to create the software add an additional 2430 >> lines. The project was started in Oct 2009, so not quite a year yet. > > Whoa. It is a huge project! We definitely need a SGA for such a beast. > > So the next step would be as James advised: open a JIRA issue explaining > your proposal and including a link to this thread > (<http://markmail.org/message/zyeoguw6gwtofm62>) and attach an archive > with the code on it so we can review it. You should also send both an > SGA and an ICLA to the foundation (these are legal papers, so a physical > copy -fax or paper mail- is needed rather than an e-mail). > > We will discuss on this list about your proposal to decide if we can > include it or not, with or without changes. > > Please keep in mind that we too have limited time, so we may take some > time to review and discuss this. As an example, I already have to review > a proposal made by another committer (Gilles), and failed to do it up to > now (I'm sorry for that and will try to do it soon). I will also have a look, but it may take me a while as I am similarly backed up. One point Luc made above is worth repeating. What we really value most is *volunteers* to join us and contribute to our community. Good code can help grow the community, but good code with no community support always ends up draining energy. So my question to the community at large is, is this codebase something you are interested in using, working on and supporting? It would be great to have at least a handful of people interested in working in this new area for [math]. Ted also made a good point on suitability for inclusion in the JDK. Things developed @apache have been incorporated in the Java language in the past, so this is a natural thing for us to do; but it does raise the question why has this not already been considered or done in the JDK (or for that matter in the native libraries that the JDK uses)? I have not dug into the code yet or thought through the consequences or numerical foundations of the approach, but it would be good to talk about these things as we evaluate the code. We may find that the numerical approach is suitable for other areas of [math] as well. Thanks again, Bill, for your interest in contributing to [math] and welcome to Commons! Phil > > Luc > >> I also previously tried to interest the people at the jQuantLib project >> (http://www.jquantlib.org), but they don't seem very interested. >> >> Bill >> >> On Tue, 8 Jun 2010, Luc Maisonobe wrote: >> >>> Le 08/06/2010 21:16, James Carman a écrit : >>>> On Tue, Jun 8, 2010 at 3:14 PM, Luc Maisonobe <luc.maison...@free.fr> >>>> wrote: >>>>> I would say it depends both on the size of the contribution and the >>>>> fact >>>>> it is completely new or a patch on existing code. The examples I >>>>> know of >>>>> are the mantissa library I contributed in 2006, the simplex solver Ben >>>>> contributed last year and the microsphere interpolation Gilles >>>>> contributed last year too. In these 3 cases, the size was of the order >>>>> of magnitude of 100s or 1000s of lines and it was for new features. We >>>>> asked for a software grant in all cases. >>>>> >>>> We asked for the grant because it was required or just as a precaution? >>> It was required for at least the two first cases. Concerning Mantissa, >>> it was an existing product I wrote and published under the terms of the >>> modified BSD license, so it was a large set of code and there was a >>> license change. Concerning the simplex solver, it was developed by Ben >>> inside Google so we needed some signed form by a Google exec. I asked on >>> the legal list for this case and they considered the software grant was >>> really needed. >>> >>> Considering microsphere, I checked further: we didn't ask for a software >>> Grant but rather for an ICLA from Gilles, because he developed it >>> explicitely for inclusion in commons-math. >>> >>> I think formally a Software Grant would be needed for all things >>> imported from outside without having been developed explicitely for the >>> foundation. The page on the foundation site reads: >>> >>> When an individual or corporation decides to donate a body of >>> existing software or documentation to one of the Apache projects, >>> they need to execute a formal Software Grant Agreement (SGA) with the >>> ASF. Typically, this is done after negotiating approval with the ASF >>> Incubator or one of the PMCs, since the ASF will not accept software >>> unless there is a viable community available to support a >>> collaborative project. >>> >>> As I understand Bill's first message about FastMath, he developed it >>> over one year and wants to contribute it afterwards, so we need a >>> Software Grant. Of course it would be even better if at the same time he >>> would provide an ICLA to be able to maintain it as part of Apache >>> commons-math. >>> >>> Luc >>> >>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >>>> For additional commands, e-mail: dev-h...@commons.apache.org >>>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >>> For additional commands, e-mail: dev-h...@commons.apache.org >>> >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >> For additional commands, e-mail: dev-h...@commons.apache.org > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
