Clarify to contributors whether you want this to be able to be part of Emacs

[hammerandtongs]

Given Emacs already small community it would be best if you were explicit with contributors about whether you ever wanted to contribute any of this code upstream.

Ie in the contributors landing area either say -

"I haven't assigned copyright to the FSF and do not expect contributors to, so be aware this can never be part of Emacs"

or

"I've assigned copyright (or will be) to the FSF and ask contributors to do so so that we could someday think about making some of this part of Emacs"

Both Remacs and Emacs-ng didn't do the copyright assignment (which is fine) but they also failed to mention this to their contributors and potential contributors (which is not fine, as I think people deserve a simple warning).

[CeleritasCelery]

I am still undecided on if we should require FSF copyright assignment. My current feeling is to say no, but you make a good point that it should be explicit.

Do you have any idea if the GNU Emacs project would even accept adding LLVM to their build flow (it's not GPL)? Or would they ever allow inclusion of code that is MIT licensed like most rust crates are? Those seem like bigger hurdles then copyright assignment in order to get changes merged.

[hammerandtongs]

I don't think the copyright assignment is that viral.

It comes down to the code that ships as part of emacs ie in the emacs repository.

Dependencies need to be gpl compatible but not copyright assigned. That's my understanding but maybe you should ask on the mailing list.

https://www.gnu.org/licenses/why-assign.en.html

I'm not ideological about it, it's just a legal thing that the FSF has been doing for a long time (why argue?). They want legal standing to be able to put the code under the GPL4 or sue someone for violating the emacs gpl codebase (only the copyright holders can sue, users have no standing to sue).

---

By not assigning copyright you are excluding people that are already active contributors to emacs (whether you think of it or not), why would people already contributing to emacs not just contribute some rust something to a mailing list emacs project instead of rune (which can then never give back to core emacs)?

The remacs and the emacs-ng made the bet that their contributor pool would be large enough to sustain the project based on people completely unwilling to assign copyright (but actually just never told people).

I think the emacs maintainers that are rust curious are far more valuable potential contributors than the rust programmers that are emacs curious but refuse to assume copyright?

Despite all the work they put in, emacs-ng and remacs are proof of that.

Very cool project btw, look forward to seeing it mature.

[CeleritasCelery]

FWIW, I asked on the Emacs mailing list about this question a while back. The answer was better then I expected. Using libraries with other licenses is okay so long as they are GPL compatible. I don't even think using a non-GPL compiler (LLVM) would be an issue. It seemed like the biggest issue was LLVM not supporting old platforms like MS-DOS.

By not assigning copyright you are excluding people that are already active contributors to emacs (whether you think of it or not)

I don't believe this is true. People that have assigned copyright to FSF (such as myself) are still free to work on non FSF projects (including proprietary code and other open source work). It is not either or.

I am personally ambivalent about copyright assignment. I will probably wait until I have meaningful contributors before making a decision. If other contributors are okay with copyright assignment, then I will implement it. But I am not willing to loose contributors over this issue. I think the odds of GNU Emacs using code from this project is very unlikely.

[shaleh]

I think the odds of GNU Emacs using code from this project is very unlikely.

remacs tried to port C logic because elisp is a weird beast and without being bug compatible I am not sure how we get to a point where emacs COULD transition. Better to be more like XEmacs and provide alternatives.

The burden of turning away developers who are unwilling to assign copyright is also a thing. Pros and cons. I definitely would not argue either way.

[CeleritasCelery]

remacs tried to port C logic because elisp is a weird beast and without being bug compatible I am not sure how we get to a point where emacs COULD transition. Better to be more like XEmacs and provide alternatives.

You don't think being bug compatible would be worthwhile? I would think that would be the only way to reuse the bulk of existing elisp.