harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tim Ellison <t.p.elli...@gmail.com>
Subject [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 09:03:10 GMT
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.

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

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

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.

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

Regards,
Tim

> I'm typing this from a fone on a train. I'll start a new thread 
> regarding other aspects using a real kbd as my thumbs are tired...
> 
> Geir
> 
>  -----Original Message-----
> From: 	Tim Ellison [mailto:t.p.ellison@gmail.com]
> Sent:	Wednesday, July 12, 2006 07:08 AM Pacific Standard Time
> To:	harmony-dev@incubator.apache.org
> Subject:	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/...
> 
> My objection to committing the concurrency code to our SVN is not on a
> technical basis.  My objection is based on the Harmony contributor process.
> 
> The commit was not made by an original author in the day to day
> development of the code, it is bringing in code from elsewhere and
> making it part of the Harmony project.  As such we need to have suitable
> Authorized Contributor Questionnaires from the authors and/or the Bulk
> Contribution Questionnaire from the owners.
> 
> I understand that the code has been released into the public domain by
> the authors, and 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 can we go and get
> ACQs from the authors to show that is the case, and file them alongside
> the other ACQs that we have for the Harmony code?
> 
> Similarly, if we then intend to take regular updates from the JSR166
> repository we should have some indication that the authors' ongoing
> contributions to that work are understood to be public domain.
> 
> Given the very public history of the concurrency project I'm quite happy
> that this openness is understood and intentional by contributors to that
> JSR and their employers, so I'm assuming that it won't be difficult to
> get such assurances.
> 
> Regards,
> Tim
> 
> Geir Magnusson Jr wrote:
>> To be clearer, I needed an "if" between "technical grounds" and "you
>> don't..."
>>
>> Also, we can keep things out of sandbox if the code violates someones
>> copyright, or is under an inappropriate license for us to have in SVN,
>> or some other legal problem for the project or ASF (like code that
>> implements a patent) but I don't think that's the case here.
>>
>> geir
>>
>>
>> Geir Magnusson Jr wrote:
>>> You can't veto something in the sandbox.
>>>
>>> You can veto on technical grounds you don't want it in the mainline.
>>>
>>> geir
>>>
>>>
>>> Tim Ellison wrote:
>>>> -1 for this commit.
>>>>
>>>> I'll discuss over on the concurrent utils thread:
>>>> http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200607.mbox/%3c005401c6a56e$79234ce0$0c01a8c0@LITTLEGUY%3e
>>>>
>>>> Regards,
>>>> Tim
>>>>

-- 

Tim Ellison (t.p.ellison@gmail.com)
IBM Java technology centre, UK.

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