Mark,
I am not worried about "fracturing". My understanding is that you wouldn't start doing colt releases build by apache, right? You'd rather take some parts or derivatives of the code and add them to commons-math CVS as you see fit (probably in a significantly refactored/modified form). I thought that was the overall idea, and it seems to me a good one.
If all goes well, Colt as an external library could fade into oblivion in a year or two, or whatever time it takes for math to really shape up. That's absolutely fine with me.
As far as myself as project member/committer: Thanks for the kind invitation, but I'm really busy with other things these days. However, I can be there for you in case you'd have questions about how/why things work "the way they work" in colt. To reach me, please make sure to "cc" me; commons-dev is a high volume mailing list.
I have no particular opinion on (A), it's up to you.
B) sounds confusing to me as it might indicate to users that they should use that library instead of commons-math. Why have a jakarta level project if all you want is to take some parts or derivatives of it and integrate them in "math"?
Regards, Wolfgang.
Mark, see comments inline below:
On Oct 8, 2004, at 7:19 AM, Mark R. Diggory wrote:
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: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: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?
/* 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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-- Mark Diggory Open Source Software Developer Apache Jakarta Project http://jakarta.apache.org
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
