Submit to GNU ELPA

[phil-s]

Hi. Thanks for this; it sounds neat.

It aims to be the foundation for a new breed of Emacs packages that understand code structurally.

TODOs
Submit to MELPA.

With the above in mind, please do consider putting this in GNU ELPA so that all package authors can use it? It would be a shame to limit its usefulness as a dependency to MELPA packages only.

[ubolonton]

I want to submit it to MELPA first, since it's easier, but eventually I'll submit to both.

[shackra]

@ubolonton why is it easier?

OH, I see why. https://git.savannah.gnu.org/cgit/emacs/elpa.git/plain/README

a package author would depend on some Emacs maintainer to push through any package to GNU ELPA, having those extra steps makes things hard indeed.

[shackra]

@ubolonton coming back to this, I did all the paper work to give the copyright assignment to the FSF so this project can be included in GNU ELPA. What about you? People that make non-trivial contributions should make their paper work so later pushing this to GNU ELPA becomes legally trivial.

[leungbk]

This seems like the kind of project that ought to be included in Emacs core once it's stabilized; the last thing Emacs needs is a deeper chasm between the OOB and the batteries-included experiences. But I've heard that the Rust toolchain is distributed under terms incompatible with Emacs' license. If that's the case, is it still eligible for Elpa?

People that make non-trivial contributions should make their paper work so later pushing this to GNU ELPA becomes legally trivial.

I heard the other day that use-package being merged into core is presently stalled because they're waiting on only a couple of people who haven't submitted their papers. So it's better to enforce this kind of thing sooner rather than later for Elpa.

[leungbk]

Putting aside the need for contributors to sign the papers, the Emacs maintainers are averse to stuff released under "pushover" licenses. This is a problem since Rust requires LLVM, which is released under one such license.

It seems to me that including this in Elpa would, at minimum, require that we develop our own clean-room + non-Rust tool for compiling the grammars, since tree-sitter-cli is written in Rust. It might also be necessary to write our own highlighting queries since we don't presently own the copyright assignment to the highlighting queries in this repo. I am not a legal expert, so I can't be sure of this. What do you think @ubolonton @shackra?

[shackra]

Putting aside the need for contributors to sign the papers, the Emacs maintainers are averse to stuff released under "pushover" licenses. This is a problem since Rust requires LLVM, which is released under one such license.

It seems to me that including this in Elpa would, at minimum, require that we develop our own clean-room + non-Rust tool for compiling the grammars, since tree-sitter-cli is written in Rust. It might also be necessary to write our own grammars since we don't presently own the copyright assignment to the grammars in this repo. I am not a legal expert, so I can't be sure of this. What do you think @ubolonton @shackra?

We aren't releasing Rust to Elpa or anything, anything compiled with Rust —or LLVM for that matter— don't inherit its licensing anymore that a piece of code compiled with GCC has.

I'm not a lawyer neither, but that's how I intuitively see it.

[leungbk]

anything compiled with Rust —or LLVM for that matter— don't inherit its licensing anymore that a piece of code compiled with GCC has.

Of the two concerns I brought up in my last post, the first one (which is what I think you were responding to here) was more of a political dispute among the maintainers than a legal dispute (which is what my second concern was, though having to write our own queries isn't necessarily that bad)---I don't disagree that LLVM-compiled stuff need not be released under the same license as LLVM itself. There shouldn't be a legal reason that the FSF cannot accept an emacs-tree-sitter that uses Rust.

I suspect that what some of the Emacs maintainers fear is that by requiring (say) LLVM in core Emacs, they are promoting software released under pushover licenses, which has the effect of indirectly helping anyone who wants to snarf LLVM code for their own proprietary software. Whenever this hypothetical Emacs exposes an LLVM-related bug, there is likely to be someone who reports it upstream and helps the LLVM project, as well as those who use its code in proprietary stuff. The FSF seems to view this as a net loss for freedom.