CC0 license compatibility

classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|

CC0 license compatibility

Alan Woodward
As part of a fix for SOLR-1972 I'm porting various bits of https://github.com/codahale/metrics into Solr.  One of the classes, ThreadLocalRandom, is released under a CC0 license, with the following header:

/*
 * Written by Doug Lea with assistance from members of JCP JSR-166
 * Expert Group and released to the public domain, as explained at
 * http://creativecommons.org/publicdomain/zero/1.0/
 *
 * http://gee.cs.oswego.edu/cgi-bin/viewcvs.cgi/jsr166/src/main/java/util/concurrent/ThreadLocalRandom.java?view=markup
 */

This fails ant precommit, as it doesn't have the expected Apache License header.  Are we legally allowed to add the AL header above this existing license?  Google leads me to believe that the licenses are compatible, but adding a new one feels wrong to me.

Thanks, Alan
---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: CC0 license compatibility

Yonik Seeley-4
On Tue, Jan 1, 2013 at 5:22 PM, Alan Woodward
<[hidden email]> wrote:
> This fails ant precommit, as it doesn't have the expected Apache License header.

That looks a bit too strict... anyone know how we can relax these or
easily add exceptions?

-Yonik
http://lucidworks.com

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: CC0 license compatibility

Dawid Weiss
In reply to this post by Alan Woodward
Just curious -- what do you need a thread local random for, Alan? Is
it for tests or for the main code?

Dawid

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: CC0 license compatibility

Alan Woodward
It's used in the statistics package for sampling.  The Histogram class holds a pool of values for calculating means and variances from a stream of data, and uses the ThreadLocalRandom to determine whether or not a new value will be added to the pool.

This is copied directly from the existing metrics code, and it's quite possible that there's already something in Lucene that I could use instead.  Which would also clear up the license header problem.  :-)

On 2 Jan 2013, at 07:59, Dawid Weiss wrote:

> Just curious -- what do you need a thread local random for, Alan? Is
> it for tests or for the main code?
>
> Dawid
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: CC0 license compatibility

Dawid Weiss
> It's used in the statistics package for sampling.  The Histogram class holds a pool of values for calculating means and variances from a stream of data, and uses the ThreadLocalRandom to determine whether or not a new value will be added to the pool.

You probably have talked about it but just to mention -- wouldn't an
algorithmic solution the type of rrd be better than collecting all the
individual samples? Depending on the stats you need of course. From
what I can remember rrd only stores a fixed size buffers so it's very
memory efficient.

http://code.google.com/p/rrd4j/

> This is copied directly from the existing metrics code, and it's quite possible that there's already something in Lucene that I could use instead.  Which would also clear up the license header problem.  :-)

There isn't in the main codebase I think. A congruential Random should
be pretty trivial to write though (since it's described in the JavaDoc
of Random itself). Doug's ThreadLocal version is useful but if your
code allows it you could just pass individual per-thread Random
instances to any interested code and not deal with ThreadLocals at
all.

There is also a number of Random implementations in commons-math and
they're definitely Apache licensed :)
http://commons.apache.org/math/userguide/random.html

D.

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: CC0 license compatibility

Alan Woodward
That's what the sampling code does - it holds an AtomicLongArray of fixed length, and updates the values in there randomly.  There's also an ExponentiallyDecayingSample which biases the collection of values towards more recent entries, for the 5-minute and 15-minute window averages.  You can see the patch here:

https://issues.apache.org/jira/secure/attachment/12562854/SOLR-1972_forked-metrics.patch

TBH, I'm not even sure we need a ThreadLocal random here, though.  Are there likely to be thread-safety issues when generating random numbers?

On 2 Jan 2013, at 09:24, Dawid Weiss wrote:

