Tim Ellison wrote: > Magnusson, Geir wrote: >> Clearly this is a great example to use to discuss this aspect of our >> project. >> >> First, this is a not an unreasonable objection to prevent code from >> moving into classlib, but I still don't see why it can't sit in >> sandbox to help with discussion of the technical merits. We can >> resolve legal concerns in parallel. Does that work for you? > > I try to be reasonable <g>. Sure, if we can move it out of 'enhanced' > and are not building it then it can be there for looking at.
I'm not really worried about this, as it's not in any module, and it's in something called /sandbox, under a dir with "proposal" in it, on the bottom of a locked filing cabinet stuck in a disused lavatory with a sign on the door saying 'Beware of the Leopard.' I can't believe anyone would claim we're making any warranty of provenance. I don't really see the benefit, or the consistency, as we don't have any paperwork for the binaries that we also have in enhanced, and some of the source in luni et al. However, maybe the solution is to just push this (and the other binaries) out of enhanced into standard to keep enhanced pure. > >> Second, we can certainly make exceptions to the project guidelines >> for cases where we believe there are no risks to the project. In >> fact, we've done it before when we accepted the core classes from >> ibm, iirc. > > How so? The IBM core classes contribution came with a completed bulk > contribution questionnaire from the code owner detailing the authorship > and a software grant. If we can get those for the concurrent code then > I'm happy. And not every author of that has an ACQ. The point is that we've made the decision that not all code in our repository must have an ACQ. We don't have any provenance information on the binaries that we have, for example. And remember, Doug isn't making a contribution, we're discussing electing to use his code. it just has the odd property that there isn't a jar. > >> To that end, are you aware of any risks for taking this >> code, given its uniqueness and statements by its author? > > It is authors plural, right? That is my suggestion, that we get > statements from the authors as we agreed in the project guidelines. We > spent some time refining exactly what we needed to know in such a statement. It's a guideline. We can also decide, as we've done in the past, to accept code w/o statements from each author. Do you really want to reconsider that? > > As I wrote earlier, I have no reason to doubt that the authors' > employers (who may have a claim on that work) knew what they were doing > and were happy for that work to be out in public domain. So we should go > and get the doc to show that is the case. How consistent do you need to be here? If letter-of-the-law, IBM owes us a bit of paperwork, and I don't know what to do about the binaries we have lying around. I don't really want to be consistent for consistent sake, simply because we can and have made rational, calculated decisions based on our understanding of risk factors so we can move the project forward. To me, the j.u.c code is a dependency, one that has no binary distribution. Our intent is to make no modifications - we're just compiling it. I don't see how our risk changes if we just distributed the same binary made from the same code. > >> Finally, I've talked to doug, and will see if we can get at least a >> statement from him regarding authorship. > > Meaning a list of authors or the like? or a statement about the code he > wrote? Either would be a good start. He is willing to write a note to us. But I'm not interested in playing "fetch me a rock" here, and want to boil the issue down into a reusable decision. I think this is an exceptional case. To me, as of now, I'm hoping this can be a simple dependency on external code that happens to be only available in source form. It is not a contribution that we'd mingle with our source and make derivative works from. So it's like any number of things we currently depend on, for which we have no provenance information, nor until now any indication that we needed it. So I can see two solutions (each with the assumption that we'll get the note from Doug, as I'm really interested in building this bridge and working with him and this code) : 1) Put the code and build script over in /standard (as well as our other dependencies). We'll still get that note from Doug, but changing the SVN URL appears to remove all currently unknown legal risk ;) and we can get back on the technical track here. 2) I can setup a sourceforge or codehaus project with the sole purpose of creating a binary. Then we depend on that in the same way we depend on other things. geir --------------------------------------------------------------------- Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
