RStan's DESCRIPTION and LICENSE

[Jiqiang Guo]

I am about to make it possible to install RStan using 

install.packages('rstan', repos='http://wiki.stan.googlecode.com/git/R')

so that Andrew could easily install RStan. 

I just revised the DESCRIPTION and LICENSE of rstan (under STAN_HOME/stan/rstan/rstan). 

Please take a look and revise them if needed as I was not serious enough about LICENSE and authorship

before. 

--

Jiqiang 

[Bob Carpenter]

The license looks fine.

I'm fine with the everyone-onboard author list, which
inclues all the Stan authors:

Author: Andrew Gelman <gel...@stat.columbia.edu>, Bob Carpenter <ca...@alias-i.com>, Matt Hoffman
<mdho...@cs.princeton.edu>, Daniel Lee <bea...@alum.mit.edu>, Michale Malecki <mal...@gmail.com>, Ben Goodrich
<goodri...@gmail.com>, Jiqiang Guo <guo...@gmail.com>, Marcus Brubaker <mbru...@cs.toronto.edu>

I'd suggest putting yourself first and the rest of us in alphabetical order.
(If it were bio, Andrew would go last as the "head of lab".)

- Bob

[Ben Goodrich]

On Monday, August 6, 2012 10:41:11 PM UTC-4, Jiqiang Guo wrote:

I just revised the DESCRIPTION and LICENSE of rstan (under STAN_HOME/stan/rstan/rstan). 

Please take a look and revise them if needed as I was not serious enough about LICENSE and authorship

before. 

Is it correct that RStan does not modify any of the code under rstan/inst/include ? If so, then I think the DESCRIPTION can say

License: GPL (>= 3)

and then add a

LicenseNote: RStan includes unmodified copies of X, Y, Z all of which are available at x, y, z under open-source licenses that are compatible with version 3 of the GPL.

That is more or less what RcppEigen does. Being able to put 

License: GPL (>= 3)

rather than

License: FILE

is good because some companies grep the DESCRIPTION of all package to avoid installing / using any GPL code and others grep the DESCRIPTION to only use FLOSS.

In general, RStan should follow the FSF's guidelines (although a lot of packages don't)

https://www.gnu.org/licenses/gpl-howto.html

Ben

[Bob Carpenter]

I think we should do exactly what Ben suggests.

If RStan does modify any of the code in rstan/inst/include, we should
rearrange things so that it doesn't.

We should only be redistributing a part of Boost, and nothing
from Eigen or Google Test. Eigen we'll get through RCppEigen and
Google Code we don't need at all.

I'm going to remove all unsupported Eigen packages from the
C++ Stan repository other than FFT unless anyone objects.

- Bob

[Jiqiang Guo]

I totally agree.  I hate `that R CMD check` tells me that RStan is not FOSS since the license in the DESCRIPTION FILE is not GPLish.  

I did not change any stan code included under rstan/inst/include and nor did I include google test code.  So I could just follow what Ben said. 

--

Jiqiang 

[Ben Goodrich]

On Friday, August 10, 2012 2:31:38 PM UTC-4, Bob Carpenter wrote:

I'm going to remove all unsupported Eigen packages from the
C++ Stan repository other than FFT unless anyone objects.

 
I am not objecting, but I can't see why having them around in the repository would cause a problem if Stan does not (currently) utilize them. I could see the Kronecker, MatrixFunctions, and MoreVectorization modules being useful to somebody, although such a somebody is presumably more than capable of putting those modules back in. The optimization-related ones are also pretty good, although I guess Stan is going to do its own soon.

Ben

[Bob Carpenter]

On 8/10/12 2:52 PM, Ben Goodrich wrote:
> On Friday, August 10, 2012 2:31:38 PM UTC-4, Bob Carpenter wrote:
>
> I'm going to remove all unsupported Eigen packages from the
> C++ Stan repository other than FFT unless anyone objects.
>
>
> I am not objecting, but I can't see why having them around in the repository would cause a problem if Stan does not
> (currently) utilize them.

There are two problems:

1. It produces more code for false hits when
searching. For instance, I don't want anyone
to confuse the Eigen auto-dif for what we're doing
for auto-dif, and

2. It's just more code to download, though given how much
we have, I doubt it'll be noticeable.

> I could see the Kronecker, MatrixFunctions, and MoreVectorization modules being useful to
> somebody, although such a somebody is presumably more than capable of putting those modules back in. The
> optimization-related ones are also pretty good, although I guess Stan is going to do its own soon.

Right. I don't know when we'll get to optimization.
It would be pretty easy. But then it'd also make sense
to just use Stan's model classes and then use someone else's
optimization package.

Also, I wish they'd just support these or get rid of them.
Having the tag "unsupported" in the file path makes me very
nervous. So I'd rather not use these things unless it's
absolutely necessary. The use of unsupported/Eigen/FFT was a tradeoff
between licensing issues and fear of using unsupported modules.
For example, Eigen's FFT seems unlikely to be upgraded with
new versions of KissFFT, of which there have been several since
Eigen's incorporation of KissFFT.

- Bob

[Ben Goodrich]

On Friday, August 10, 2012 3:01:38 PM UTC-4, Bob Carpenter wrote:

Also, I wish they'd just support these or get rid of them.
Having the tag "unsupported" in the file path makes me very
nervous.  So I'd rather not use these things unless it's
absolutely necessary.  

Some unsupported modules are more supported than others. But Eigen only has a few main developers and a ton of users, so they don't want to promise things they can't deliver. But if there were a problem with something in unsupported/ , someone would presumably be willing to talk about it on the list and try to fix it if it didn't require rewriting something in the main part of Eigen. For FFT, it was probably worth it.

Ben