Re: Licensing
Ricardo Gladwell wrote: Emmanuel Bourg wrote: Excluding LGPLed projects is just a political decision imho. Emmanuel Bourg Sorry for sounding newbie about this, but what exactly are the political difficulties to hosting LGPL and ASL projects on the apache.org domain. Does the ASF and the FSF not get along? The concept of the LGPL is quite clear for me, it's do whatever you want with your code, but if you change my LGPL code, you have to license your modification under the LGPL. I agree the LGPL may be worded ambiguously with regard to Java programs, but for Hibernate this ambiguity is clarified in the License FAQ. One could say this FAQ has no legal value if it's not included in the actual license, but it's not true. It's a promise made on the official site, that's endorsed by the authors, that they will not consider this usage as an infringement of their copyright, and this kind of promise has a legal value in court, see Promissory Estoppel for more information. You can ask any author of a Java LGPLed project to make a similar clarification if you want to use its work in an ASLed code, I'm ready to bet none will refuse because it was the way they intended to distribute their work. Emmanuel Bourg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Licensing (was: Re: [configuration] handling exceptions in AbstractConfiguration implementations)
Henri Yandell [EMAIL PROTECTED] writes: (Henning's .sig is especially apt in his reply btw. :) ) To me, the Levesque paper is a pretty good summary of the current state of the (mostly GPL) open source community as a whole. It hurts and she steps on so many toes of all the self-declared open-source advocats and all information must be free types. This might be the main reason, why leading open source community advocates did their best to damage the reputation of her. IMHO, it is a real must read for everyone that writes and especially uses open source. Funnily enough, many of the points that she raises don't apply to the ASF. Which IMHO shows, that the ASF, for all its shortcomings and problems, seem to have gotten quite a number of things right. Regards Henning -- Dipl.-Inf. (Univ.) Henning P. Schmiedehausen INTERMETA GmbH [EMAIL PROTECTED]+49 9131 50 654 0 http://www.intermeta.de/ RedHat Certified Engineer -- Jakarta Turbine Development -- hero for hire Linux, Java, perl, Solaris -- Consulting, Training, Development Fighting for one's political stand is an honorable action, but re- fusing to acknowledge that there might be weaknesses in one's position - in order to identify them so that they can be remedied - is a large enough problem with the Open Source movement that it deserves to be on this list of the top five problems. -- Michelle Levesque, Fundamental Issues with Open Source Software Development - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Licensing
On Thu, 07 Oct 2004 13:13:32 +0200, Emmanuel Bourg [EMAIL PROTECTED] wrote: Ricardo Gladwell wrote: Emmanuel Bourg wrote: Excluding LGPLed projects is just a political decision imho. Emmanuel Bourg Sorry for sounding newbie about this, but what exactly are the political difficulties to hosting LGPL and ASL projects on the apache.org domain. Does the ASF and the FSF not get along? To answer Richard's question (didn't see it) I think the only political difficulty is the usual 'Free-Software' vs 'Open-Source' one that has existed for a long time. Which links to Henning's point; we spend tonnes of time and effort on tiny matters on legal pedantics instead of coding. The concept of the LGPL is quite clear for me, it's do whatever you want with your code, but if you change my LGPL code, you have to license your modification under the LGPL. I agree the LGPL may be worded ambiguously with regard to Java programs, but for Hibernate this ambiguity is clarified in the License FAQ. One could say this FAQ has no legal value if it's not included in the actual license, but it's not true. It's a promise made on the official site, that's endorsed by the authors, that they will not consider this usage as an infringement of their copyright, and this kind of promise has a legal value in court, see Promissory Estoppel for more information. Now we're onto the IANAL stuff and ponderings on how to get such suggestions to a lawyer without it turning into an expensive 2 week QA. Can Promissory Estoppel (whatever that is) be given just on a website etc. For example, I'd love to see an ASF lawyer come up with a concise 'footnote' to the LGPL that we could ask Java LGPL users to add to their licences. Or just a 'promissory estoppel' that could be placed there. I agree that no one who has made their library LGPL does so for potential Java virality. Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Licensing
Henri Yandell wrote: To answer Richard's question (didn't see it) I think the only political difficulty is the usual 'Free-Software' vs 'Open-Source' one that has existed for a long time. Which links to Henning's point; we spend tonnes of time and effort on tiny matters on legal pedantics instead of coding. True, but on the other hand we could spend tonnes of times and effort duplicating LGPL code because no one cleared the legal uncertaincy. Now we're onto the IANAL stuff and ponderings on how to get such suggestions to a lawyer without it turning into an expensive 2 week QA. Can Promissory Estoppel (whatever that is) be given just on a website etc. For example, I'd love to see an ASF lawyer come up with a concise 'footnote' to the LGPL that we could ask Java LGPL users to add to their licences. Or just a 'promissory estoppel' that could be placed there. That's a good idea, how do we contact the ASF lawyers ? Emmanuel Bourg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Licensing
Henning P. Schmiedehausen wrote: Henri Yandell [EMAIL PROTECTED] writes: IMHO, it is a real must read for everyone that writes and especially uses open source. Funnily enough, many of the points that she raises don't apply to the ASF. Hmm... I might disagree with that one. For example, I don't know many newbie users who could single-handedly set-up and configure the Apache web server with Tomcat without encountering a few problems. Also, some ASF projects have very skimpy documentation in places. Fighting for one's political stand is an honorable action, but re- fusing to acknowledge that there might be weaknesses in one's position - in order to identify them so that they can be remedied - is a large enough problem with the Open Source movement that it deserves to be on this list of the top five problems. -- Michelle Levesque, Fundamental Issues with Open Source Software Development I have heard an interesting theory behind this: that the technical affinity shared by geeks and open-source advocates across the world is actually a form of mild autism, passed down the male line. Anecdotally, on my father's side many of my uncles are engineers, and my grandfather was an engineer (who, interestingly, claims to have invented the flip chart which he failed to patent) - the geek old guard. And, in this generation, most of my male cousins are working in the IT industry as programmers and system administrators - the new geeks. Anyway, my point is that it would also seem that, along with poor social skills and shyness, a form bi-polar fanaticism seems to come with this techno-autism. The constant them or us attitude one sees on forums such as /. seem to be near universal constant. I mention it only for interests sake. :) Kind regards, -- Ricardo - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Licensing
How dare they say that about us!!! ;) -- James Mitchell Software Engineer / Open Source Evangelist EdgeTech, Inc. 678.910.8017 AIM: jmitchtx - Original Message - From: Ricardo Gladwell [EMAIL PROTECTED] To: Jakarta Commons Developers List [EMAIL PROTECTED] Sent: Thursday, October 07, 2004 10:58 AM Subject: Re: Licensing Henning P. Schmiedehausen wrote: Henri Yandell [EMAIL PROTECTED] writes: IMHO, it is a real must read for everyone that writes and especially uses open source. Funnily enough, many of the points that she raises don't apply to the ASF. Hmm... I might disagree with that one. For example, I don't know many newbie users who could single-handedly set-up and configure the Apache web server with Tomcat without encountering a few problems. Also, some ASF projects have very skimpy documentation in places. Fighting for one's political stand is an honorable action, but re- fusing to acknowledge that there might be weaknesses in one's position - in order to identify them so that they can be remedied - is a large enough problem with the Open Source movement that it deserves to be on this list of the top five problems. -- Michelle Levesque, Fundamental Issues with Open Source Software Development I have heard an interesting theory behind this: that the technical affinity shared by geeks and open-source advocates across the world is actually a form of mild autism, passed down the male line. Anecdotally, on my father's side many of my uncles are engineers, and my grandfather was an engineer (who, interestingly, claims to have invented the flip chart which he failed to patent) - the geek old guard. And, in this generation, most of my male cousins are working in the IT industry as programmers and system administrators - the new geeks. Anyway, my point is that it would also seem that, along with poor social skills and shyness, a form bi-polar fanaticism seems to come with this techno-autism. The constant them or us attitude one sees on forums such as /. seem to be near universal constant. I mention it only for interests sake. :) Kind regards, -- Ricardo - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Licensing
On Thu, 07 Oct 2004 16:19:36 +0200, Emmanuel Bourg [EMAIL PROTECTED] wrote: Henri Yandell wrote: Now we're onto the IANAL stuff and ponderings on how to get such suggestions to a lawyer without it turning into an expensive 2 week QA. Can Promissory Estoppel (whatever that is) be given just on a website etc. For example, I'd love to see an ASF lawyer come up with a concise 'footnote' to the LGPL that we could ask Java LGPL users to add to their licences. Or just a 'promissory estoppel' that could be placed there. That's a good idea, how do we contact the ASF lawyers ? With difficulty. Eavesdropping on the board list, they are working on ways to get a better line of communication to the legal team (and getting a more defined legal team). There are some number of pro-bono hours per month, but these are easy to use up I think. My plan for this issue is: 1) Identify the current situation to get away from the Can I use project X which is under LGPL questions. See http://wiki.apache.org/jakarta/LicenceIssues. 2) Ensure the Jakarta cvs repository is clean in regards to said issues. 3) Collate ideas for work-arounds. Plugin-architecture; footnotes to LGPL etc. 4) Any work-arounds that seem good would then be put on a request for the board to consider. Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Licensing
On 7 Oct 2004, at 15:58, Ricardo Gladwell wrote: Henning P. Schmiedehausen wrote: Henri Yandell [EMAIL PROTECTED] writes: IMHO, it is a real must read for everyone that writes and especially uses open source. Funnily enough, many of the points that she raises don't apply to the ASF. Hmm... I might disagree with that one. For example, I don't know many newbie users who could single-handedly set-up and configure the Apache web server with Tomcat without encountering a few problems. hmm... not sure that that's a very good example. AIUI interoperation with apache HTTPD was never really a primary goal of tomcat (and was left to secondary sub-projects). jserv is the ASF project which fills that gap. IIRC as a very green newbie, i found jserv really easy to install and integrate with apache HTTPD. Also, some ASF projects have very skimpy documentation in places. i'd go as far as saying most. but (once a project's been around long enough) there are usually enough books and articles to make up for this deficit. it interests me that academic licensed project seem to make up for lack of technical documentation by the quantity of published hard copy. - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Licensing (was: Re: [configuration] handling exceptions in AbstractConfiguration implementations)
Eric Pugh [EMAIL PROTECTED] writes: This is really driving me crazy.. I have tracked threads on general and jakarta-pmc mailing lists about this.. And everytime it comes down to I am not a lawyer and a bunch of FUD. We really need someone from the top of Apache to provide direction. I work a lot with hibernate code and can think of at least 4 projects that have hibernate code in them (at least as far as import statements). There _is_ a clear statement from the board. And even though we don't really like it technology-wise, it is sound from a licensing point of view. #1 No LGPL dependencies in code delivered from *.apache.org #2 import xxx where xxx is a LGPLed package is already a dependency. I think that Geir made this clear on [EMAIL PROTECTED] So every project that does have e.g. Hibernate dependencies in there must move off-Apache. This holds true for some maven-plugins and it would also hold true for a possible Hibernate-related commons-configuration module. This is not a bad thing IMHO. Apache is mainly about community and the drive to keep the sources clean. Having some modules or code being outside apache.org (e.g. on SourceForge) shouldn't be a big problem. We add a links to related stuff to the site and everything is fine. Regards Henning -- Dipl.-Inf. (Univ.) Henning P. Schmiedehausen INTERMETA GmbH [EMAIL PROTECTED]+49 9131 50 654 0 http://www.intermeta.de/ RedHat Certified Engineer -- Jakarta Turbine Development -- hero for hire Linux, Java, perl, Solaris -- Consulting, Training, Development Fighting for one's political stand is an honorable action, but re- fusing to acknowledge that there might be weaknesses in one's position - in order to identify them so that they can be remedied - is a large enough problem with the Open Source movement that it deserves to be on this list of the top five problems. -- Michelle Levesque, Fundamental Issues with Open Source Software Development - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Licensing (was: Re: [configuration] handling exceptions in AbstractConfiguration implementations)
Correct. I'll work to resolve the lack of published information. It's more than just LGPL really, we need a page that lists all acceptable OSI-accepted licences. LGPL is just the biggest issue as it's probably the 2nd most common open-source Java licence behind BSD-like. As far as the FUD/IANAL stuff, it's all pretty honest but I'm happy to take a stand and say that we won't have LGPL in Jakarta code until we hear otherwise from the board. I'd love to be using JFreeChart here, but it's LGPL. Hen (Henning's .sig is especially apt in his reply btw. :) ) On Wed, 6 Oct 2004 22:13:30 + (UTC), Henning P. Schmiedehausen [EMAIL PROTECTED] wrote: Eric Pugh [EMAIL PROTECTED] writes: This is really driving me crazy.. I have tracked threads on general and jakarta-pmc mailing lists about this.. And everytime it comes down to I am not a lawyer and a bunch of FUD. We really need someone from the top of Apache to provide direction. I work a lot with hibernate code and can think of at least 4 projects that have hibernate code in them (at least as far as import statements). There _is_ a clear statement from the board. And even though we don't really like it technology-wise, it is sound from a licensing point of view. #1 No LGPL dependencies in code delivered from *.apache.org #2 import xxx where xxx is a LGPLed package is already a dependency. I think that Geir made this clear on [EMAIL PROTECTED] So every project that does have e.g. Hibernate dependencies in there must move off-Apache. This holds true for some maven-plugins and it would also hold true for a possible Hibernate-related commons-configuration module. This is not a bad thing IMHO. Apache is mainly about community and the drive to keep the sources clean. Having some modules or code being outside apache.org (e.g. on SourceForge) shouldn't be a big problem. We add a links to related stuff to the site and everything is fine. Regards Henning -- Dipl.-Inf. (Univ.) Henning P. Schmiedehausen INTERMETA GmbH [EMAIL PROTECTED]+49 9131 50 654 0 http://www.intermeta.de/ RedHat Certified Engineer -- Jakarta Turbine Development -- hero for hire Linux, Java, perl, Solaris -- Consulting, Training, Development Fighting for one's political stand is an honorable action, but re- fusing to acknowledge that there might be weaknesses in one's position - in order to identify them so that they can be remedied - is a large enough problem with the Open Source movement that it deserves to be on this list of the top five problems. -- Michelle Levesque, Fundamental Issues with Open Source Software Development - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Licensing
Henri Yandell wrote: I'll work to resolve the lack of published information. It's more than just LGPL really, we need a page that lists all acceptable OSI-accepted licences. LGPL is just the biggest issue as it's probably the 2nd most common open-source Java licence behind BSD-like. http://nagoya.apache.org/wiki/apachewiki.cgi?Licensing This is on the old-soon-to-be-deprecated wiki, and it hasn't been ported over. -- Serge Knystautas Lokitech software . strategy . design http://www.lokitech.com p. 301.656.5501 e. [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: COLT and Licensing was: [math] [primitives]
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: [EMAIL PROTECTED] Distributed Systems Department| phone: (415)-533-7610 Berkeley Laboratory | http://dsd.lbl.gov/~hoschek/ --- thanks for any response, Mark - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: COLT and Licensing [math]
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: COLT and Licensing [math]
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
ttInteger.MIN_VALUE/tt and ttInteger.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
ttInteger.MIN_VALUE/tt and ttInteger.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
ttLong.MIN_VALUE/tt and ttLong.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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: COLT and Licensing [math]
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 ttInteger.MIN_VALUE/tt and ttInteger.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 ttInteger.MIN_VALUE/tt and ttInteger.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
ttLong.MIN_VALUE/tt and ttLong.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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: COLT and Licensing was: [math] [primitives]
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Licensing Issues
On Wed, 23 Oct 2002, Michael A. Smith wrote: Jeff Prickett wrote: Michael, The licensing details will be worked out soon. hrm. what's this mean? Just means that I will clean up the dates and double check that each file holds a correct license before any formal release or snapshot A good portion of the Periodicity code base dates back to 2000. Some of the UML diagrams date back to 1999. However, you are right the code just checked in is totally new and as such should hold (c) 2002. cool. :) As far as this being my own original contribution. It is. There are no conflicts as far as outside copyrights. Thanks for reaffirming that. I was just being anal about the dates though. :) I am pretty anal about licensing issues myself. I worked for hire on a proprietary version of iCalendar that was based on the Apache code that I had written so I had to cover my but about what I put into Apache CVS. I dont think that I will ever work on a proprietary extension like that for someone else again. michael Jeff Prickett -- To unsubscribe, e-mail: mailto:commons-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:commons-dev-help;jakarta.apache.org
Licensing Issues
Michael, The licensing details will be worked out soon. A good portion of the Periodicity code base dates back to 2000. Some of the UML diagrams date back to 1999. However, you are right the code just checked in is totally new and as such should hold (c) 2002. As far as this being my own original contribution. It is. There are no conflicts as far as outside copyrights. Thanks Jeff Prickett -- To unsubscribe, e-mail: mailto:commons-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:commons-dev-help;jakarta.apache.org
Re: Licensing Issues
Jeff Prickett wrote: Michael, The licensing details will be worked out soon. hrm. what's this mean? A good portion of the Periodicity code base dates back to 2000. Some of the UML diagrams date back to 1999. However, you are right the code just checked in is totally new and as such should hold (c) 2002. cool. :) As far as this being my own original contribution. It is. There are no conflicts as far as outside copyrights. Thanks for reaffirming that. I was just being anal about the dates though. :) michael -- Michael A. Smith [EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:commons-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:commons-dev-help;jakarta.apache.org
Re: Licensing (Re: [cli] new command line interface library...)
On Sat, Dec 22, 2001 at 02:16:05PM +1100, Jeff Turner wrote: As for LGPL, it's technical shortcomings are indeed problematic, specifically: The scope of the LGPL is too coarse-grained. The scope is furthermore open to interpretation. It is limited to some fuzzy notion of functional entities (a collection of software functions and/or data prepared so as to be conveniently linked with application programs). I gather it's this open to interpretation problem which currently means LGPL'ed code cannot be used in Apache projects. A few years ago, I was surprised when I went back to gnu.org to re-read the LGPL -- and I noticed the name had been changed from the Library GPL to the Lesser GPL ... after reading it, that seems a fair description. I've seen some long discussions of the LGPL amoung the ASF members interested in licenses -- iirc, the problems include difficulties with maintenence releases and the fact that the LGPL is ultimately still viral (it's just less virulent). I don't know if there's a publicly posted explanation of this, but I could ask around (there was some talk of this, a while back, but ultimately istr it was left to lie for political reasons -- most of the ASF folks are not really interested in getting into arguments over licenses, just in writing software). take care -- Ed -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Licensing (Re: [cli] new command line interface library...)
Exactly. That is my case and the case of several friends of mine. Have fun, Paulo Gaspar -Original Message- From: Jeff Turner [mailto:[EMAIL PROTECTED]] Sent: Saturday, December 22, 2001 4:16 AM ... Also as the article says, non-copyleft code gets *more* contributions than copylefted, because those services corporations are now free to use and improve the code. There is a strong commercial incentive for improvements to be rolled back into the code base, because maintaining a forked version of a project is expensive, especially when it's not your primary money-earner :) ... -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
