Implement a copyright assignment policy such that this could be upstreamed.

[hammerandtongs]

https://www.gnu.org/software/emacs/manual/html_node/emacs/Copyright-Assignment.html

Whether or not this project would ever be upstreamed it would seem like a mistake not to plan for it at this stage.

[hammerandtongs]

I'm not sure but maybe a workflow via this tool would suffice?

https://www.clahub.com/

[hammerandtongs]

I'm not sure but maybe a workflow via this tool would suffice?

https://www.clahub.com/

[Wilfred]

Being inclusive is an important goal for Remacs.

Copyright assignment is a significant hurdle to contribution. All our code is under GPLv3, so we're fully Free Software, but we benefit from people dropping by with small patches (even if they're >15 lines of code).

Remacs is in a great position to explore different workflows, and this is an important way that we differ from GNU Emacs.

Plenty of contributors do have copyright assignment to the FSF, myself included. We do upstream relevant elisp patches. We want to make Emacsen better and more accessible to everyone!

[Wilfred]

Being inclusive is an important goal for Remacs.

Copyright assignment is a significant hurdle to contribution. All our code is under GPLv3, so we're fully Free Software, but we benefit from people dropping by with small patches (even if they're >15 lines of code).

Remacs is in a great position to explore different workflows, and this is an important way that we differ from GNU Emacs.

Plenty of contributors do have copyright assignment to the FSF, myself included. We do upstream relevant elisp patches. We want to make Emacsen better and more accessible to everyone!

[alphapapa]

I think this decision should be reconsidered. If one of the goals of Remacs is actually to provide for the long-term future of Emacs, on the assumption that the core C-language devs will retire without replacements, then it is very important that Remacs could be adopted by the FSF.

If Remacs can't take Emacs's place under the FSF umbrella in the future, it could end up being a "real" fork, which would likely lead to incompatibilities down the line. And if that happened, it would likely split the community, and that could actually be harmful to Emacs/Remacs's future as a whole.

Emacs will surely face more competition from other projects in the future, not less, so I think it's important to plan ahead so that the Emacs/Remacs efforts could be consolidated someday. I appreciate your work on this, as it has a lot of potential, both technically and in attracting new users and developers. I would hate to see it held back by gradual divergence, leading to users having to eventually make a tough decision someday. As an Emacs package developer, I would not want to see another XEmacs/Emacs-type split with minor incompatibilities (e.g. Org mode has a lot of old code for XEmacs support; let's not do that again!).

Thanks for your consideration.

[alphapapa]

I think this decision should be reconsidered. If one of the goals of Remacs is actually to provide for the long-term future of Emacs, on the assumption that the core C-language devs will retire without replacements, then it is very important that Remacs could be adopted by the FSF.

If Remacs can't take Emacs's place under the FSF umbrella in the future, it could end up being a "real" fork, which would likely lead to incompatibilities down the line. And if that happened, it would likely split the community, and that could actually be harmful to Emacs/Remacs's future as a whole.

Emacs will surely face more competition from other projects in the future, not less, so I think it's important to plan ahead so that the Emacs/Remacs efforts could be consolidated someday. I appreciate your work on this, as it has a lot of potential, both technically and in attracting new users and developers. I would hate to see it held back by gradual divergence, leading to users having to eventually make a tough decision someday. As an Emacs package developer, I would not want to see another XEmacs/Emacs-type split with minor incompatibilities (e.g. Org mode has a lot of old code for XEmacs support; let's not do that again!).

Thanks for your consideration.

[vermiculus]

I would add my voice to this -- I also do not want to see another XEmacs/Emacs split. Emacs should always be GNU Emacs -- and GNU Emacs should (IMO) move to Rust. That will be legally difficult if an existing Rust implementation is not assignable since it will be risky -- if not impossible -- for the FSF to say 'we definitely didn't use that code'.

[vermiculus]

I would add my voice to this -- I also do not want to see another XEmacs/Emacs split. Emacs should always be GNU Emacs -- and GNU Emacs should (IMO) move to Rust. That will be legally difficult if an existing Rust implementation is not assignable since it will be risky -- if not impossible -- for the FSF to say 'we definitely didn't use that code'.