Choosing the new Stan compiler's implementation language


When designing user experiences don’t think of yourself but think of your target user. The typical user that we’re catering to with CRAN and the like will not find changing the mirror easy; it will not be “that’s it”. Same with changing paths, modifying hidden configuration files, and the like.


Sure, I was suggesting to you to provide instructions to your audience during (or before) the course. Of course, users won’t think of that as a start… but I think what I suggest is as easy as

R> install.packages("rstan", repos="")

which will install rstan using today’s snapshot of CRAN (and tomorrow this link will install the same stuff again).


That’s because we have been avoiding using things past C++1y. I think that’s mostly a lot of better auto/templating for lambdas.

I thought RStudio was AGPL. Is there something in the binary that requires extra permissions beyond the license under which the source is distributed?

In some of the error handling and output checking, yes, but some of the inputs to the services are things like a model, which means they already contain data. And nothing in the services determines the names given to arguments in R or command line or elsewhere.

In your language, we’re refactoring the parser code (i.e., not changing the language or parser behavior and relying on a large suite of current tests). The technical way we’re doing that is rewriting the parser, AST, and code generator from scratch. By the way, Fowler’s Refactoring book is one of my faves!

The sense in which our new project is like the move from gcc to clang is that we’re not replacing the language (for them, C++, for us, Stan), but we are replacing the implementation.

BUGS to JAGS and Python 2.0 to 3.0 are more similar to each other than what we’re doing.

The move from Stan 2 to Stan 3 (the bigger project, not the parser rebuild) will be somewhat like Python 2 to Python 3 in that we’ll be turning off most of what’s currently deprecated. Anyway, just loose analogies to think about.


Trademarks. c.f.

  • Use of RStudio trademarks in connection with the provision of a public website that makes RStudio products available for download (rather than directing users to the official RStudio product download site).
  • Use of RStudio trademarks in connection with RStudio products bundled with other software.
  • Use of RStudio trademarks in connection with publicly hosted versions of RStudio products.

This is the primary reason why I didn’t try for this previously. However, the good news is that I have obtained preliminary permission as of yesterday to release an all-in-one installer w/ RStudio.


If I am understanding you correctly, that is not correct. For the gcc column of
it lists

  • Generic (polymorphic) lambda expressions
  • Initialized/Generalized lambda captures (init-capture)
  • decltype(auto), Return type deduction for normal functions

under things that were implemented as of g++-4.9 (and a few more that seem less relevant to me).

So, we could use those now — and are using some of those in the unit tests — but are not. Of the things that are only implemented in g+±5, the one that seems most useful is “Extended constexpr” but the constexpr in C++11 is not that bad, and I think was being used on one of the PRs for complex numbers.


They consider redistributing RStudio software a use of their trademark? Is that only if you put their trademark up on your web? Or is it that you can’t say that the distribution has RStudio in it?

That’s certainly was not our intention in registering trademarks for Stan and our logo.

When did giving things away get so hard legally?


There’s a lot that’s evolving around typing and const(expr)ness with the lambdas. I agree there’s a lot we can do with what’s in C++1y already.


Did you consider going through brew rather than making a standalone installer? I would’ve thought that a natural option since I always used brew to set up the environment for Stan but I haven’t had a Mac for a few years now so idk.


@sakrejda multiple times. The issue is there is a disconnect between those using the tools and setting them up. Many of the Statisticians I’ve come into contact with do not have an extensive shell/CLI background. As I alluded to earlier, macOS users are expected to understand sys-admin level concepts when they were drawn to the platform for the exact opposite reason (“everything works”). I toyed with making the installer just a shell script. But, the way brew cask works isn’t ideal. It’s much easier to forgo that process and bundle individual installers together.


@Bob_Carpenter I’m not a lawyer. I err on the side of extreme caution related to IP matters. I would ask these questions to RStudio directly.

