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 Thu, 13 Jul 2006 13:21:05 GMT

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: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org


Mime
View raw message