>> It's used in the statistics package for sampling.  The Histogram class holds a pool of values for calculating means and variances from a stream of data, and uses the ThreadLocalRandom to determine whether or not a new value will be added to the pool.
>
> You probably have talked about it but just to mention -- wouldn't an
> algorithmic solution the type of rrd be better than collecting all the
> individual samples? Depending on the stats you need of course. From
> what I can remember rrd only stores a fixed size buffers so it's very
> memory efficient.
>
> http://code.google.com/p/rrd4j/
>
>> This is copied directly from the existing metrics code, and it's quite possible that there's already something in Lucene that I could use instead.  Which would also clear up the license header problem.  :-)
>
> There isn't in the main codebase I think. A congruential Random should
> be pretty trivial to write though (since it's described in the JavaDoc
> of Random itself). Doug's ThreadLocal version is useful but if your
> code allows it you could just pass individual per-thread Random
> instances to any interested code and not deal with ThreadLocals at
> all.
>
> There is also a number of Random implementations in commons-math and
> they're definitely Apache licensed :)
> http://commons.apache.org/math/userguide/random.html
>
> D.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: CC0 license compatibility

Dawid Weiss
> That's what the sampling code does - it holds an AtomicLongArray of fixed length, and updates the values in there randomly.  There's also an ExponentiallyDecayingSample which biases the collection of values towards more recent entries, for the 5-minute and 15-minute window averages.  You can see the patch here:

Ah, ok! I just remembered that some of this stuff was exploding memory
and Uwe reverted it so that Jenkins could do its job. Don't know if it
was a bug or something else - had very little time to look into it.

> TBH, I'm not even sure we need a ThreadLocal random here, though.  Are there likely to be thread-safety issues when generating random numbers?

I think they may be using it to avoid synchronizations on the default
Random implementation. I honestly don't think this is going to be a
problem in practice if you replaced the ThreadLocal random with just a
Random (even if there are conflicts adding random + random noise =
random noise). If the rate of updates is really high, or if you want a
better random generator than the default (which you may want to
consider) then copy a random generator from commons math and voila,
should be fine?

Dawid

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: CC0 license compatibility

Alan Woodward-2
>
> Ah, ok! I just remembered that some of this stuff was exploding memory
> and Uwe reverted it so that Jenkins could do its job. Don't know if it
> was a bug or something else - had very little time to look into it.

That was a bug on my part.  :-(  This should fix it, though.

>
>> TBH, I'm not even sure we need a ThreadLocal random here, though.  Are there likely to be thread-safety issues when generating random numbers?
>
> I think they may be using it to avoid synchronizations on the default
> Random implementation. I honestly don't think this is going to be a
> problem in practice if you replaced the ThreadLocal random with just a
> Random (even if there are conflicts adding random + random noise =
> random noise). If the rate of updates is really high, or if you want a
> better random generator than the default (which you may want to
> consider) then copy a random generator from commons math and voila,
> should be fine?

The updates are per-request, which could be pretty high, I suppose.  I'll have a look at commons-math, anyway.  Thanks!

Alan Woodward
[hidden email]
---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: CC0 license compatibility

Dawid Weiss
> That was a bug on my part.  :-(  This should fix it, though.

No worries. It was holiday season so Uwe took the liberty to revert I guess.

> The updates are per-request, which could be pretty high, I suppose.  I'll have a look at commons-math, anyway.  Thanks!

I don't think it'd be anywhere close to noticeable given the full
request, but a Mersenne twister would provide better distribution too
though so you may consider that.

Dawid

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: CC0 license compatibility

Robert Muir
In reply to this post by Alan Woodward
On Tue, Jan 1, 2013 at 5:22 PM, Alan Woodward
<[hidden email]> wrote:

> As part of a fix for SOLR-1972 I'm porting various bits of https://github.com/codahale/metrics into Solr.  One of the classes, ThreadLocalRandom, is released under a CC0 license, with the following header:
>
> /*
>  * Written by Doug Lea with assistance from members of JCP JSR-166
>  * Expert Group and released to the public domain, as explained at
>  * http://creativecommons.org/publicdomain/zero/1.0/
>  *
>  * http://gee.cs.oswego.edu/cgi-bin/viewcvs.cgi/jsr166/src/main/java/util/concurrent/ThreadLocalRandom.java?view=markup
>  */
>
> This fails ant precommit, as it doesn't have the expected Apache License header.  Are we legally allowed to add the AL header above this existing license?  Google leads me to believe that the licenses are compatible, but adding a new one feels wrong to me.
>
>

If you look at the ant task in question, you will see it has a list of
supported licenses/regexps.

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]