In the interim, we’re going to go ahead with wrapping the installer. As Stan hasn’t explicitly laid out any trademark terms (c.f. and given your remarks, I assume that included it as a default package would be okay?


We (the Stan Governing Body) are in the process of working out the details here. We are broadly committed to people being able to use and distribute the Stan software under the relatively unrestricted terms of its licence.

My understanding of what the trademark is for is that while people can use, derive from, distribute, and profit from the Stan software, we don’t want them to be able to say “this is Stan” or in any way imply that something is an intial Stan package if it isn’t.

We are working on some more concrete policies for things like “powered by Stan” logos, but right now if you need something the best way is to email us ( We will do our best to make the process as smooth and straightforward as possible!


This is really a fundamental tension we’re wrestling with for all of our installs. Stan requires users to become developer-level installers in order to get their C++ toolchain all hooked together. It shouldn’t be this hard, but the combination of PATH issues, R’s makevars files that many users can’t even figure out how to open and edit, Apple’s moving things around willy nilly, and nothing ever working on Windows, it’s been rough.

Did you ask or just assume you needed permission? I can ask them what their intention is.

One link deeper you get to the Stan logo use guidelines which again don’t seem particularly clear to me as a non-lawyer. We certainly didn’t mean to restrict the distribution of the manual or the software. We just didn’t want people to write “powered by Stan” on their software for advertising without our permission or to imply that courses they were giving were sanctioned by the Stan project. I’m glad that’s consistent with Dan Simpson’s comment; thanks for commenting, Dan.


Thanks for the clarification. I’ll try to send an e-mail over later today.

Again, with anything related to IP rights, I assumed that I needed permission. This was why I opted against initially working on bundling and focusing more of my efforts on being able to deploy a toolchain.

That said, when I was brought into this thread, I reached out to RStudio last week and got the clarification as given above. Thus, I received preliminary permission to bundle RStudio’s IDE with R, a Developer Toolchain, and a set of packages.


In the interim folks, I’ve setup a GitHub org to house the macOS projects:

Where the r-macos-rtools installer is failing for users presently is on the CLI installation:

xcode-select --install

This is due to a path issues on Mojave.

sudo xcode-select --reset
sudo xcode-select --install


It depends on what the license is. For instance, Stan’s code is clearly BSD licensed. You can do anything you want with it allowed by the terms of that license. That’s more of an issue for a lawyer than for us if you want to be super safe.

Great. They seem like a very reasonable group of people.

Going forward, we are going to want to put a lot more emphasis on installer packages like the one you’re managing. We probably won’t get around to this for six months or so, but if you need help with the package you’re working on, please ask! We want to support you working on this.

Speaking of IP, I saw the r-macos-rtools was distributed under the GPL (version 2 or higher, which has always seemed overly trusting of GNU to me—who knows what’ll be in v4?). You can only do that if you have permission for all of the components you distribute to be GPL-ed. For example, we distribute Boost and Eigen with Stan, so we can’t just make the whole thing BSD. The Stan component is BSD, but Boost and Eigen have their own licenses, and we need to distribute them with those licenses. I see that you have other licenses nested, so you might just want to clarify on the outside that the distribution isn’t 100% GPL. We need to do a bit better job of this on Stan, too.


Before we begin, licensing is a tricky business. I’m not a lawyer, nor do I claim to ever want to be. I try my best to ensure that all licensing guidelines are followed appropriately. In the evident that they are not, I’m more than happy to modify terms. That said, everyone has a preference with licenses. I primarily want to make everything as public as possible.

Actually, that isn’t accurate. I’m going to quote the GPL FAQ as it relates to separate works and how they can be aggregated:

Q: What is the difference between an “aggregate” and other kinds of “modified versions”? (#MereAggregation)

A: An “aggregate” consists of a number of separate programs, distributed together on the same CD-ROM or other media. The GPL permits you to create and distribute an aggregate, even when the licenses of the other software are nonfree or GPL-incompatible. The only condition is that you cannot release the aggregate under a license that prohibits users from exercising rights that each program’s individual license would grant them.

The emphasis here is mine. In particular, the user-facing portion of the installer only emphasizes the works’ licenses (e.g. how the software installed is to be used). I’m allowed to license how the underlying code that unites the different modules using GPL. In contrast, if the program uses a GPL library (via linking against it), then the entire work must be released under GPL.

The portion you are referring to is released under an MIT license, which can be incorporated into a GPL work as long as the terms of the licenses are upheld. e.g.

“The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.”

More details on this approach can be found at the SFLC’s document for Maintaining Permissive-Licensed Files in a GPL-Licensed Project: Guidelines for Developers

Great to hear! The main portion I’ll need help with in the immediate future is having someone sign an installer. At some point, I’ll likely also try to recruit volunteers to help with maintenance.


That’s pretty much my and Stan’s position. It’s just a matter of figuring out what that means. We tried to resolve one issuea bout GPL like this by consulting NumFOCUS’s IP attorney. Our devs, even after clarification, could not agree on how to interpret the lawyer’s opinion. We finally gave up and took the most conservative possible route.

Let’s try to get to something more accurate. I realize that you can distribute other packages with GPL-ed code if their licenses are compatible. That’s what’s going on with RStan (GPL) and Stan (BSD), for example. My take on this

is that it’s saying you can distribute GPL-ed software with other software, but you can’t distribute that other software under the GPL—you have to keep it under its original license. The way I read it, RStan is GPL-ed, but the bits of Stan it contains remain BSD-ed, not GPL-ed.

This we agree on.

Is there something you’re linking against that is forcing you to use the GPL? We’re trying to move Stan products away from GPL as much as possible because so many users consider it toxic.

I think I’m just hung up on the semantic issue of whether the whole release is GPL or not.

What I’d like to make more clear with the Stan releases is the component licenses. They’re all included, as you do, but we don’t call the whole thing out. I guess what you’re saying is that’s not necessary. By saying you’re distributing under GPL, it’s understood that’s only the bits of code that aren’t under some other license.


RStan doesn’t contain any bits of Stan. StanHeaders does.


I think you are making too much of this. If A is under BSD and B is GPL but includes A, then anyone is allowed to download A from its website and do whatever with it. And anyone is allowed to download B and redistribute derivative works of B under the GPL.


This reminds me of SPDX I have seen notable projects who boil their licensing down to something along the lines of:

"All material here is released under the GNU General Public License. All material that is not executable, including all text when not executed, is also released under the Creative Commons Attribution 3.0 International (CC BY 3.0) license or later.

In SPDX terms, everything here is licensed under GPL (>= 2); if it’s not executable, including the text when extracted from code, it’s “(GPL >= 2 OR CC-BY-3.0+).”

Like almost all software today, this software depends on many other components with their own licenses. Not every component is (GPL >= 2), but all components are FLOSS. "