I’ve recently been working on updating the various syntax highlighters for Stan. One of the more important ones is GitHub - jrnold/atom-language-stan, since this is what is used by Github itself to highlight Stan code. It has not been updated since Stan 2.19, and the author is inactive.
I would like to fork this repo under the stan-dev Github organization. It is MIT licensed and requires almost no maintenance, but especially since it is used by Github it would be great to be able to keep it as up to date as possible.
Just curious, did you reach out to Jeffrey? He might transfer the repo if you asked (and the SGB wanted it to happen). I’m happy to reach out to him if you need.
Is he on discourse? @jrnold?
Regarding SGB, the current repo is MIT licensed.
I think that we stan-dev repo are preferred to be BSD-3-Clause License.
That would be the only problem.
EDIT: a Treesitter stan grammar should be awesome also :)
My 2 cents is that the license is more important in case we envision others building tools around some code in a stan-dev repository. And in that case, we want to have a permissive license to not restrict how the users can use that code and distribute their tools/software/whatever. We want that code to get around and be used by as wide a range of users as possible.
In the case of language definitions, I don’t really see this use-case being a big thing. This repo is/will be consumed by a few of the syntax highlighters that already use it and thus seem to not have any issues wrt the license.
I don’t have the experience Bob has, so definitely would like to hear from him.
This is really two questions. First, licenses on GitHub are by repo, not by organization, so it’s no problem using multiple licenses under stan-dev. Second, the MIT license is very flexible and compatible with both BSD and with GPL. That means we could fork the MIT licensed repo, preserve its copyright notice, and then have the choice to release the entire package under BSD with new contributions being made under the BSD license. This is precisely why you give your code flexible licenses—to make it easier for other people to use legally.
Other than the AGPL (the most restrictive of the GPL licenses), the licenses grant someone the ability to redistribute the licensed code. So it’s mainly about people who want to extend it and then redistribute it. The MIT license is compatible with GPL and with BSD, so anyone would be able to do pretty much what they want with it.
My feeling is that it’ll be easiest and least confusing for downstream users or devs if we just fork it and maintain the MIT license.
Ok, then. I am also in favor of this one. But let’s wait a couple of days for @jrnold to reply. Also if anyone is opposed to this please feel free to express your opinion.