Choosing the new Stan compiler's implementation language

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.

3 Likes

@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. Stan - About Us) 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 (board@mc-stan.org). 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
2 Likes

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.

1 Like

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 https://spdx.org/spdx-license-list/license-list-overview. 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. "

Probably. I just want to make sure we’re doing the right thing.

Sure, anything consistent with the BSD. That means keeping the original license. What you can’t do is download A, then redistribute it under a different license, such as GPL.

Right. As long as A keeps its BSD license.

My only concern is what we should put at the top level to describe A. Should we just say that A is GPL-ed or should we say A is GPL-ed but it relies on components under other licenses compatible with GPL. Exactly what @increasechief points out here:

I had to look up the “L” there—it’s just “free” in another language (“libre”). Seems redundant to me.

We can’t quite do this because our logos aren’t consistent with CC BY, but this is pretty much what we say now.

1 Like

Folks, can we move the discussion of an all-in-one installer outside of the compiler implementation language thread? I feel like it is getting off track very fast.

I think we can close this discussion altogether as we’ve decided to go with OCaml.

2 Likes

No worries. No discussion’s ever truly closed with open-source software.

An implementation already exists in Haskell: https://github.com/diffusionkinetics/open/blob/master/stanhs/lib/Stan/AST.hs

This was presented at StanCon 2018: https://glutamate.github.io/stancon/stancon.html

If you are thinking of OCaml, why not Haskell?