harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Geir Magnusson Jr <g...@pobox.com>
Subject Re: [legal] taking concurrency utils code into the project (Re: svn commit: r421111 [1/11] - in /incubator/harmony/enhanced/classlib/trunk/sandbox: ./ juc-proposal/ juc-proposal/concurrent/ juc-proposal/concurrent/.settings/ juc-proposal/concurrent/META-INF/ juc-proposal/concurrent/src/ juc-proposal/concurrent/src)
Date Mon, 17 Jul 2006 00:49:58 GMT

Geir Magnusson Jr wrote:
> Tim Ellison wrote:
>> Magnusson, Geir wrote:


>>> 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.

I want to make something explicitly clear to everyone (IOW, this isn't
asking for a response from Tim...) :

In no way do I believe that anything* this project has accepted from IBM
or any other contributor has been created under conditions that are not
clean room, fully acceptable to the project, or in any way put this
project or it's users in any risk whatsoever.

My point is - which I appear to have stated in a way that is
unfortunately both unclear and too strong, thus further confusing the
message - that the process that we have created is a set of guidelines
for both contributors as well as  us, and we always have the freedom to
adapt to exceptional or unusual circumstances, and I support doing that
as long as we always keep with the intent of the project cleanroom
goals, and understand and make intelligent decisions about risk along
the way.


* Ok, there was that issue with the two files in JCHEVM, but that's been
resolved to everyone satisfaction

Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org

View raw message