Mailing-List: contact commons-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Jakarta Commons Developers List" <commons-dev@jakarta.apache.org>
Received-SPF: pass (hermes.apache.org: local policy)
Message-ID: <4166DBFF.7070402@latte.harvard.edu>
Date: Fri, 08 Oct 2004 14:27:11 -0400
From: "Mark R. Diggory" <mdiggory@latte.harvard.edu>
Reply-To: mark_diggory@harvard.edu
User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913)
MIME-Version: 1.0
To: Jakarta Commons Developers List <commons-dev@jakarta.apache.org>
Subject: Re: [math] Matrix subMatrix and mean methods
References: <95F1CCA52E317C49AB7AA71B16E8988B0C2394@mail2.tsd.biz>
In-Reply-To: <95F1CCA52E317C49AB7AA71B16E8988B0C2394@mail2.tsd.biz>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit


Phil Steitz wrote:
> Mark,
>  
> We should discuss this as part of post 1.0 planning for [math].  There is a third option, which is to borrow code from Colt as we implement the kinds of pluggable numerical linear algebra implementations that we have been discussing.  Maybe that is what you mean by "fracturing."  Probably not the best way to go, but may be necessary to maintain performance + flexibility.  
>  

Actually, what I mean by "fracturing" is creating two separate complete 
versions of Colt (one Apache, one Not) occupying the same package name 
space, this would be a problem (as Wolfgang pointed out too). This would 
be bad in that both these projects, already having small development 
communities would become competitive and conflicting instead of cooperative.

I don't think that borrowing portions of implementation from Colt is 
"fracturing" as the Commons Math is already a separate project, we are 
just adding in functionality to an already existing API.

> Regarding Colt as a Jakarta subproject, or as part of a larger Jakarta or Apache Math project, that is an interesting idea.  This would probably need to go through the incubator.  
 >

I would suspect so too. But it is a relatively mature project on its own 
so incubation would probably be a short process, mainly to organize the 
development team and manage any donation/licensing sort of issues.

Wolfgang just gracefully declined to be a "developer" in such a project 
at Apache. So that effects (or doesn't) what we do decide to do now.

> Is http://dsd.lbl.gov/~hoschek/colt/index.html the right project page for the current development in Colt?  Is the mailing list referenced there active? 
>  

Yes, I am on the list currently, there is some activity.

> Phil
> 
> 	-----Original Message----- 
> 	From: Mark R. Diggory [mailto:mdiggory@apache.org] 
> 	Sent: Fri 10/8/2004 7:19 AM 
> 	To: Jakarta Commons Developers List 
> 	Cc: brian@collab.net; Wolfgang Hoschek 
> 	Subject: Re: [math] Matrix subMatrix and mean methods
> 	
> 	
> 
> 	Brain and Wolfgang,
> 	
> 	This sort of clarification is exactly what we needed to hear. It sounds
> 	like we can begin working portions of Colt now.
> 	
> 	My question to Wolfgang is, to avoid "fracturing" Colt into multiple
> 	implementations, we could decided between two possible approaches.
> 	
> 	A.) Refer to the portions of Colt we may be using by pointing to the
> 	external Colt project where ever necessary without actually placing the
> 	entire package into the Apache CVS tree.
> 	
> 	or
> 	
> 	B.) Explore the idea of Colt as an actual "Jakarta" level project and
> 	invite Wolfgang to join us as a member of that project development team.
> 	
> 	Wolfgang, what do you think?
> 	
> 	thanks,
> 	-Mark
> 	
> 	Brian Behlendorf wrote:
> 	> On Thu, 7 Oct 2004, Phil Steitz wrote:
> 	>
> 	>> Brian Behlendorf wrote:
> 	>>
> 	>>>
> 	>>> Thanks, Wolfgang.  This is a pretty easy case for us - as it sits
> 	>>> today, especially with this email note from Wolfgang (which should be
> 	>>> included in a NOTES file sitting near colt.jar when imported) it
> 	>>> looks perfectly fine to incorporate this into Apache, preserving
> 	>>> CERN's copyright notice. From a policy perspective, we should commit
> 	>>> to the repository not just the .jar file but the source code as well.
> 	>>>
> 	>>> Any patches that Apache developers need to make should be offered
> 	>>> upstream, of course, and then reincorporated into the ASF repository
> 	>>> by merging in a new version.  But if we need to locally modify the
> 	>>> work, then the copyright on the resulting derivative work would be
> 	>>> (C) Apache Software Foundation and the Apache 2.0 license, being
> 	>>> careful not to remove the original (C) CERN or license/notice.
> 	>>
> 	>>
> 	>> What if what we end up wanting to do is to incorporate code from the
> 	>> implemented algorithms into existing Apache software?  Then do we just
> 	>> need to add the CERN license / notice?
> 	>
> 	>
> 	> You should include the CERN license into the file where the code that
> 	> originated from CERN appeared, making it clear that it refers to the
> 	> code that was imported.  For example, at the top of the related file:
> 	>
> 	> /* Copyright 1999-2004 The Apache Software Foundation
> 	>  *
> 	>  * Licensed under the Apache License, Version 2.0 (the "License");
> 	>  * you may not use this file except in compliance with the License.
> 	>  * You may obtain a copy of the License at
> 	>  *
> 	>  *     http://www.apache.org/licenses/LICENSE-2.0
> 	>  *
> 	>  * Unless required by applicable law or agreed to in writing, software
> 	>  * distributed under the License is distributed on an "AS IS" BASIS,
> 	>  * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
> 	>  * See the License for the specific language governing permissions and
> 	>  * limitations under the License.
> 	>  */
> 	>
> 	> /* Portions originally Copyright CERN, under the following license:
> 	>  * [... CERN license ...]
> 	>  */
> 	>
> 	> The CVS or SVN history would be consulted if we needed to know exactly
> 	> which portions.  The above is enough to know - it gives credit where
> 	> credit is due, and nothing in that license places a requirement that the
> 	> ASF license does not also require.
> 	>
> 	>     Brian
> 	>
> 	>
> 	> ---------------------------------------------------------------------
> 	> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> 	> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
> 	>
> 	
> 	--
> 	Mark Diggory
> 	Open Source Software Developer
> 	Apache Jakarta Project
> 	http://jakarta.apache.org
> 	
> 	---------------------------------------------------------------------
> 	To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> 	For additional commands, e-mail: commons-dev-help@jakarta.apache.org
> 	
> 	
> 
> 
> 
> ------------------------------------------------------------------------
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org

-- 
Mark Diggory
Software Developer
Harvard MIT Data Center
http://www.hmdc.harvard.edu

---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org