LGPL code in Stan?

[Sebastian Weber]

Hi!

To my knowledge it would be ok to include LGPL code into Stan from a legal perspective. I.e. one could distribute respective code, but whenever changes are made to this piece, then it must go back to the authors.

Is it hence thinkable to include LGPL code in Stan?

The reason I am asking is that the author of odeSD is really keen on making odeSD as header only C++ code possible!

odeSD is the fastest ODE+sensitivity solver available to date for stiff problems (for non-stiff problems the performance will still be good given that the number of non-zero elements in the Jacobian scales as O(N) instead of O(N^2)). This integrator is > 2x faster than CVODES.

Sebastian

[Bob Carpenter]

I'd rather go with something a little more established. I
couldn't find anything online about odeSD other than that
paper by the authors. Do you know of independent evaluations?

- Bob

> --
> You received this message because you are subscribed to the Google Groups "stan development mailing list" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to stan-dev+u...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

[Sebastian Weber]

Hi Bob!

I see your point, sure. But from this perspective there is no way around CVODES which requires installation to be bullet proof (where I got quite far I think, i.e. I tested my routine on Windows / Mac / Linux with g++ / clang++ / icpc).

I have been in contact with others who used odeSD in their projects and did only hear good things about it. Moreover, one of the odeSD co-authors is very motivated to make odeSD header only C++, specifically Lukas is currently in the process of replacing the BLAS calls with calls to Eigen (Lukas worked with BLAS and with Eigen so he is the perfect guy to do this)! Once that is done, then odeSD is fully header only with dependencies which are already fulfilled by Stans dependencies.

So life is a compromise here... and BTW, the LSODA C implementation isn´t evaluated in any peer-reviewed journal I am aware of; only the Fortran version in ODEPACK is, but this one is not up for discussion.

Sebastian

[Bob Carpenter]

We're not making anything bullet proof. If we wanted
real robustness, we'd be much much more conservative in
what we rolled out!

I don't trust peer review for math or stats, much less
software. I am much more trusting of unit tests and an
installed user base.

I also worry that LGPL will be a deal breaker for industrialists
and other software packages who are allergic to all things GPL.
I know, I know --- LGPL is supposed to be a friendly GPL, but
it's still super restrictive compared to BSD.

We simply don't have the resources to make pieces of Stan optional
in the compile (allowing users to pick and choose dependencies).
Compiling across platforms and interfaces and compiler versions is
sucking up way too much time as is.

I'm also worried about committing us to doing something on a deadline
that's based on software that's not even finished yet.

- Bob

[Joshua N Pritikin]

On Mon, Oct 12, 2015 at 04:53:05PM -0400, Bob Carpenter wrote:
> I also worry that LGPL will be a deal breaker for industrialists
> and other software packages who are allergic to all things GPL.
> I know, I know --- LGPL is supposed to be a friendly GPL, but
> it's still super restrictive compared to BSD.

So you want to invite industrialists to take the code and re-package it
as proprietary?

If you're a developer then I don't understand the attraction of a
BSD-style license. Open source does not obtain free software.

--
Joshua N. Pritikin
Department of Psychology
University of Virginia
485 McCormick Rd, Gilmer Hall Room 102
Charlottesville, VA 22904
http://people.virginia.edu/~jnp3bc

[Bob Carpenter]

I understand and appreciate the GPL's intent.

I want the maximum number of users and the prejudice only
goes one way. We run into lots of people who won't (usually
because of corporate policy) use GPL code, but will use BSD
code. We've never run into the opposite case.

I suppose someone who's all in with GPL wouldn't contribute
to a BSD project because it doesn't have the GPL's copyleft
protections.

- Bob

[Marcus Brubaker]

I don't really want to get into a GPL vs BSD argument (mostly because I don't really care either way) but it is very arbitrary to say that Stan shouldn't use LGPL libraries.  The reason is simple, *Stan already uses LGPL libraries*. glibc is LGPL, libstdc++ is actually GPL with an added clause. In fact, on Linux at least, the vast majority of libraries (system or otherwise) are LGPL or something similar.  Using an LGPL library does nothing to the licensing of Stan, or Stan-derived programs.

If a company can't tell the difference between LGPL and GPL then maybe they need a new lawyer and perhaps should reconsidering doing software development at all...

[Bob Carpenter]

Good point about libstdc++. And that has to be a runtime
linkage thing, unlike the compiler itself.

It's easy for a lawyer to say "no", leading to a lot of
what are probably overly conservative decisions. Same for us.
If we don't allow LGPL (or other copyleft) code in, then we
won't get bit by copyleft. But I don't want to just make
a knee-jerk "no" decision --- I want to do what makes sense
for the users we anticipate.

I was actually asking about the LGPL because I don't know
how companies view it. We've been using Eigen since it
was LGPL3+.

Also, I got the licensing wrong for Eigen --- it's MPL2, which
they (Eigen) call a "weak copyleft" license. WTF? I thought
MPL wasn't copyleft. Here's the FAQ:

https://www.mozilla.org/en-US/MPL/2.0/FAQ/

Now I'm really boggled at why they changed from LGPL. And without
using their EIGEN_MPL2_ONLY flag, we might be allowing some residual
LGPL pieces in already (they list SimplicialCholesky, AMD ordering,
and constrained_cg).

So I guess we're already a long way down the copyleft path for
libraries.

- Bob

[Marcus Brubaker]

It's true, lawyers will be lazy and say no by default and I might have been more worried about that 10 or 20 years ago when (L)GPL was little known but I think today that's not really the issue it once was.

Cheers,

Marcus

[Joshua N Pritikin]

On Tue, Oct 13, 2015 at 03:57:59PM -0400, Bob Carpenter wrote:
> So I guess we're already a long way down the copyleft path for
> libraries.

It's an opportunity to educate about the virtues of copyleft.