You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Wolfgang Hoschek <wh...@lbl.gov> on 2003/11/07 02:53:46 UTC
Re: COLT and Licensing was: [math] [primitives]
Hi,
I'm the COLT maintainer and not regularly on this list, so only saw the
discussion now circumstanstially.
The latest stable release (1.1.0) is repackaged due too popular demand,
eliminates license-offending packages, does not include GPL'd code
anymore, and is available from a new location:
http://dsd.lbl.gov/~hoschek/colt/
FYI, the licenses are here:
http://dsd.lbl.gov/~hoschek/colt/dependencies.html
The LGPL corejava package is not essential for most parts of the library
and could be dropped by sacrificing some print functionality. Similar
things hold for the com.isml.math package and the concurrent lib.
CC me directly if there should me more ongoing discussion.
Wolfgang.
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: COLT and Licensing [math]
Posted by "Mark R. Diggory" <md...@latte.harvard.edu>.
A point I see, and maybe Paul can comment on this, is that RngPack seems
to start providing its functionality at the level of
public double raw();
and not lower down at
public int nextInt();
So, to use an interface based solely on "public int nextInt();" RngPack
and other packages may require some refactoring on his part to fit into it.
I personally think that the "public int nextInt();" would be the right
place to start off a generic interface because much of the other
convenience methods can be built off of it rather generically, all the
Service Providers need to supply is the functionality to produce ints.
But, it is probably true that implementing this method on some random
generators is difficult or impossible, and this may be a big concern.
Some generators may have to invert the process and as such turn the
double raw values into other primitive datatypes. That is unless I'm
mistaken about this issue.
-Mark
Wolfgang Hoschek wrote:
>
> A RandomGenerator deals in producing 32 bit integers from the uniform
> distribution, all other stuff belongs into the area of "distributions"
> and convenience classes. The most minimal interface one needs is
> something like this (proposal):
>
> /**
> * Interface for uniform pseudo-random number generators.
> */
> public interface RandomGenerator {
>
> /**
> * Returns a 32 bit uniformly distributed random number in the
> closed interval <tt>[Integer.MIN_VALUE,Integer.MAX_VALUE]</tt>
> (including <tt>Integer.MIN_VALUE</tt> and <tt>Integer.MAX_VALUE</tt>);
> */
> public int nextInt();
> }
>
>
> One might want to add a few more convenience methods, although all of
> these (and others) can be implemented in terms of the interface above:
>
> /**
> * Interface for uniform pseudo-random number generators.
> */
> public interface RandomGenerator {
>
> /**
> * Returns a 32 bit uniformly distributed random number in the open
> unit interval <code>(0.0,1.0)</code> (excluding 0.0 and 1.0).
> */
> public double raw();
>
> /**
> * Returns a 64 bit uniformly distributed random number in the open
> unit interval <code>(0.0,1.0)</code> (excluding 0.0 and 1.0).
> */
> public double nextDouble();
>
> /**
> * Returns a 32 bit uniformly distributed random number in the
> closed interval <tt>[Integer.MIN_VALUE,Integer.MAX_VALUE]</tt>
> (including <tt>Integer.MIN_VALUE</tt> and <tt>Integer.MAX_VALUE</tt>);
> */
> public int nextInt();
>
> /**
> * Returns a 64 bit uniformly distributed random number in the
> closed interval <tt>[Long.MIN_VALUE,Long.MAX_VALUE]</tt> (including
> <tt>Long.MIN_VALUE</tt> and <tt>Long.MAX_VALUE</tt>).
> */
> public long nextLong();
>
> /**
> * Returns a 32 bit uniformly distributed random number in the open
> unit interval <code>(0.0f,1.0f)</code> (excluding 0.0f and 1.0f).
> */
> public float nextFloat();
> }
>
>
> If Paul agrees, perhaps we can all settle on such an interface (or
> similar). Further, RngPack with BSD license could get back into colt again.
>
> Wolfgang.
>
--
Mark Diggory
Software Developer
Harvard MIT Data Center
http://osprey.hmdc.harvard.edu
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: COLT and Licensing [math]
Posted by Wolfgang Hoschek <wh...@lbl.gov>.
>
> I think I exagerated a bit with the use of term "consortium". I'm mostly
> just refering to something like the java.security.SecureRandom SPI
> (practically Identical but specifically not for encryption grade RNG).
> This way, if you write an application that uses (lets call it
> RandomFactory), and there are service providers for a bunch of different
> Random Number generators out there, then you don't need to "rewrite"
> your code to test it performance/correlation on different generators.
A RandomGenerator deals in producing 32 bit integers from the uniform
distribution, all other stuff belongs into the area of "distributions"
and convenience classes. The most minimal interface one needs is
something like this (proposal):
/**
* Interface for uniform pseudo-random number generators.
*/
public interface RandomGenerator {
/**
* Returns a 32 bit uniformly distributed random number in the closed
interval <tt>[Integer.MIN_VALUE,Integer.MAX_VALUE]</tt> (including
<tt>Integer.MIN_VALUE</tt> and <tt>Integer.MAX_VALUE</tt>);
*/
public int nextInt();
}
One might want to add a few more convenience methods, although all of
these (and others) can be implemented in terms of the interface above:
/**
* Interface for uniform pseudo-random number generators.
*/
public interface RandomGenerator {
/**
* Returns a 32 bit uniformly distributed random number in the open
unit interval <code>(0.0,1.0)</code> (excluding 0.0 and 1.0).
*/
public double raw();
/**
* Returns a 64 bit uniformly distributed random number in the open
unit interval <code>(0.0,1.0)</code> (excluding 0.0 and 1.0).
*/
public double nextDouble();
/**
* Returns a 32 bit uniformly distributed random number in the closed
interval <tt>[Integer.MIN_VALUE,Integer.MAX_VALUE]</tt> (including
<tt>Integer.MIN_VALUE</tt> and <tt>Integer.MAX_VALUE</tt>);
*/
public int nextInt();
/**
* Returns a 64 bit uniformly distributed random number in the closed
interval <tt>[Long.MIN_VALUE,Long.MAX_VALUE]</tt> (including
<tt>Long.MIN_VALUE</tt> and <tt>Long.MAX_VALUE</tt>).
*/
public long nextLong();
/**
* Returns a 32 bit uniformly distributed random number in the open
unit interval <code>(0.0f,1.0f)</code> (excluding 0.0f and 1.0f).
*/
public float nextFloat();
}
If Paul agrees, perhaps we can all settle on such an interface (or
similar). Further, RngPack with BSD license could get back into colt again.
Wolfgang.
>
>
>>>
>>> Also, can you possibly comment on your position and or interest
>>> concerning the possible inclusion of some parts of your codebase into
>>> Jakarta Commons Math in the possible future? That is, if our ASF
>>> licensing permits.
>>
>>
>>
>> Overall, I've moved on to other areas (P2P databases). So these days,
>> I'm maintaining colt on a very minimal time budget, and if someone
>> else (like jakarta-commons) picks up the theme, it would be very good
>> and welcome.
>
>
> Interestingly, I'm becoming involved with some efforts here at Harvard
> to implement what we're calling the "Crimson Grid Initiative". I may be
> reviewing your software (Firefish and Spitfire) in the near future :-)
>
>>
>> Feel free to include parts of colt into commons and modify as you feel
>> appropriate under the license, which is Apache-style, and requires the
>> copyright to be retained. I gather that this could be the crux for
>> ASF. Unfortunately I myself can't transfer the copyright, since it
>> does not belong to me, but rather my (former) research organisation,
>> CERN. If this should not work for ASF, colt may still be worth looking
>> at when contemplating your design and impl. questions.
>>
>
> I will be consulting with ASF to find out exactly what we can work with
> while maintaining copyright. Unfortunately, this may be a limitiation.
> But I'll try to find out more before speculating any further.
>
> Many Thanks,
> Mark
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: COLT and Licensing [math]
Posted by "Mark R. Diggory" <md...@latte.harvard.edu>.
Wolfgang Hoschek wrote:
> Hi Mark,
>
> Mark R. Diggory wrote:
>
>> Wolfgang,
>>
>> Can you comment on your decision to remove the dependency of Paul
>> Houle's RngPack implementation?
>
>
> RngPack is GPL'd, and this was a problem for many. If it would be LGPL's
> or Apache style, it would not pose (or have posed) a problem. So the
> removal is due too licensing concerns, not due too any technical
> consideration.
>
I think some information has not gotten to you. Paul Houle has just
re-released RngPack under a BSD style license. We're discussing other
Licensing options as well.
>>
>> I've been discussing with Paul the possibility of a establishing a
>> consortium style "Service Provider" interface for "Research Grade"
>> random number generators (separate from the java.security.SecureRandom
>> API). Is this something you may have an interest in?
>
>
> At first sight, this seems a little overkill (cost/benefit). My guess is
> that a minimal interface would do fine for most people, and a
> consortium, service providers, factories, abstract classes and default
> search mechanisms do not "pull their weight" just to get hold of a
> random number generator.
>
I think I exagerated a bit with the use of term "consortium". I'm mostly
just refering to something like the java.security.SecureRandom SPI
(practically Identical but specifically not for encryption grade RNG).
This way, if you write an application that uses (lets call it
RandomFactory), and there are service providers for a bunch of different
Random Number generators out there, then you don't need to "rewrite"
your code to test it performance/correlation on different generators.
>>
>> Also, can you possibly comment on your position and or interest
>> concerning the possible inclusion of some parts of your codebase into
>> Jakarta Commons Math in the possible future? That is, if our ASF
>> licensing permits.
>
>
> Overall, I've moved on to other areas (P2P databases). So these days,
> I'm maintaining colt on a very minimal time budget, and if someone else
> (like jakarta-commons) picks up the theme, it would be very good and
> welcome.
Interestingly, I'm becoming involved with some efforts here at Harvard
to implement what we're calling the "Crimson Grid Initiative". I may be
reviewing your software (Firefish and Spitfire) in the near future :-)
>
> Feel free to include parts of colt into commons and modify as you feel
> appropriate under the license, which is Apache-style, and requires the
> copyright to be retained. I gather that this could be the crux for ASF.
> Unfortunately I myself can't transfer the copyright, since it does not
> belong to me, but rather my (former) research organisation, CERN. If
> this should not work for ASF, colt may still be worth looking at when
> contemplating your design and impl. questions.
>
I will be consulting with ASF to find out exactly what we can work with
while maintaining copyright. Unfortunately, this may be a limitiation.
But I'll try to find out more before speculating any further.
Many Thanks,
Mark
--
Mark Diggory
Software Developer
Harvard MIT Data Center
http://osprey.hmdc.harvard.edu
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: COLT and Licensing was: [math] [primitives]
Posted by Wolfgang Hoschek <wh...@lbl.gov>.
Hi Mark,
Mark R. Diggory wrote:
> Wolfgang,
>
> Can you comment on your decision to remove the dependency of Paul
> Houle's RngPack implementation?
RngPack is GPL'd, and this was a problem for many. If it would be LGPL's
or Apache style, it would not pose (or have posed) a problem. So the
removal is due too licensing concerns, not due too any technical
consideration.
>
> I've been discussing with Paul the possibility of a establishing a
> consortium style "Service Provider" interface for "Research Grade"
> random number generators (separate from the java.security.SecureRandom
> API). Is this something you may have an interest in?
At first sight, this seems a little overkill (cost/benefit). My guess is
that a minimal interface would do fine for most people, and a
consortium, service providers, factories, abstract classes and default
search mechanisms do not "pull their weight" just to get hold of a
random number generator.
>
> Also, can you possibly comment on your position and or interest
> concerning the possible inclusion of some parts of your codebase into
> Jakarta Commons Math in the possible future? That is, if our ASF
> licensing permits.
Overall, I've moved on to other areas (P2P databases). So these days,
I'm maintaining colt on a very minimal time budget, and if someone else
(like jakarta-commons) picks up the theme, it would be very good and
welcome.
Feel free to include parts of colt into commons and modify as you feel
appropriate under the license, which is Apache-style, and requires the
copyright to be retained. I gather that this could be the crux for ASF.
Unfortunately I myself can't transfer the copyright, since it does not
belong to me, but rather my (former) research organisation, CERN. If
this should not work for ASF, colt may still be worth looking at when
contemplating your design and impl. questions.
Regards,
Wolfgang.
-----------------------------------------------------------------------
Wolfgang Hoschek | email: whoschek@lbl.gov
Distributed Systems Department | phone: (415)-533-7610
Berkeley Laboratory | http://dsd.lbl.gov/~hoschek/
-----------------------------------------------------------------------
>
> thanks for any response,
> Mark
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: COLT and Licensing was: [math] [primitives]
Posted by "Mark R. Diggory" <md...@latte.harvard.edu>.
Wolfgang,
Can you comment on your decision to remove the dependency of Paul
Houle's RngPack implementation?
I've been discussing with Paul the possibility of a establishing a
consortium style "Service Provider" interface for "Research Grade"
random number generators (separate from the java.security.SecureRandom
API). Is this something you may have an interest in?
Also, can you possibly comment on your position and or interest
concerning the possible inclusion of some parts of your codebase into
Jakarta Commons Math in the possible future? That is, if our ASF
licensing permits.
thanks for any response,
Mark
--
Mark Diggory
(Jakarta Commons Math Developer)
Software Developer
Harvard MIT Data Center
http://osprey.hmdc.harvard.edu
Wolfgang Hoschek wrote:
> Hi,
>
> I'm the COLT maintainer and not regularly on this list, so only saw the
> discussion now circumstanstially.
>
> The latest stable release (1.1.0) is repackaged due too popular demand,
> eliminates license-offending packages, does not include GPL'd code
> anymore, and is available from a new location:
>
> http://dsd.lbl.gov/~hoschek/colt/
>
> FYI, the licenses are here:
>
> http://dsd.lbl.gov/~hoschek/colt/dependencies.html
>
> The LGPL corejava package is not essential for most parts of the library
> and could be dropped by sacrificing some print functionality. Similar
> things hold for the com.isml.math package and the concurrent lib.
>
> CC me directly if there should me more ongoing discussion.
>
> Wolfgang.
> ---------------------------------------------------------------------
> 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