Remacs: Implement a copyright assignment policy such that this could be upstreamed.
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
All 4 comments
I'm not sure but maybe a workflow via this tool would suffice?
hammerandtongs
on 16 Jul 2017
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
on 17 Jul 2017
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
on 16 Oct 2017
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
on 25 Jun 2018
Related issues
brotzeit
路
3Comments
Wilfred
路
9Comments
gorakhargosh
路
7Comments
DavidDeSimone
路
6Comments
ZelphirKaltstahl
路
4Comments
Most helpful comment
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.