Licenses of dependencies

+1. For major decisions like this one that needs to go through the TWG, there should probably be a separate TWG thread?

For all developers to chime in, I don’t know of a better list than the developers category, but we could make something like an announcement category that’s separate and low traffic.

Where did this date come from?

cc: @ariddell, @ahartikainen, @mitzimorris

@seantalts suggested to wait for a week, see from above

I only made the date meant by that explicit.

1 Like

nlmixr( is under GPLv2 and uses Stan to calculate ODE Jacobian. I wonder if this change would push them away.

It shouldn’t because they do not use MCMC and they could link against the RcppParallel package like RStan will do, but I should check with them that they only #include the right stuff.

They do have

isn’t this where TBB would be going to?

1 Like

As I understood things, then even nlmixr is fine. The reason is that the users will put together the final binary thing - which is fine since still no unitary binary would be distributed. This is how I understand it.

(and I can actually ask Matt Fiddler, the author of nlmix to bump to GPLv3; Matt is a colleague of mine)

EDIT: And as @seantalts writes: You cannot distribute a single binary anymore, but you can distribute the sources and let users put it together.


Thank you! I read that in @seantalts’s post, but didn’t put 2 and 2 together. (@seantalts, could you be more specific and more clearly note action required in your posts? That was buried far down in that comment and having a clear date is better than just “the next week.”)

Just so we’re on the same page, for the Math library, we’re ok including Apache 2 licensed dependencies, but we’re being careful so that we’re not leaving pitfalls for things that depend on Math.

  • we can continue to license Math as BSD even if it has a Apache 2 dependency
  • we can distribute an Apache 2 library as source
  • we can not and do not want to distribute an Apache 2 library that’s built as a binary

For any GPLv2-licensed code, it has to be careful not to distribute an executable that has the Math library that’s been compiled into it once we introduce an Apache 2 license dependency. But for BSD and GPLv3 this is fine. I take it MIT license (Prophet) it’s also ok. Is that right?

I actually said it twice and ended with a call to action,


I don’t think discourse allows me to change font size but if it helps I can bold things like that in the future.

[edit] I edited my post above to give the date implied by “in the next week.”

Yes, we’re only incompatible with being distributed with GPLv2 licenses as a single work. I think that is possibly a unique property of GPLv2.

Yes, bold definitely helps! And font size is controllable a little bit. Markdown headers (#) work.

1 Like

Went to add bolding. Thanks!

1 Like

My spidy sense says that this back and forth is getting a bit strained.

We have a decision before us, I am prepared to FedEx anyone not already aware of this issue a memo to please check in. Send me an email with coordinates, horse dispatch available…email:

I will offer my usual deadline strategy, midnight anywhere on the planet Sept 14th. That means 6am roughly in New York City on the 15th. I think that should work.


I think the magnitude of this change warrants enough notification. This change has the potential to affect downstream projects that have licensed themselves as GPLv2. Currently, all these packages are safe to do what they want with Stan, but after Stan starts depending on an Apache 2-licensed dependency, these packages won’t be able to distribute a pre-compiled Stan program as part of their package and leave their licensing as GPLv2. (Yes, that’s a lot of conditions that need to be met, but it is a change and we would be forcing action on developers.)

As an example, if someone were to do something like rstanarm but with cmdstanpy AND it was licensed GPLv2, that package would be licensed improperly; this is fine to do without Math depending on Apache 2.

These are the RStan packages that are listed in the “reverse depends” section that are licensed GPLv2:

I’m just bringing this up because there exist multiple open-source packages that are licensed as GPLv2 and we’re making a change that could affect these packages.

We’re not responsible for the legality of anything outside of Stan, but we should still be courteous to members of the community when there’s a big change like this. My only request is that we make a new thread so the information is easy to digest and there’s a clearer call to action for those that actually want to make a statement. I’m guessing we’ll have 0 responses, but I’d rather give an opportunity than have the start of the decision-making process happen ~50 posts into a thread that doesn’t indicate that changing dependencies may have a lasting effect.

@breckbaldwin, if you still feel the way you do, that’s fine. I’ll find emails of all the GPLv2 packages that depend on Stan and ask that you contact them directly.

clinDR, CopulaDTA, DAMisc, GPRMortality, HCT, and JMbayes compile Stan programs at runtime, so it is fine for them to be GPL2.

evidence just calls rstanarm at runtime and doesn’t have any of its own Stan code.

walker comes with Stan code that gets compiled by CRAN for Windows and Mac and its license is GPL2 or GPL3, so it would be affected by the proposed change.

In general, we need to be looking at the Reverse Linking To section of StanHeaders rather than RStan because (most of) those come with compiled Stan models. nlmixr and openMx don’t but openMx is already Apache2 and Sebastian is going to talk to nlmixr.

1 Like

Thank you for the clarification! What’s reasonable for notification to R package maintainers?

I would think a GitHub issue or if not on GitHub an email.

Lets try and do this as clearly and transparently as possible to the larger community as well as our own community. Steps I am going to try:

  1. We have a decision that we are pretty sure we want to make, allow an Apache 2 library dependency into math.
  2. I’ll classify the legal question as in the “no brainer but there may be unforeseen consequences that could be heavy” category which merits a ‘trip wire’ consensus process.
  3. The ‘trip wire’ merely means that we tell everyone we can think of about what we want to do, see if anyone raises a valid objection in a fixed time window, if not then adopt the decision.
  4. If the ‘trip wire’ gets tripped, then we have a vote after a week of discussion or the proposer can modify/withdraw. This portion likely needs refinement.

So 1) and 2) have happened, now we do 3). I have posted a new thread (Apache 2 library inclusion into Stan Math--general policy case. Trip wire consensus decision) with what I think the proposal is and send around to various downstream projects for input.



Thank you!

The week has passed and no one objected. We’re now able to include Apache 2 licenses in Stan :)

Thank you everyone for your collaboration on this! Especially @bgoodri and @breckbaldwin for getting the word out to the downstream folks.

1 Like