Emacs and Magit(lwn.net)
lwn.net
Emacs and Magit
https://lwn.net/Articles/727550/
179 comments
FSF assignments have had full digital support in every country and very fast since 11/2016. https://www.fsf.org/blogs/licensing/fsf-now-offering-paperle...
Sad to see this outdated info in the top comment.
Sad to see this outdated info in the top comment.
> With the advice of counsel, we can begin accepting scanned copies of assignments from all contributors, regardless of where they reside. With a small update to our assignment contract, we can finally make it possible for all contributors to avoid having to send their forms via the post.
Uhh, having to scan a printed and signed document is not much better than having to use snail mail.
When I see "full digital support" I understand that to mean I can use just a computer.
Many other projects accept a digital signature (basically filling out a form -- in a browser). Why isn't that sufficient for the FSF?
Uhh, having to scan a printed and signed document is not much better than having to use snail mail.
When I see "full digital support" I understand that to mean I can use just a computer.
Many other projects accept a digital signature (basically filling out a form -- in a browser). Why isn't that sufficient for the FSF?
FWIW: the term in the industry for that is "electronic signature". "Digital" signatures usually refer to crypto.
And one reason for worry, historically, is that international law for paperless/signatureless contract enforcement is sort of a mess. Wikipedia has a page here with links to various nations and their requirements: https://en.wikipedia.org/wiki/Electronic_signatures_and_law
Not a lawyer nor speaking for the FSF. But it seems not entirely unreasonable to me that a conservative approach to copyright assignment would have picked the path they chose. It's just a hard problem.
If you want to ding the FSF, ding them on the copyright assignment requirement. Whining about the process seems a little too much to me.
And one reason for worry, historically, is that international law for paperless/signatureless contract enforcement is sort of a mess. Wikipedia has a page here with links to various nations and their requirements: https://en.wikipedia.org/wiki/Electronic_signatures_and_law
Not a lawyer nor speaking for the FSF. But it seems not entirely unreasonable to me that a conservative approach to copyright assignment would have picked the path they chose. It's just a hard problem.
If you want to ding the FSF, ding them on the copyright assignment requirement. Whining about the process seems a little too much to me.
Good god, if you don't care about the project enough to not sign a piece of paper and scan it, just don't contribute to it. FSF has programmers and lawyers alike that are also working to further computing freedom, I don't believe they are imposing this paperwork for messing around.
> Good god, if you don't care about the project enough to not sign a piece of paper and scan it.
Wouldn't it make more sense to sign an agreement form with one's GPG private key rather than having to show a physical signature?
Wouldn't it make more sense to sign an agreement form with one's GPG private key rather than having to show a physical signature?
Lawyers and judges don't understand GPG. Your silly hacker shenanigans don't hold up in court. Or maybe they will, but it's a gamble.
Yes, it's a creaky, old system, but that's how it works: with paper and signatures and old, wrinkly men sitting on benches deciding your fate based on their incomplete understanding of modern technology.
Yes, it's a creaky, old system, but that's how it works: with paper and signatures and old, wrinkly men sitting on benches deciding your fate based on their incomplete understanding of modern technology.
> Lawyers and judges don't understand GPG.
As I mentioned in another comment, having an expert witness testify about public/private keys, PKI, "Web of Trust" should be sufficient in court.
Alternatively, passing legislation that gives a digital signature prima facie status in court would work as well.
As I mentioned in another comment, having an expert witness testify about public/private keys, PKI, "Web of Trust" should be sufficient in court.
Alternatively, passing legislation that gives a digital signature prima facie status in court would work as well.
> Alternatively, passing legislation that gives a digital signature prima facie status in court would work as well.
All US jurisdictions already have such laws (in virtually all states, the same law—UETA—has been adopted, and E-SIGN is the federal law.)
Foreign jurisdictions may or may not have laws with similar effect, though I suspect they are pretty common by now, at least in the developed world.
All US jurisdictions already have such laws (in virtually all states, the same law—UETA—has been adopted, and E-SIGN is the federal law.)
Foreign jurisdictions may or may not have laws with similar effect, though I suspect they are pretty common by now, at least in the developed world.
There's a difference between "electronic signatures" and "digital signatures" [1]. I was referring to digital signatures, but, from what I've read and understand, the laws you cite refer to electronic signatures.
[1] https://www.assuresign.com/electronic-signatures-vs-digital-...
[1] https://www.assuresign.com/electronic-signatures-vs-digital-...
Digital sigbatures and electronic signatures are, to be sure, different things (you can digitally sign something without, for instance, any capture of intent to be a legal signsture) but, digital signatures are also a means of achieving a valid electronic signature as defined in those laws.
Obviously, people selling centralized document storage and electronic signature services are incentivized to obfuscate this as much as possible.
Obviously, people selling centralized document storage and electronic signature services are incentivized to obfuscate this as much as possible.
For some reason, I don't see a reply link for your most recent post [1].
> I didn't assert that case law made digital signatures equivalent to electronic signatures
You're correct; I didn't read your original response carefully enough. Also, the comment [2] that stated that the FSF does indeed allow for digital signatures (in the US at least) definitely settles the issues and answers my original question.
[1] https://news.ycombinator.com/item?id=14824452)
[2] https://news.ycombinator.com/item?id=14823665
> I didn't assert that case law made digital signatures equivalent to electronic signatures
You're correct; I didn't read your original response carefully enough. Also, the comment [2] that stated that the FSF does indeed allow for digital signatures (in the US at least) definitely settles the issues and answers my original question.
[1] https://news.ycombinator.com/item?id=14824452)
[2] https://news.ycombinator.com/item?id=14823665
> digital signatures are also a means of achieving a valid electronic signature as defined in those laws.
If that's the case, then why does the FSF require scanning a printout with a physical signature (as one commenter mentioned) instead of opting for a digital signature of that document?
Does case law pertaining to the laws you cited support the assertion that digital signatures have the same legal meaning as an electronic or physical signature?
If that's the case, then why does the FSF require scanning a printout with a physical signature (as one commenter mentioned) instead of opting for a digital signature of that document?
Does case law pertaining to the laws you cited support the assertion that digital signatures have the same legal meaning as an electronic or physical signature?
> If that's the case, then why does the FSF require scanning a printout with a physical signature (as one commenter mentioned) instead of opting for a digital signature of that document?
I dunno, ask the FSF what their reasoning is. Among the numerous plausible explanations is that they are concerned about laws in some non-US jurisdictions, or that they haven't expended resources examining other options.
> Does case law pertaining to the laws you cited support the assertion that digital signatures have the same legal meaning as an electronic or physical signature?
I didn't assert that case law made digital signatures equivalent to electronic signatures (in fact, I explicitly pointed to one way in which it is possible for a digital signature to fail to meet the similar requirements in UETA and E-SIGN for an electronic signature.)
I dunno, ask the FSF what their reasoning is. Among the numerous plausible explanations is that they are concerned about laws in some non-US jurisdictions, or that they haven't expended resources examining other options.
> Does case law pertaining to the laws you cited support the assertion that digital signatures have the same legal meaning as an electronic or physical signature?
I didn't assert that case law made digital signatures equivalent to electronic signatures (in fact, I explicitly pointed to one way in which it is possible for a digital signature to fail to meet the similar requirements in UETA and E-SIGN for an electronic signature.)
Passing legislation or bringing in expert witnesses (and risk having their testimony being questioned) are all harder than just appeasing the old, wrinkly guys sitting on the benches.
> Lawyers and judges don't understand GPG. Your silly hacker shenanigans don't hold up in court.
Presumably, lawyers and judges will understand state (notably, UETA, in all but three states) and federal laws (notably, E-SIGN) governing the use and validity of electronic signatures.
Presumably, lawyers and judges will understand state (notably, UETA, in all but three states) and federal laws (notably, E-SIGN) governing the use and validity of electronic signatures.
> Presumably,
Are you erring on the side of legal caution? 'Cause I assure you the FSF is.
Are you erring on the side of legal caution? 'Cause I assure you the FSF is.
This has been available for contributors in the United States for some years now, and I've used it to sign the assignment documents in the past. It might not be available in all countries though.
> If you use GPG, you can sign your assignment using a detached signature in the following manner:
> gpg -a --detach-sig ASSIGNMENT
> Where ASSIGNMENT is the PDF file(s) as you have received it from us.
> Then simply email the assignment, key ID, and signature file back to us at [email protected]. Please make sure that your key is listed on a public keyserver.
> If you use GPG, you can sign your assignment using a detached signature in the following manner:
> gpg -a --detach-sig ASSIGNMENT
> Where ASSIGNMENT is the PDF file(s) as you have received it from us.
> Then simply email the assignment, key ID, and signature file back to us at [email protected]. Please make sure that your key is listed on a public keyserver.
I'm actually surprised that no one mentioned this sooner. It's too bad that this isn't an option for most other legal documents that one has to submit in a lot of situations.
Well played, sir. Given the nature of FSF's business you'd think they'd be on the cutting edge of digital identification and authentication. GPG keys a thousand times better at properly identifying an owner than an easily forged pen-and-paper signature.
For that matter, why not have a blockchain assignment process? Given what a vanguard for technology FSF used to be it's a shame to watch it devolve at the pace of bureaucracy.
For that matter, why not have a blockchain assignment process? Given what a vanguard for technology FSF used to be it's a shame to watch it devolve at the pace of bureaucracy.
> Given the nature of FSF's business you'd think they'd be on the cutting edge of digital identification and authentication.
The FSF is very careful about the legal system. Signed paper contracts are a robust legal technology. When something important happens, they don't want a judge to be distracted by unfamiliar things.
edit: they also have digital signing in a couple of different forms.
https://www.fsf.org/blogs/licensing/fsf-now-offering-paperle...
The FSF is very careful about the legal system. Signed paper contracts are a robust legal technology. When something important happens, they don't want a judge to be distracted by unfamiliar things.
edit: they also have digital signing in a couple of different forms.
https://www.fsf.org/blogs/licensing/fsf-now-offering-paperle...
Would that be valid in a court? Because I believe that's where these papers are going to be used at.
It would be a matter of checking if there's any judicial precedent for digital signatures. If not, then an expert witness explaining the principles behind public/private keys, PKIs (how they're used in industry to verify the authenticity of servers), and how it compares to the "web of trust" model in terms of verifying authenticity and how it applies to FSF contributors.
These days whenever I'm asked to print, sign, and scan a form I now just use OSX Preview to insert my digital signature, save it, and send it back. (I have no idea if there are legal issues with this but nobody's ever complained to me that this isn't okay.)
I still hate when I'm asked to do this but it's vastly more convenient than actually printing and scanning a form.
I still hate when I'm asked to do this but it's vastly more convenient than actually printing and scanning a form.
I've done this using Inkscape a few times, usually works but I've had one company come back to me saying "uh no, print it out". They were in finance so maybe a regulatory thing or maybe just luck.
This is a legit/acknowledged way to meet the FSF's requirements.
For what it's worth, I do all my "scanning" with my phone camera these days. There are various apps that can even make it look like a traditionally scanned document in addition to converting it to PDF.
> If it were part of Emacs you'd need to use the FSF's collaboration tools which have a higher barrier of entry,
No, we would continue to use Github for the foreseeable future. If a FSF hosted Gitlab/Gitea/... instance came to be, then we would likely switch to that.
Also I am not exactly a fan of either the git forge or the mailing list work-flow. So I plan to add "competitive collaboration tools" to Magit that allow a project to continue to use either back-end while also allowing all or some contributors to use collaboration work-flows that are more tightly integrated with the development and version-control work-flows. https://github.com/magit/magit/issues/2972
The primary downsides of assigning copyright to the FSF that I see is the "waiting for papers to be signed" part and that some potential contributors will no longer be able to / be willing to contribute.
No, we would continue to use Github for the foreseeable future. If a FSF hosted Gitlab/Gitea/... instance came to be, then we would likely switch to that.
Also I am not exactly a fan of either the git forge or the mailing list work-flow. So I plan to add "competitive collaboration tools" to Magit that allow a project to continue to use either back-end while also allowing all or some contributors to use collaboration work-flows that are more tightly integrated with the development and version-control work-flows. https://github.com/magit/magit/issues/2972
The primary downsides of assigning copyright to the FSF that I see is the "waiting for papers to be signed" part and that some potential contributors will no longer be able to / be willing to contribute.
Other than getting papers from contributors, are there ways in which Magit becoming part of Emacs would significantly change the development workflow?
I would probably get drawn into more lengthy discussions.
It's important to note that when Richard said that Magit should be "part of Emacs", that really meant "part of GNU Elpa and/or GNU Emacs". If Magit is just made part of Elpa (which I believe is all that Richard wants), then that doesn't change much. We get protection at the cost of the assignment overhead.
But I already wanted to add parts of Magit to Emacs itself anyway. Low-level libraries that are useful beyond Magit itself, and which would benefit from being built-in. That includes some existing ui libraries but also new libraries I intend to write to replace old abstractions used in Magit, such as a file-handler for Git blobs and trees. Magit would benefit if other Git related packages used those, instead of everyone reinventing the wheel.
Once some code is part of Emacs itself it will be more difficult to change than if it were living in a separate repository. On the bright side, that would likely motivate me to write tools to make that process less painful.
It's important to note that when Richard said that Magit should be "part of Emacs", that really meant "part of GNU Elpa and/or GNU Emacs". If Magit is just made part of Elpa (which I believe is all that Richard wants), then that doesn't change much. We get protection at the cost of the assignment overhead.
But I already wanted to add parts of Magit to Emacs itself anyway. Low-level libraries that are useful beyond Magit itself, and which would benefit from being built-in. That includes some existing ui libraries but also new libraries I intend to write to replace old abstractions used in Magit, such as a file-handler for Git blobs and trees. Magit would benefit if other Git related packages used those, instead of everyone reinventing the wheel.
Once some code is part of Emacs itself it will be more difficult to change than if it were living in a separate repository. On the bright side, that would likely motivate me to write tools to make that process less painful.
>No, we would continue to use Github for the foreseeable future.
The FSF does not consider Github to be a suitable VCS host for its projects. Gitlab has, to my memory, a rating of "good enough", but only Savannah (which the FSF hosts instances of) is truly thought of as excellent, and it's what's used for all the current projects under their control.
If Magit were to become a FSF project, it would be made to migrate.
The FSF does not consider Github to be a suitable VCS host for its projects. Gitlab has, to my memory, a rating of "good enough", but only Savannah (which the FSF hosts instances of) is truly thought of as excellent, and it's what's used for all the current projects under their control.
If Magit were to become a FSF project, it would be made to migrate.
The user you're responding to is the maintainer of Magit - I would wager he has a better idea of his hosting situation than you do.
That's a statement on the level of Turnbull's "laws of Australia". I doubt the FSF would break its own policy for a new project, especially since the principle is free software over user convenience. The maintainer might want to add proprietary dependencies to their project, but under FSF control, it wouldn't happen.
Most of the packages that are distributed using GNU Elpa (i.e. the non-built-in packages under FSF control) are developed on Github.
Can you show me an example of such a package? All the Elpa packages are hosted on a Savannah instance.
https://git.savannah.gnu.org/cgit/emacs/elpa.git/tree/packag...
https://git.savannah.gnu.org/cgit/emacs/elpa.git/tree/packag...
> Can you show me an example of such a package?
https://github.com/magnars/dash.el
> All the Elpa packages are hosted on a Savannah instance.
That's the "publishing repository". You have to push there for a new version of your package to be published on GNU Elpa. But for most packages development happens elsewhere, and in most cases "elsewhere" is Github. Emacs maintainers sometimes commit directly in the Elpa repository (and package maintainers are expected to deal with the consequences, such as "two diverging mainlines"), but development happens elsewhere.
https://github.com/magnars/dash.el
> All the Elpa packages are hosted on a Savannah instance.
That's the "publishing repository". You have to push there for a new version of your package to be published on GNU Elpa. But for most packages development happens elsewhere, and in most cases "elsewhere" is Github. Emacs maintainers sometimes commit directly in the Elpa repository (and package maintainers are expected to deal with the consequences, such as "two diverging mainlines"), but development happens elsewhere.
> Emacs maintainers sometimes commit directly in the Elpa repository (and package maintainers are expected to deal with the consequences, such as "two diverging mainlines")
Is a model like this what you mean when you say "No, we would continue to use Github for the foreseeable future"? I guess if you're doing all the legwork, it won't be overly visible to other people who want to contribute. Still though...
Is a model like this what you mean when you say "No, we would continue to use Github for the foreseeable future"? I guess if you're doing all the legwork, it won't be overly visible to other people who want to contribute. Still though...
That doesn't seem that onerous. It's just a pull and and a merge—it's what git is designed for.
Orgmode is another example.
> If it were part of Emacs you'd need to use the FSF's collaboration tools which have a higher barrier of entry
I've lost count of how many projects I've contributed to, due to how easy Github makes submitting a patch.
Contrast that to contributing to Emacs: I can't recall a single time I tried to send in a change-proposal without regretting it, seeing it fan out for weeks in endless mailing lists discussions and more often than not end up going nowhere.
If Magit ends up under FSF ownership and the Github repo is discontinued, I'll just assume the number of contributors will plummet. At least that sounds like the most likely outcome.
Here's hoping for the best.
I've lost count of how many projects I've contributed to, due to how easy Github makes submitting a patch.
Contrast that to contributing to Emacs: I can't recall a single time I tried to send in a change-proposal without regretting it, seeing it fan out for weeks in endless mailing lists discussions and more often than not end up going nowhere.
If Magit ends up under FSF ownership and the Github repo is discontinued, I'll just assume the number of contributors will plummet. At least that sounds like the most likely outcome.
Here's hoping for the best.
That has little to do with Github vs mailing list and much to do with the maintainers and the type of project. Github has lots of immature projects with single developers. Of course submitting a patch to emacs is going to be more difficult. I've had absolutely no problem contributing to parts of emacs (org-mode to be specific).
If they make it harder to contribute, you're guaranteed to get fewer contributions.
> you're going to have to wait days/weeks as your copyright assignment papers make their way over snail-mail.
Depends on the country. I signed mine with my GPG key in the United States and simply e-mailed it:
https://www.fsf.org/blogs/licensing/fsf-to-begin-accepting-g...
There's other countries, like Italy:
https://www.fsf.org/blogs/licensing/fsf-to-begin-accepting-g...
Depends on the country. I signed mine with my GPG key in the United States and simply e-mailed it:
https://www.fsf.org/blogs/licensing/fsf-to-begin-accepting-g...
There's other countries, like Italy:
https://www.fsf.org/blogs/licensing/fsf-to-begin-accepting-g...
FSF assignments have had full digital support in every country since 11/2016. https://www.fsf.org/blogs/licensing/fsf-now-offering-paperle...
The package is already licensed under the GPLv3,
I fully agree. I think it is also important to point out that it uses the 'either version 3, or (at your option) any later version'-wording. So, even if the FSF updates the GPL, they are fine.
I fully agree. I think it is also important to point out that it uses the 'either version 3, or (at your option) any later version'-wording. So, even if the FSF updates the GPL, they are fine.
Why would it be important to distribute Magit as part of Emacs? Why not just install it via MELPA?
No need to install it on remote systems. I'm more of a Vi guy and I have a decent selection of plugins on my primary system, but I appreciate being able to use the built in Vim features without installing stuff on remote machines.
Though Magit seems maybe a bit of a weird thing to be using on a minimal remote system.
Though Magit seems maybe a bit of a weird thing to be using on a minimal remote system.
And you can use the built-in emacs features via emacs -nw on a remote system. Core vim doesn't come with a git client I assume? So I'm not seeing the difference.
The other answer is
If we don't put stuff like org-mode and magit in emacs then the community will produce emacs distributions bundling the standard add-ons.
The other answer is
apt-get install emacs-core-plus-standard-packages
apt-get install emacs-core emacs-magit emacs-org-mode
If we don't put stuff like org-mode and magit in emacs then the community will produce emacs distributions bundling the standard add-ons.
There's no need to install Magit on remote systems. It works flawlessly over TRAMP and I use it every day like that.
> Why not just install it via MELPA?
Specifically addressing this point (since major distros already package magit):
There are environments where it's not allowed to install software that hasn't been cleared by site/department/company IT, let alone software from a rolling repository where packages aren't signed and upstream maintainers can get code in just by tagging it on GitHub. In such an environment it's a lot easier to say something like "I need Debian 12 with build-essential and emacs26".
As cool and handy as it is, MELPA is kind of scary from a security standpoint.
Specifically addressing this point (since major distros already package magit):
There are environments where it's not allowed to install software that hasn't been cleared by site/department/company IT, let alone software from a rolling repository where packages aren't signed and upstream maintainers can get code in just by tagging it on GitHub. In such an environment it's a lot easier to say something like "I need Debian 12 with build-essential and emacs26".
As cool and handy as it is, MELPA is kind of scary from a security standpoint.
That's true in terms of many Linux systems being locked down to normal users (no installing in /usr or even /usr/local). But emacs extensions install in your home directory. I've never heard of a system where users couldn't write to their own home directories.
> I've never heard of a system where users couldn't write to their own home directories.
Neither have I, but I have heard of (and been subject to) policies that don't allow installing unapproved 3rd party executable code, and have not seen one that made exceptions based on path.
Neither have I, but I have heard of (and been subject to) policies that don't allow installing unapproved 3rd party executable code, and have not seen one that made exceptions based on path.
I've heard of such policies, but only in the context of working for TLAs or certain high-risk positions in financial institutions.
But also, if such policies were based on (for instance) "noexec", you don't have to be able to run executables to install elisp code.
But also, if such policies were based on (for instance) "noexec", you don't have to be able to run executables to install elisp code.
Mine was neither, just a contract gig at a crappy company.
There were no technical measures in place to stop me from compiling my own binaries (that was in part what I was there to do), and bringing my own elisp also would have worked.
Except for the "breaking my contract" part, if it was unapproved 3rd party code. Given that actual FTEs respected the rule, it seemed unwise to test it.
There were no technical measures in place to stop me from compiling my own binaries (that was in part what I was there to do), and bringing my own elisp also would have worked.
Except for the "breaking my contract" part, if it was unapproved 3rd party code. Given that actual FTEs respected the rule, it seemed unwise to test it.
thanks for writing this down. i completely agree with you.
i am a happy emacs and magit user. i contribute to emacs packages, and maintain a few myself (emacs-direnv, evil-swap-keys, evil-colemak-basics, evil-text-object-python).
i do all this DESPITE emacs being a fsf/gnu project. i strongly dislike the old-fashioned processes, the extreme stances on things that i do not consider problems, and last but not least, the very negative and non-inclusive community.
the remarks by rms that a magit alternative/competitor would be welcome is POISONOUS. advocating for an unnecessary community divide is destructive for the goodwill of many (potential) contributors to the emacs ecosystem (myself included).
i am a happy emacs and magit user. i contribute to emacs packages, and maintain a few myself (emacs-direnv, evil-swap-keys, evil-colemak-basics, evil-text-object-python).
i do all this DESPITE emacs being a fsf/gnu project. i strongly dislike the old-fashioned processes, the extreme stances on things that i do not consider problems, and last but not least, the very negative and non-inclusive community.
the remarks by rms that a magit alternative/competitor would be welcome is POISONOUS. advocating for an unnecessary community divide is destructive for the goodwill of many (potential) contributors to the emacs ecosystem (myself included).
Also if it will be included, it may suffer from the same problem as standard library packages from many programming languages: very rare updates. For example, https://bugs.ruby-lang.org/projects/ruby/wiki/StdlibGem.
Yes, although you'll always have the option to install updates from Github.
Same case with orgmode.
Same case with orgmode.
Other projects have git access (outside the Emacs review process) and are included in Emacs. MH-E, for example.
I did the FSF paperwork and had a patch for Emacs accepted. Not a big deal, really. Dicussion of the patch on the mailing was very useful and I learned a thing or two from Eli. Not sure why people spend so much energy debating this when it is really a non-issue.
Copyright assignment papers no longer need to be sent over snail mail in most cases.
A higher barrier to entry or a different barrier to entry. Nobody was born with the ability to "just submit a pull request".
It's also a weird thing to say, given how much more difficult GitHub PRs make contributing regarding actual barrier-to-entry. GitHub contributions are only easy if you're already using GitHub to do your work. Talking about the marginal difficulty of using GitHub as if it's low on an absolute scale (rather than a relative scale, which is what marginal difficulty is about by definition) is like talking about the benefits of any other heavily subsidized thing without acknowledging the hidden subsidy and factoring it into the absolute cost.
I.e., it can only be called a low barrier to entry if you're willing redefine "entry" to be something other than "entry".
I.e., it can only be called a low barrier to entry if you're willing redefine "entry" to be something other than "entry".
If it were part of Emacs you'd need to use the FSF's collaboration tools which have a higher barrier of entry, and if you're a first-time contributor with a non-trivial contribution you're going to have to wait days/weeks as your copyright assignment papers make their way over snail-mail.
This is as good a reason as any to try to replace Emacs. Maybe Remacs will succeed.
Though I suppose it'd be best to have proof of this claim. Not that I don't believe you, but this is the type of thing that turns newbies away from Emacs without giving it a shot.
This is as good a reason as any to try to replace Emacs. Maybe Remacs will succeed.
Though I suppose it'd be best to have proof of this claim. Not that I don't believe you, but this is the type of thing that turns newbies away from Emacs without giving it a shot.
That's true but it's only the technical and logistical part of the problem.
There's a moral issue too in giving-up copyright to an entity : What if the future the FSF (RMS is not eternal) changes its policy to turn to something completely crazy with your code ? They will own all will own all your copyright-assigned code and you won't be able to do anything about it.
I mean : what if you were agree with GPL2 but not 3 and that now the copyright owner decides to move the code you've written to GPL3 ?
There's a moral issue too in giving-up copyright to an entity : What if the future the FSF (RMS is not eternal) changes its policy to turn to something completely crazy with your code ? They will own all will own all your copyright-assigned code and you won't be able to do anything about it.
I mean : what if you were agree with GPL2 but not 3 and that now the copyright owner decides to move the code you've written to GPL3 ?
>What if the future the FSF (RMS is not eternal) changes its policy to turn to something completely crazy with your code ?
The FSF's copyright assignment contract has clauses that prevent them from doing such things. It's really a very fair contract.
The FSF's copyright assignment contract has clauses that prevent them from doing such things. It's really a very fair contract.
To elaborate: the clause is actually designed precisely to prevent a hostile takeover from another entity; it's an important part of the contract. The clause states the conditions under which your code and program will be made available.
Ok this seems more reasonnable than I thought.
Neovim came along but majority who use vim still use vim. They won't change. This is in a situation where neovim is ahead of vim in certain areas (some may not like it and call it bloat but I call them features).
Unless remacs gives a clear advantage over emacs in terms of performance while still retaining compatibility people won't switch easily. Even then the switch should be quick and painless. (Neovim had those and so some people jumped ship).
Unless remacs gives a clear advantage over emacs in terms of performance while still retaining compatibility people won't switch easily. Even then the switch should be quick and painless. (Neovim had those and so some people jumped ship).
[deleted]
Can confirm. It hasn't turned me off Emacs by any means, but it is one of the reasons I strongly prefer releasing packages on MELPA to getting patches into Emacs proper.
I would never use Remacs but I would use CLemacs. Others wouldn't use the previous two but would use Pymacs, Rbemacs or Hemacs. Then there's people who wouldn't use any of those but swear by Elmacs.
You're aware that remacs rewrite the C part of emacs in Rust, not the ELisp ones? The final goal for users and plugin writers is a fully transparent transition.
> if you're a first-time contributor with a non-trivial contribution you're going to have to wait days/weeks as your copyright assignment papers make their way over snail-mail.
I've always wondered how you could "contribute" to an FSF project when it was clear that your "contribution" ended up as 100% their work.
Sure, they need to have some kind of legal process around enforcing copyright, but Samba seems to have done fine while accepting individual contributions.
> The package is already licensed under the GPLv3
Exactly. It's clear that the FSF has no interest in GPL code. Instead, they're interested in GPL code that they own. If they can't own it, they don't want to touch it.
For me, this is one more thing where the FSF has an attitude of "my way or the highway". I don't like it from large corporations, and I don't like in the "free" software world, either.
And that's ignoring other issues... most FSF projects I've used are bloated and over-designed. And Hurd? It's been 27 years, and it's still not ready for prime time.
As history shows, the Linux approach of "lower barriers to contribution" works a whole lot better than "make people jump through complicated hoops before accepting their code".
I've always wondered how you could "contribute" to an FSF project when it was clear that your "contribution" ended up as 100% their work.
Sure, they need to have some kind of legal process around enforcing copyright, but Samba seems to have done fine while accepting individual contributions.
> The package is already licensed under the GPLv3
Exactly. It's clear that the FSF has no interest in GPL code. Instead, they're interested in GPL code that they own. If they can't own it, they don't want to touch it.
For me, this is one more thing where the FSF has an attitude of "my way or the highway". I don't like it from large corporations, and I don't like in the "free" software world, either.
And that's ignoring other issues... most FSF projects I've used are bloated and over-designed. And Hurd? It's been 27 years, and it's still not ready for prime time.
As history shows, the Linux approach of "lower barriers to contribution" works a whole lot better than "make people jump through complicated hoops before accepting their code".
> I've always wondered how you could "contribute" to an FSF project when it was clear that your "contribution" ended up as 100% their work.
The copyright assignment papers you write aren't as unilateral as you might think. It doesn't say "this belongs to the FSF now, none of it is for you." They're fairly clear in the language and say that the FSF will defend your software and keep it free for everyone, including of course yourself. It's an exchange: you give them your copyright, in return they will use your copyright to forever defend your software from becoming non-free. So your software will always be available to everyone, including yourself. You also only have to sign them once ever; it's not like they require new papers for each contribution you make.
Oh, and you also get a sticker, I think. :-) Due to some legal finnagling, since you're signing your copyright away as part of a contract, you need to receive something of tangible value in return. I think that's why you get back a sticker (or maybe it was dollar bill, I forget).
I don't think the FSF has ever gone to court defending copyleft, but that's not entirely the point. A good weapon can be effective as self-defense merely as a deterrent. It doesn't necessarily have to be fired. Also, the FSF always exhausts all other means to bring about GPL compliance and considers legal action a means of absolutely last resort.
The copyright assignment papers you write aren't as unilateral as you might think. It doesn't say "this belongs to the FSF now, none of it is for you." They're fairly clear in the language and say that the FSF will defend your software and keep it free for everyone, including of course yourself. It's an exchange: you give them your copyright, in return they will use your copyright to forever defend your software from becoming non-free. So your software will always be available to everyone, including yourself. You also only have to sign them once ever; it's not like they require new papers for each contribution you make.
Oh, and you also get a sticker, I think. :-) Due to some legal finnagling, since you're signing your copyright away as part of a contract, you need to receive something of tangible value in return. I think that's why you get back a sticker (or maybe it was dollar bill, I forget).
I don't think the FSF has ever gone to court defending copyleft, but that's not entirely the point. A good weapon can be effective as self-defense merely as a deterrent. It doesn't necessarily have to be fired. Also, the FSF always exhausts all other means to bring about GPL compliance and considers legal action a means of absolutely last resort.
> The copyright assignment papers you write aren't as unilateral as you might think.
It means you are prohibited from using your own code except as how the FSF sees fit. That's what copyright assignment means.
So if you want to take your code and contribute it to a BSD licensed project? Nope. FSF won't allow that. Or use it in a commercial product? Nope. FSF won't allow that.
You can use it in a GPL product, so long as you keep the FSF copyright.
> A good weapon can be effective as self-defense merely as a deterrent.
Sure. And what about Samba?
Nothing prevents the Samba team from joining together collectively and suing someone for violating their license. The fact that other people have contributed small pieces to the code doesn't matter. A GPL license violation is still a violation of the code they own.
e.g my own project: FreeRADIUS. At this point, I've written at least half of the code. If there's a licence violation, I don't need anyone else's permission (or copyright assignment) to go after the violators.
So what, exactly benefit do I gain by submitting code to the FSF, and assigning copyright?
It means you are prohibited from using your own code except as how the FSF sees fit. That's what copyright assignment means.
So if you want to take your code and contribute it to a BSD licensed project? Nope. FSF won't allow that. Or use it in a commercial product? Nope. FSF won't allow that.
You can use it in a GPL product, so long as you keep the FSF copyright.
> A good weapon can be effective as self-defense merely as a deterrent.
Sure. And what about Samba?
Nothing prevents the Samba team from joining together collectively and suing someone for violating their license. The fact that other people have contributed small pieces to the code doesn't matter. A GPL license violation is still a violation of the code they own.
e.g my own project: FreeRADIUS. At this point, I've written at least half of the code. If there's a licence violation, I don't need anyone else's permission (or copyright assignment) to go after the violators.
So what, exactly benefit do I gain by submitting code to the FSF, and assigning copyright?
> It means you are prohibited from using your own code except as how the FSF sees fit. That's what copyright assignment means.
The FSF copyright assignment grants you back the right to do what you wish with your code, including sell exceptions.
> So what, exactly benefit do I gain by submitting code to the FSF, and assigning copyright?
Because they'll enforce the GPL on your behalf. I assigned copyright for my GNU project to the FSF for that reason: I have no resources for enforcement. Nor do most people.
> e.g my own project: FreeRADIUS. At this point, I've written at least half of the code. If there's a licence violation, I don't need anyone else's permission (or copyright assignment) to go after the violators.
If there's a violation with _your code_.
If someone uses a portion of your code you don't have copyright over, you have no standing. And _this_ is why the FSF wants full copyright over Emacs.
The FSF copyright assignment grants you back the right to do what you wish with your code, including sell exceptions.
> So what, exactly benefit do I gain by submitting code to the FSF, and assigning copyright?
Because they'll enforce the GPL on your behalf. I assigned copyright for my GNU project to the FSF for that reason: I have no resources for enforcement. Nor do most people.
> e.g my own project: FreeRADIUS. At this point, I've written at least half of the code. If there's a licence violation, I don't need anyone else's permission (or copyright assignment) to go after the violators.
If there's a violation with _your code_.
If someone uses a portion of your code you don't have copyright over, you have no standing. And _this_ is why the FSF wants full copyright over Emacs.
> The FSF copyright assignment grants you back the right to do what you wish with your code, including sell exceptions.
And can I enforce copyright for those exceptions?
Clearly not, because the FSF owns the copyright.
And can I enforce copyright for those exceptions?
Clearly not, because the FSF owns the copyright.
No, the FSF would have to.
> If someone uses a portion of your code you don't have copyright over,
Then it's not my code, and I don't have rights on it, do I?
Then it's not my code, and I don't have rights on it, do I?
I hope parent commentor clarifies this: do you still get to claim a fork of your contributed code as copyrighted to yourself? The standing problem goes both ways; if you distributed your fork but you had licensed it from the FSF, won't you lack standing from unauthorized use?
[deleted]
> I hope parent commentor clarifies this
I can't edit my comment; sorry. I meant "your project's code".
I can't edit my comment; sorry. I meant "your project's code".
>do you still get to claim a fork of your contributed code as copyrighted to yourself?
I believe so - as long as you license it with the GPL.
I believe so - as long as you license it with the GPL.
So you concede that it doesn't matter if you wrote over half the code? If only there were a mechanism for reaching that other code, so you could defend it...
Oh, wait. Perhaps if those contributors assigned their copyright to you under a very permissive contract...
Oh, wait. Perhaps if those contributors assigned their copyright to you under a very permissive contract...
I don't understand the confusion here. It's not rocket science.
> So you concede that it doesn't matter if you wrote over half the code?
There's just no way you can conclude that from my comments. I explicitely said I could enforce copyright on my code, even if it's only half of the project.
Again, the comment I was replying to said this:
> If someone uses a portion of your code you don't have copyright over,
Does no one see the logical contradiction in that statement?
YOUR code that YOU DON'T OWN.
Uh... then it's not MY CODE, is it? Is that really that hard to figure out?
I'll explain using simple examples, as people apparently aren't getting it.
* If a third-party contributor to my project re-uses his own code elsewhere, I don't care. It's his code.
* If someone violates copyright on a third-party contributors code, again, I don't really care. He's responsible for enforcing copyright on his code. I'm not.
* And if he's contributing code to my project, I'm pretty sure that code is integrated into my project, and is largely useless outside of it. So the odds of a violation of just his code are pretty small.
* If someone infringes on the project as a whole, then I own copyright to the majority, and I can enforce my copyright, independent of anyone else.
* [edit] And if I submit code to the FSF and assign copyright to them, then it's their responsibility to enforce copyright... because they own the copyright. And yes, I have no standing.
Is that clear? Can people please stop down-voting me for pointing out logical inconsistencies?
> So you concede that it doesn't matter if you wrote over half the code?
There's just no way you can conclude that from my comments. I explicitely said I could enforce copyright on my code, even if it's only half of the project.
Again, the comment I was replying to said this:
> If someone uses a portion of your code you don't have copyright over,
Does no one see the logical contradiction in that statement?
YOUR code that YOU DON'T OWN.
Uh... then it's not MY CODE, is it? Is that really that hard to figure out?
I'll explain using simple examples, as people apparently aren't getting it.
* If a third-party contributor to my project re-uses his own code elsewhere, I don't care. It's his code.
* If someone violates copyright on a third-party contributors code, again, I don't really care. He's responsible for enforcing copyright on his code. I'm not.
* And if he's contributing code to my project, I'm pretty sure that code is integrated into my project, and is largely useless outside of it. So the odds of a violation of just his code are pretty small.
* If someone infringes on the project as a whole, then I own copyright to the majority, and I can enforce my copyright, independent of anyone else.
* [edit] And if I submit code to the FSF and assign copyright to them, then it's their responsibility to enforce copyright... because they own the copyright. And yes, I have no standing.
Is that clear? Can people please stop down-voting me for pointing out logical inconsistencies?
> use it in a commercial product? Nope. FSF won't allow that.
The FSF explicitly allows that.
> The assignment contract we normally use has a clause that permits you to use your code in proprietary programs [...] Although we believe that proprietary software is wrong, we include this clause because it would serve no purpose to ask you to promise not to do it. You're giving us a gift in the first place.
http://git.savannah.gnu.org/cgit/gnulib.git/tree/doc/Copyrig...
The FSF explicitly allows that.
> The assignment contract we normally use has a clause that permits you to use your code in proprietary programs [...] Although we believe that proprietary software is wrong, we include this clause because it would serve no purpose to ask you to promise not to do it. You're giving us a gift in the first place.
http://git.savannah.gnu.org/cgit/gnulib.git/tree/doc/Copyrig...
And... can you enforce copyright on such a program?
No, because the FSF owns the copyright. They have to do it.
Or maybe the program has mixed copyright (you and the FSF), in which case the same problem (and solution) applies for mixed-copyright software.
So how exactly, does assigning copyright to the FSF make anything better for anyone? It helps the FSF, sure. But everyone else (including the author) is negatively impacted by it.
In contrast, if copyright remains with the author, then the only thing the FSF would lose is the ability to sue for infringement of the code you contributed.
They could still sue for infringement of the code that they own.
No, because the FSF owns the copyright. They have to do it.
Or maybe the program has mixed copyright (you and the FSF), in which case the same problem (and solution) applies for mixed-copyright software.
So how exactly, does assigning copyright to the FSF make anything better for anyone? It helps the FSF, sure. But everyone else (including the author) is negatively impacted by it.
In contrast, if copyright remains with the author, then the only thing the FSF would lose is the ability to sue for infringement of the code you contributed.
They could still sue for infringement of the code that they own.
> So how exactly, does assigning copyright to the FSF make anything better for anyone? It helps the FSF, sure. But everyone else (including the author) is negatively impacted by it.
The author assigning the copyright benefits from GPL enforcement---enforcement they likely would not have the resources to do themselves.
The code is still free software; the author can continue to use it in other free software projects. Do you have a specific situation in mind where the author might want to still have copyright (aside from a matter of principle) so we can focus on that for discussion?
The author assigning the copyright benefits from GPL enforcement---enforcement they likely would not have the resources to do themselves.
The code is still free software; the author can continue to use it in other free software projects. Do you have a specific situation in mind where the author might want to still have copyright (aside from a matter of principle) so we can focus on that for discussion?
My use-case is that I want to use the code I write as I see fit, using all of the rights I have available to me. If I assign copyright to the FSF, I lose many of those rights.
So no, it's not about a specific situation. It's about the principle of the thing.
i.e. if the FSF can be founded on the principle of freedom, why can't I claim to believe in the principle of freedom too? And why do I have to give up my rights under the law, in order to give the FSF more freedom for themselves?
> The author assigning the copyright benefits from GPL enforcement---enforcement they likely would not have the resources to do themselves.
The logical conclusion of that statement is that copyright doesn't really matter, whether the license is GPL or not. Violators can ignore the copyright, secure in the confidence that the majority of people won't have the resources to sue.
So why don't we assign copyright for all open source projects to the FSF? After all, if the software is free, it doesn't really matter who the copyright holder is, right? And having someone who can enforce is is good, right?
Yes, I'm playing devil's advocate here. There are unstated assumptions in the FSF's position, and in peoples support of it. I'd like to clarify what those assumptions are, and why they're true (or not).
So no, it's not about a specific situation. It's about the principle of the thing.
i.e. if the FSF can be founded on the principle of freedom, why can't I claim to believe in the principle of freedom too? And why do I have to give up my rights under the law, in order to give the FSF more freedom for themselves?
> The author assigning the copyright benefits from GPL enforcement---enforcement they likely would not have the resources to do themselves.
The logical conclusion of that statement is that copyright doesn't really matter, whether the license is GPL or not. Violators can ignore the copyright, secure in the confidence that the majority of people won't have the resources to sue.
So why don't we assign copyright for all open source projects to the FSF? After all, if the software is free, it doesn't really matter who the copyright holder is, right? And having someone who can enforce is is good, right?
Yes, I'm playing devil's advocate here. There are unstated assumptions in the FSF's position, and in peoples support of it. I'd like to clarify what those assumptions are, and why they're true (or not).
> So no, it's not about a specific situation. It's about the principle of the thing.
That's fair.
> i.e. if the FSF can be founded on the principle of freedom, why can't I claim to believe in the principle of freedom too?
They're founded on a principle of freedom as defined specifically by the four freedoms.
> The logical conclusion of that statement is that copyright doesn't really matter, whether the license is GPL or not. Violators can ignore the copyright, secure in the confidence that the majority of people won't have the resources to sue.
Yes there's a problem with the Copyright system. But the law does act as a deterrent because there is always risk involved in violating it.
> So why don't we assign copyright for all open source projects to the FSF?
The simple answer: they only accept copyright assignments for GNU projects.
They don't have the staff for enforcing others' copyrights, though; there's other organizations for that, like the Conservancy.
> After all, if the software is free, it doesn't really matter who the copyright holder is, right?
Sure it does: only the Copyright holder has standing in court.
That's fair.
> i.e. if the FSF can be founded on the principle of freedom, why can't I claim to believe in the principle of freedom too?
They're founded on a principle of freedom as defined specifically by the four freedoms.
> The logical conclusion of that statement is that copyright doesn't really matter, whether the license is GPL or not. Violators can ignore the copyright, secure in the confidence that the majority of people won't have the resources to sue.
Yes there's a problem with the Copyright system. But the law does act as a deterrent because there is always risk involved in violating it.
> So why don't we assign copyright for all open source projects to the FSF?
The simple answer: they only accept copyright assignments for GNU projects.
They don't have the staff for enforcing others' copyrights, though; there's other organizations for that, like the Conservancy.
> After all, if the software is free, it doesn't really matter who the copyright holder is, right?
Sure it does: only the Copyright holder has standing in court.
> Nothing prevents the Samba team from joining together collectively and suing someone for violating their license.
It's a lot more work and can be more tricky when there are many different copyright holders. For example, the GPL case against VMWare has hinged on proving that Christoph Hellwig in fact owns the copyright to the lines in ESXi that ended up in VMWare's codebase. He tried to provide git blame output, as I recall, but the court didn't consider this to be sufficient. The case got thrown out, although Hellwig has said he will appeal.
If Linux had a single copyright holder, there would be no need for git blame output and Linux could mount a more effective defense.
It's a lot more work and can be more tricky when there are many different copyright holders. For example, the GPL case against VMWare has hinged on proving that Christoph Hellwig in fact owns the copyright to the lines in ESXi that ended up in VMWare's codebase. He tried to provide git blame output, as I recall, but the court didn't consider this to be sufficient. The case got thrown out, although Hellwig has said he will appeal.
If Linux had a single copyright holder, there would be no need for git blame output and Linux could mount a more effective defense.
[deleted]
Note that FSF copyright assignment is opt-in for GNU projects. There are many projects that do not use copyright assignment. Sometimes it makes sense, sometimes it doesn't.
> Either all of the significant contributors to Magit must sign papers with the FSF (with code from the holdouts being replaced), or an entirely new Emacs interface to Git must be written.
False dichotomy: GNU Emacs can simply not ship with a git porcelain.
Most Emacs users I know typically have dozens of packages installed from MELPA; I don't think most users mind having to install an extra one. If an acceptable agreement regarding copyright assignment cannot be reached, I would really prefer that the status quo be maintained.
False dichotomy: GNU Emacs can simply not ship with a git porcelain.
Most Emacs users I know typically have dozens of packages installed from MELPA; I don't think most users mind having to install an extra one. If an acceptable agreement regarding copyright assignment cannot be reached, I would really prefer that the status quo be maintained.
It's not a false dichotomy. You're just working VERY hard at ignoring the context. The part you quoted comes right after the part that says "If we want to distribute something like Magit with Emacs".
If you don't think that's a worthwhile goal, that's fine, but there is no need to blatantly misinterpret the context of the discussion here.
If you don't think that's a worthwhile goal, that's fine, but there is no need to blatantly misinterpret the context of the discussion here.
Yeah, maybe Magit is also the killer app for the 'package' system as well.
Stallman said he didn't like having to tell users that they need to install a package in order to have the kind of functionality that Magit provides.
So? He's not the maintainer of the project. Anyway, that's clearly a non-scaleable solution. No software engineer would be attracted to this design, only someone with a fanatical obsession with GPL which blinds him to engineering considerations. The emacs core developers can't take on the burden of maintaining every bit of add-on functionality that is written throughout human history and seems useful enough to want to include in emacs. These things should have test suites; maintaining a discrete project like magit or org-mode is the job of the magit/org-mode developers, and should be isolated from the core Emacs code base, interacting via the API provided by Emacs core. One job of the core developers is to design and maintain that API.
I think you misunderstand the issue. The Emacs maintainers would not have to maintain Magit, and that's not what this is about. This is about distribution.
Note that the GNU ELPA is considered to be part of Emacs, whereas MELPA is not. MELPA may also contain unlicensed software or otherwise non-free software.
Note that the GNU ELPA is considered to be part of Emacs, whereas MELPA is not. MELPA may also contain unlicensed software or otherwise non-free software.
> MELPA may also contain unlicensed software or otherwise non-free software.
Some statistics on that: https://emacsmirror.net/stats/licenses.html.
Some statistics on that: https://emacsmirror.net/stats/licenses.html.
I don't think I misunderstand the issue.
> The Emacs maintainers would not have to maintain Magit
That's not true. They would have to maintain it: deal with bug reports, deal with breakage due to upstream API changes in Emacs core. They wouldn't do feature development.
I used to contribute code to org-mode, so I know how this works. The magit team will make periodic releases, at which point the magit code will be copied over into the emacs code base. From that point on, the emacs maintainers are on the hook for any bugs or other problems occurring with the version of magit that they have included into Emacs. They'll have to deal with/triage magit bug reports received via the Emacs bug tracker.
> The Emacs maintainers would not have to maintain Magit
That's not true. They would have to maintain it: deal with bug reports, deal with breakage due to upstream API changes in Emacs core. They wouldn't do feature development.
I used to contribute code to org-mode, so I know how this works. The magit team will make periodic releases, at which point the magit code will be copied over into the emacs code base. From that point on, the emacs maintainers are on the hook for any bugs or other problems occurring with the version of magit that they have included into Emacs. They'll have to deal with/triage magit bug reports received via the Emacs bug tracker.
> He's not the maintainer of the project
RMS' opinion is taken very seriously in emacs development community.
RMS' opinion is taken very seriously in emacs development community.
Why? Has he written any code lately?
Honest question, because from the outside he seems like an absolute grognard whose computing habits are so far removed from those of everyone else that he is incapable of relating to how the modern world does its computing.
Perhaps if he wants a good git interface in emacs, RMS should sling some code instead of giving the same entry-level ethics talk ad nauseam.
Honest question, because from the outside he seems like an absolute grognard whose computing habits are so far removed from those of everyone else that he is incapable of relating to how the modern world does its computing.
Perhaps if he wants a good git interface in emacs, RMS should sling some code instead of giving the same entry-level ethics talk ad nauseam.
> Has he written any code lately?
Why would that even matter? I find this attitude very puzzling and extremely worrying.
Of all the arbitrary metrics to decide whether to listen to and consider somebody's position "lines of code written" seems like an exceptionally poor choice.
I find your comment to be a good example of what is wrong in circles that like to consider themselves part of hacker culture.
Why would that even matter? I find this attitude very puzzling and extremely worrying.
Of all the arbitrary metrics to decide whether to listen to and consider somebody's position "lines of code written" seems like an exceptionally poor choice.
I find your comment to be a good example of what is wrong in circles that like to consider themselves part of hacker culture.
Well if he's not contributing to the project in any meaningful way, why is his opinion valued?
It's not a matter of lines of code, but of contribution at all.
What does RMS enable the emacs project to do that they couldn't do without him?
What does he bring to the table?
I'm not being rhetorical, I mean it: why do people care what he thinks?
It's not a matter of lines of code, but of contribution at all.
What does RMS enable the emacs project to do that they couldn't do without him?
What does he bring to the table?
I'm not being rhetorical, I mean it: why do people care what he thinks?
It's not even a GPL/non-GPL issue. Magit is licensed under the GPLv3.
It's because the FSF doesn't have assignment of the copyright to the code and there's no signed contributor agreements. The insane part of this isn't wanting it to be FOSS (it is!!), it's insisting it to be a part of the core project.
It's because the FSF doesn't have assignment of the copyright to the code and there's no signed contributor agreements. The insane part of this isn't wanting it to be FOSS (it is!!), it's insisting it to be a part of the core project.
> False dichotomy: GNU Emacs can simply not ship with a git porcelain.
False dichotomy: The FSF can drop their requirement for onereous copyright assignments and instead trust the GPL to do its job.
False dichotomy: The FSF can drop their requirement for onereous copyright assignments and instead trust the GPL to do its job.
For a copyleft license to do its job you have to enforce it, otherwise it would be the same as a permissive license.
The FSF is not requiring copyright assignment. It is the choice of the GNU Emacs project that the GNU Emacs project requires them. The Emacs maintainers could change their minds about that, and FSF would be OK with that.
friendly reminder: the built-in vc-mode can interface with most version control systems, including git.
It's not as great as magit, but it works (and it has you to learn very little).
It's not as great as magit, but it works (and it has you to learn very little).
If the FSF wants Magit but can't bundle it because of their own policies (as Stefan Monnier so eloquently points out), that's a problem for the FSF to solve, not Magit.
I think this comment on the Lwn-article really highlights how bizarre this has all turned out:
> GNU began as a project to replace proprietary software with free one, and now lives on as a project to replace free software with free software.
I think that about sums it up. (And I say that as a passionate Emacs-user)
I think this comment on the Lwn-article really highlights how bizarre this has all turned out:
> GNU began as a project to replace proprietary software with free one, and now lives on as a project to replace free software with free software.
I think that about sums it up. (And I say that as a passionate Emacs-user)
Apropos vc-mode comes with vc-annotate-mode (C-x C-v g) which is the best way to go through the history of the file
Magit is still the reason I haven't jumped ship to Atom of VSCode at this point and I would hate to see anything happen to it that would negatively effect its development.
As far as the argument goes, I feel the platform is _better_ by having such a marquee package not be included. The barrier to get it installed it quite simple ( run one command ) and it opens up the user to the package management system which is getting better and allows users to bring in all the features that used to require elisp hacking
As far as the argument goes, I feel the platform is _better_ by having such a marquee package not be included. The barrier to get it installed it quite simple ( run one command ) and it opens up the user to the package management system which is getting better and allows users to bring in all the features that used to require elisp hacking
So, the reason that FSF wants the hold the copyright to the code they distribute is so that they, as the copyright holder, can enforce the license [1]. But why do they need to be the ones enforcing the license on every bit of code they distribute? They could include Magit with Emacs and just declare that they will not be the ones enforcing the license on that part of the code. The main issue I see with such an arrangement is that if Magit was included with Emacs, then conceivably some low-level Magit functions that have more general use could start to find their way into other Emacs code, and other people writing code for Emacs will use those functions in their code. Then the FSF would be in a situation where some of the code that they hold the copyright to depends on code whose copyright they don't hold.
To prevent this, I guess they could establish a "contrib" directory in the emacs source for GPL3+-compatible code that is distributed with Emacs but whose copyright is not owned by the FSF. Any GPL3+ code, or really any free software code with a compatible license, could be added in this directory, without copyright assignment, if the Emacs maintainers feel it's worth including with Emacs. Then, they could require that code outside the contrib directory must not depend on code inside it, and that would be a fairly easy rule to enforce. Then they can include Magit and whatever other GPL3+ Emacs packages they want to with Emacs, but they will still have precise knowledge of which parts of the code they hold the copyright to and can enforce the license on (namely, everything outside the contrib directory).
Are there any downsides to such an arrangement that I'm missing? Is there something that makes this kind of solution unworkable?
Ultimately, I don't see why the FSF doesn't want to distribute any code that they can't enforce the license on. Maintaining copyright on their own code and distributing other people's code aren't mutually exclusive activities.
[1]: https://www.gnu.org/licenses/why-assign.en.html
To prevent this, I guess they could establish a "contrib" directory in the emacs source for GPL3+-compatible code that is distributed with Emacs but whose copyright is not owned by the FSF. Any GPL3+ code, or really any free software code with a compatible license, could be added in this directory, without copyright assignment, if the Emacs maintainers feel it's worth including with Emacs. Then, they could require that code outside the contrib directory must not depend on code inside it, and that would be a fairly easy rule to enforce. Then they can include Magit and whatever other GPL3+ Emacs packages they want to with Emacs, but they will still have precise knowledge of which parts of the code they hold the copyright to and can enforce the license on (namely, everything outside the contrib directory).
Are there any downsides to such an arrangement that I'm missing? Is there something that makes this kind of solution unworkable?
Ultimately, I don't see why the FSF doesn't want to distribute any code that they can't enforce the license on. Maintaining copyright on their own code and distributing other people's code aren't mutually exclusive activities.
[1]: https://www.gnu.org/licenses/why-assign.en.html
Emacs does not need to bundle Magit (or most other packages for that matter). What it needs is better package manager - built in!
As of recently, I'm an Emacs user (long time Vim user, just wanted some change) and I still have not completely comprehended how MELPA works. If anything should be more closely built in (and documented and standardised) to Emacs, package manager should. Everything else is better placed into outside packages.
If we look at Python world, here and there we can find discussions to include some library into stdlib and there are good reasons not to do it. Yes, batteries included is cool at first but it's no wonder that pythonistas say that "stdlib is place where packages go to die". We can think the same of Emacs and its package system.
As of recently, I'm an Emacs user (long time Vim user, just wanted some change) and I still have not completely comprehended how MELPA works. If anything should be more closely built in (and documented and standardised) to Emacs, package manager should. Everything else is better placed into outside packages.
If we look at Python world, here and there we can find discussions to include some library into stdlib and there are good reasons not to do it. Yes, batteries included is cool at first but it's no wonder that pythonistas say that "stdlib is place where packages go to die". We can think the same of Emacs and its package system.
What's the issue with the builtin package manager? After configuring your desired sources, any of the hundreds of packages available are literally an M-x package-install away (or package-list-packages if you want to browse around).
[1] This is my 'configuration', I haven't touched it in years: (setq package-archives '(("gnu" . "http://elpa.gnu.org/packages/") ("melpa-stable" . "http://stable.melpa.org/packages/") ("melpa" . "http://melpa.org/packages/")))
[1] This is my 'configuration', I haven't touched it in years: (setq package-archives '(("gnu" . "http://elpa.gnu.org/packages/") ("melpa-stable" . "http://stable.melpa.org/packages/") ("melpa" . "http://melpa.org/packages/")))
One of my biggest issues is that you can't request specific versions. Without that, the standard "big distributions" like spacemacs are doomed to constantly break. It's no accident quite a few Emacs power users plain don't use it.
> What it needs is better package manager - built in!
Er… it does? package.el has been included in Emacs since Emacs 24[0], and there's an official package repository[1] which is included by default, alongside the older MELPA and Marmalade which you can add to 'package-archives if you want packages from there.
> I still have not completely comprehended how MELPA works.
MELPA is just a repository for package.el.
> If anything should be more closely built in (and documented and standardised) to Emacs, package manager should.
It is…
[0] https://www.emacswiki.org/emacs/ELPA
[1] http://elpa.gnu.org
Er… it does? package.el has been included in Emacs since Emacs 24[0], and there's an official package repository[1] which is included by default, alongside the older MELPA and Marmalade which you can add to 'package-archives if you want packages from there.
> I still have not completely comprehended how MELPA works.
MELPA is just a repository for package.el.
> If anything should be more closely built in (and documented and standardised) to Emacs, package manager should.
It is…
[0] https://www.emacswiki.org/emacs/ELPA
[1] http://elpa.gnu.org
Just like other built-in things, the package.el is way too basic, both in terms of features and interface. It's also useless for packages you'd like to closely follow, as it cannot deal with git/bzr/hg/whathaveyou. Inability to pin some package to the given version is also a major pain.
It's kind-of OK for beginners, but for more advanced users it's disappointing. It's better, IMHO, to think about package.el as a low-level library implementing some functions useful for package management - but calling it a package manager, while technically correct, seems like a bit of a stretch.
There are other projects however, like el-get, which work. So it's not like Emacs has no package manager. It's just that the "real" package managers are far away from being built-in.
It's kind-of OK for beginners, but for more advanced users it's disappointing. It's better, IMHO, to think about package.el as a low-level library implementing some functions useful for package management - but calling it a package manager, while technically correct, seems like a bit of a stretch.
There are other projects however, like el-get, which work. So it's not like Emacs has no package manager. It's just that the "real" package managers are far away from being built-in.
I think one reason why people don't know about the emacs package manager is a lot of people know emacs from Linux servers, many of which run ancient versions of CentOS (for "reliability"). I ended up installing my own version of emacs in my home directory because the installed version in /usr/bin is 23.1.1.
Speaking as a Debian user; so maybe not part of the majority, but the last problem that the world faces is not enough package managers.
As far as I know, even Windows and MacOS have made moves towards implementing package managers AKA App Stores. I know iOS has it in spades. The Linux distributions have the problem of packet management figured out to their tastes.
Having a _completely_ different extension/package paradigm for every major and minor piece of software is not a user-friendly approach.
As far as I know, even Windows and MacOS have made moves towards implementing package managers AKA App Stores. I know iOS has it in spades. The Linux distributions have the problem of packet management figured out to their tastes.
Having a _completely_ different extension/package paradigm for every major and minor piece of software is not a user-friendly approach.
> Having a _completely_ different extension/package paradigm for every major and minor piece of software is not a user-friendly approach.
The central problem is that from an upstream author's perspective, distro package management is a nightmare.
Once upon a time, I tried maintaining Debian and RPM packages for my software. The process to become a Debian package maintainer was incredibly onerous and bureaucratic. Furthermore, dpkg is designed around the idea that you really should have exactly one version of each dependency across an entire system, for every piece of software that depends on it. And finally, the Debian stable version was usually years out of date.
RPM-based distributions had their own problems: Different, incompatible RPM features, dependency hell, etc. And of course, between dpkg and RPM, there were a half-dozen popular Linux distros, and two popular "distro" package managers on the Mac.
So I gave up. I distribute virtually all of my software using "language" package managers like bundler, npm and cargo. (And the rest as statically linked musl-libc binaries or Docker images.) These have top-notch support for dependency management, semantic versioning, and cross-platform builds. They're about a decade more advanced that dpkg or RPM for the things I care about. And if for some reason I need a GUI app, there's always Electron.
With cargo, TravisCI and AppVeyor, I can package a CLI tool for every popular system (including Windows) in a weekend, with automated cross-platform tests, and I'll rarely ever think about it again. And all my users can always get the latest versions, not three-year-old versions.
Anybody who wants to package my software for a distro is welcome to do so. I wash my hands of it all, and I'm extremely unlikely to provide any support.
The central problem is that from an upstream author's perspective, distro package management is a nightmare.
Once upon a time, I tried maintaining Debian and RPM packages for my software. The process to become a Debian package maintainer was incredibly onerous and bureaucratic. Furthermore, dpkg is designed around the idea that you really should have exactly one version of each dependency across an entire system, for every piece of software that depends on it. And finally, the Debian stable version was usually years out of date.
RPM-based distributions had their own problems: Different, incompatible RPM features, dependency hell, etc. And of course, between dpkg and RPM, there were a half-dozen popular Linux distros, and two popular "distro" package managers on the Mac.
So I gave up. I distribute virtually all of my software using "language" package managers like bundler, npm and cargo. (And the rest as statically linked musl-libc binaries or Docker images.) These have top-notch support for dependency management, semantic versioning, and cross-platform builds. They're about a decade more advanced that dpkg or RPM for the things I care about. And if for some reason I need a GUI app, there's always Electron.
With cargo, TravisCI and AppVeyor, I can package a CLI tool for every popular system (including Windows) in a weekend, with automated cross-platform tests, and I'll rarely ever think about it again. And all my users can always get the latest versions, not three-year-old versions.
Anybody who wants to package my software for a distro is welcome to do so. I wash my hands of it all, and I'm extremely unlikely to provide any support.
Isn't the default package site called ELPA? (not MELPA which is not official but maintained by the community).
Forget MELPA. Use el-get.
I concur, el-get is quite nice and can install/manage packages from a wide variety of sources, sort of like Arch's AUR. It's at https://github.com/dimitri/el-get.
Why is there a desire to include things like magit in emacs? (Same question regarding e.g. org-mode). Wouldn't it be better to have a lean core, abiding by the strict FSF rules, and a high quality package ecosystem and package manager? It needn't be a barrier to beginners, high quality "distributions" bundling the great packages like magit and org-mode would appear immediately (kind of exist already, like spacemacs).
You tend to have the same kinds of problems as early Linux distros did - namely, fragmentation that accidentally heightens the barrier to entry.
Aside from that, much of Emacs's power comes from the ecosystem of Emacs Lisp applications and libraries that come with the base install. I learned Emacs in the first place because of Tramp's appeal, and shortly thereafter discovered in org-mode an amazingly powerful tool I'd never realized I wanted so badly. Absent either of those, I probably would not have kept using Emacs for long.
Finally, there's the question of support. A few years back, when I was much more heavily involved in helping new Emacs users on sites like Stack Overflow, I found over time that the problems people were having tended more often than not to originate not in Emacs per se, but rather in the (mis)behavior of the various collections of packages that came with one or another of the "starter kits" then popular, and beset by the same fragmentation mentioned above. When you start out not with Emacs, but with Emacs plus a large collection of random packages tied together with customizations and init unique to the distribution, it's much harder to find useful information when something goes wrong, because there probably aren't all that many people using the same thing you are - and, being very new, you likely don't yet know how to have a productive conversation with Emacs itself, or even that such conversations are possible.
Conversely, when you have a problem with something that's part of Emacs, you're much more likely to find something or someone that can help you get past it, because ~everyone using Emacs is running the same code you are, and someone has almost certainly figured out how to solve the same problem before. Fragmenting the ecosystem makes this less likely; incorporating popular packages into Emacs, where that can be accomplished, makes it more so.
Aside from that, much of Emacs's power comes from the ecosystem of Emacs Lisp applications and libraries that come with the base install. I learned Emacs in the first place because of Tramp's appeal, and shortly thereafter discovered in org-mode an amazingly powerful tool I'd never realized I wanted so badly. Absent either of those, I probably would not have kept using Emacs for long.
Finally, there's the question of support. A few years back, when I was much more heavily involved in helping new Emacs users on sites like Stack Overflow, I found over time that the problems people were having tended more often than not to originate not in Emacs per se, but rather in the (mis)behavior of the various collections of packages that came with one or another of the "starter kits" then popular, and beset by the same fragmentation mentioned above. When you start out not with Emacs, but with Emacs plus a large collection of random packages tied together with customizations and init unique to the distribution, it's much harder to find useful information when something goes wrong, because there probably aren't all that many people using the same thing you are - and, being very new, you likely don't yet know how to have a productive conversation with Emacs itself, or even that such conversations are possible.
Conversely, when you have a problem with something that's part of Emacs, you're much more likely to find something or someone that can help you get past it, because ~everyone using Emacs is running the same code you are, and someone has almost certainly figured out how to solve the same problem before. Fragmenting the ecosystem makes this less likely; incorporating popular packages into Emacs, where that can be accomplished, makes it more so.
As a not very committed and not very expert Emacs user, I find annoying fragmentation in Emacs configuration not at the level of individual packages, but of fundamental mechanisms with inconsistent alternatives.
- defining customization groups and variables for one's package vs. not bothering and using semi-documented raw global variables (many actively despise the customization system)
- properly using the Customization pages vs. just overriding the variables in the init file
-packages that need to be built from a cloned Git (usually Github) repository, packages that want to be "installed" by hand, packages that use the "standard" package manager, alternative package managers, packages offering more than one of the above (or multiple sources with different versions)
- loading and configuring packages with require statements and setting variables; with use-package in self-contained blocks; implicitly or almost implicitly; in ad hoc ways.
Sometimes Emacs itself contributes to the mess; when I thought I exported my faces settings to a theme the "theme" file actually came to contain unrelated settings, preserving obsolete configuration of removed packages and amply overlapping and conflicting with the init file; now, for example, nyan-cat mode only displays a proper wavy trail if I use this magical theme. I'd need to spend hours dismantling the "theme" line by line.
- defining customization groups and variables for one's package vs. not bothering and using semi-documented raw global variables (many actively despise the customization system)
- properly using the Customization pages vs. just overriding the variables in the init file
-packages that need to be built from a cloned Git (usually Github) repository, packages that want to be "installed" by hand, packages that use the "standard" package manager, alternative package managers, packages offering more than one of the above (or multiple sources with different versions)
- loading and configuring packages with require statements and setting variables; with use-package in self-contained blocks; implicitly or almost implicitly; in ad hoc ways.
Sometimes Emacs itself contributes to the mess; when I thought I exported my faces settings to a theme the "theme" file actually came to contain unrelated settings, preserving obsolete configuration of removed packages and amply overlapping and conflicting with the init file; now, for example, nyan-cat mode only displays a proper wavy trail if I use this magical theme. I'd need to spend hours dismantling the "theme" line by line.
I agree that Emacs seriously suffers from "anti-Python syndrome" (or maybe a better term is just "Lisp syndrome") in that there's many ways to do a given thing and no immediately clear "best" option. However, while it may not be immediately clear, I think almost everything you mention here has a "pseudo-consensus" best option. Not something everyone does, but that most people do, and that you're most likely to see recommended as best practice.
- You should be defining groups and variables to provide better documentation and allow use of the interface. But you shouldn't actually use the interface to do customization (put it in your personal configuration files instead). The interface is both pretty annoying and disallows documentation of why exactly you're setting certain options.
- You use the standard package manager (package.el) and ELPA, MELPA, and maybe the Org repo. There are a few of these which will require external tools of some sort, in which case fair enough, that's an extra step. But that's still pretty standard in my view (although definitely doing that automatically would be great). I don't think I have any packages that require alternative package managers anymore.
- Use use-package. No real question at this point.
I do agree that themes are in general a nightmare.
- You should be defining groups and variables to provide better documentation and allow use of the interface. But you shouldn't actually use the interface to do customization (put it in your personal configuration files instead). The interface is both pretty annoying and disallows documentation of why exactly you're setting certain options.
- You use the standard package manager (package.el) and ELPA, MELPA, and maybe the Org repo. There are a few of these which will require external tools of some sort, in which case fair enough, that's an extra step. But that's still pretty standard in my view (although definitely doing that automatically would be great). I don't think I have any packages that require alternative package managers anymore.
- Use use-package. No real question at this point.
I do agree that themes are in general a nightmare.
From my experience as a developer and maintainer of several packages now available via MELPA and MELPA Stable, I can say with confidence that the standards for new package submission are quite high - indeed, my trips through that review process, and the excellent feedback I have on all occasions received, have taught me a great deal about how to build Emacs libraries and packages in a reliable, maintainable, usable fashion.
Unfortunately, there is a great deal of older Emacs Lisp code out there, much of which was not written to any perceptible standard whatsoever beyond "works on my machine lol ¯\_(ツ)_/¯". I say this not to disparage the people who wrote and released that code - indeed, a lot of what's in my own ~/.emacs.d, and which I use daily, comes of the same sort of origin. But either way, the Emacs ecosystem has a serious legacy code problem - something which, of course, you already know full well.
Unfortunately, there's no good single suggestion I can make here.
I can say that learning Emacs Lisp will make it easier to cope with nonsense like people unaccountably refusing to implement package configuration in terms of Customize, and with the occasional package where Customize legitimately isn't flexible enough to support everything that package needs to do.
But learning a whole new programming language, especially one that originates in a paradigm not familiar to most working programmers today, is a hell of a big ask as a prerequisite for effectively using an editor. My own experience is that it's well worth doing so - but if you're already frustrated with the nonsense you've observed, I can hardly blame you for deciding it's not worth your own while.
I can say that, well, it's just a matter of needing to invest the time to learn how to leverage this uniquely powerful tool, and not everything worth doing is easy - but, quite aside from being rude and insulting, such a claim has the same problem as the one I just talked about. I mean, I started using Emacs eight years ago, and it took me three or four of those to achieve something that can reasonably be called proficiency. That's a hell of a learning curve.
I can't reasonably say that the problems you're seeing don't exist, or result from error or misperception on your part rather than failure on the part of the ecosystem. (No one else can reasonably say that, either, and I misdoubt some have tried.) Among other traits, Emacs is older than the entire user interface paradigm that's become ubiquitous since 1985, and that makes many of its core metaphors seem either strange or strangely expressed. "Theme", for example, which everywhere else means a specific visual style packaged as a unit with a name, in Emacs means an entire set of Customize configurations packaged likewise. And then Emacs also, separately, has lately gained themes of the newer sort, with the same name referring to both! Of course it's a huge gotcha for the new user. And there are many more.
All I can say is: the Emacs core maintainers, and those of us building new packages for public release, are working the problem - doing our best to relieve Emacs of the manifold architectural and ecosystemic burdens which make it so easy for people to reasonably regard the platform and its partisans as relics of the past, and replace those legacies with a structure and culture sound enough to support Emacs' next 30 years. There's an almighty lot to do, and as with any free or open source project, never enough capable hands for all the doing. But as we can, we are.
Unfortunately, there is a great deal of older Emacs Lisp code out there, much of which was not written to any perceptible standard whatsoever beyond "works on my machine lol ¯\_(ツ)_/¯". I say this not to disparage the people who wrote and released that code - indeed, a lot of what's in my own ~/.emacs.d, and which I use daily, comes of the same sort of origin. But either way, the Emacs ecosystem has a serious legacy code problem - something which, of course, you already know full well.
Unfortunately, there's no good single suggestion I can make here.
I can say that learning Emacs Lisp will make it easier to cope with nonsense like people unaccountably refusing to implement package configuration in terms of Customize, and with the occasional package where Customize legitimately isn't flexible enough to support everything that package needs to do.
But learning a whole new programming language, especially one that originates in a paradigm not familiar to most working programmers today, is a hell of a big ask as a prerequisite for effectively using an editor. My own experience is that it's well worth doing so - but if you're already frustrated with the nonsense you've observed, I can hardly blame you for deciding it's not worth your own while.
I can say that, well, it's just a matter of needing to invest the time to learn how to leverage this uniquely powerful tool, and not everything worth doing is easy - but, quite aside from being rude and insulting, such a claim has the same problem as the one I just talked about. I mean, I started using Emacs eight years ago, and it took me three or four of those to achieve something that can reasonably be called proficiency. That's a hell of a learning curve.
I can't reasonably say that the problems you're seeing don't exist, or result from error or misperception on your part rather than failure on the part of the ecosystem. (No one else can reasonably say that, either, and I misdoubt some have tried.) Among other traits, Emacs is older than the entire user interface paradigm that's become ubiquitous since 1985, and that makes many of its core metaphors seem either strange or strangely expressed. "Theme", for example, which everywhere else means a specific visual style packaged as a unit with a name, in Emacs means an entire set of Customize configurations packaged likewise. And then Emacs also, separately, has lately gained themes of the newer sort, with the same name referring to both! Of course it's a huge gotcha for the new user. And there are many more.
All I can say is: the Emacs core maintainers, and those of us building new packages for public release, are working the problem - doing our best to relieve Emacs of the manifold architectural and ecosystemic burdens which make it so easy for people to reasonably regard the platform and its partisans as relics of the past, and replace those legacies with a structure and culture sound enough to support Emacs' next 30 years. There's an almighty lot to do, and as with any free or open source project, never enough capable hands for all the doing. But as we can, we are.
Thanks for the thoughtful answer.
1. Your main point is clearly correct. But the counterpoint is that it's not scaleable for the emacs core developers to take the responsibility of maintaining the code from every third-party package that seems useful enough to include. A few years ago I wrote quite a bit of code for org-mode, so I've seen how this works. The org-mode team prepares a release (err, no test suite though! At least not back then.) And then some weeks/months ahead of a major emacs release, the org-mode codebase at an agreed commit gets copied over into the emacs code base. But from that point on, emacs core devs are on the hook for any mistakes we made. That clearly doesn't scale to many packages. So what you said notwithstanding, the only viable option long term is to make the package management system excellent, and to make the API via which packages interact with emacs core excellent.
2. Yes to what you say about the "starter kits". But things have completely changed since then with the arrival of package management and package repositories.
1. Your main point is clearly correct. But the counterpoint is that it's not scaleable for the emacs core developers to take the responsibility of maintaining the code from every third-party package that seems useful enough to include. A few years ago I wrote quite a bit of code for org-mode, so I've seen how this works. The org-mode team prepares a release (err, no test suite though! At least not back then.) And then some weeks/months ahead of a major emacs release, the org-mode codebase at an agreed commit gets copied over into the emacs code base. But from that point on, emacs core devs are on the hook for any mistakes we made. That clearly doesn't scale to many packages. So what you said notwithstanding, the only viable option long term is to make the package management system excellent, and to make the API via which packages interact with emacs core excellent.
2. Yes to what you say about the "starter kits". But things have completely changed since then with the arrival of package management and package repositories.
Essentially the same argument as linux-style OS vs freebsd-style OS.
Its worth pointing out the analogy that most OS have git as an addon and have emacs itself as an addon. Once someone has gone to the effort of installing git, and installing emacs, installing magit isn't a noticeable or significant barrier.
Another interesting thing for non-emacs users to consider is this saves approximately zero time. A quick
grep -c use-package .emacs.d/init.el
shows I import about 36 packages and I'm kinda a minimalist emacs user. The most effort I could possibly save would be about 3%. Its not like I'm going to stop using cider or flycheck if magit is bundled.
Its worth pointing out the analogy that most OS have git as an addon and have emacs itself as an addon. Once someone has gone to the effort of installing git, and installing emacs, installing magit isn't a noticeable or significant barrier.
Another interesting thing for non-emacs users to consider is this saves approximately zero time. A quick
grep -c use-package .emacs.d/init.el
shows I import about 36 packages and I'm kinda a minimalist emacs user. The most effort I could possibly save would be about 3%. Its not like I'm going to stop using cider or flycheck if magit is bundled.
Is there any difference between use-package and require? I've been using require in my init.el.
require simply loads a feature, assuming it exists. use-package can do a whole lot more, including installing the package, configuring auto-loads, setting up key-bindings, pre- and post-load configuration, etc.
It's a third-party package itself at this point, but I believe it's going to be included in Emacs before too long.
It's a third-party package itself at this point, but I believe it's going to be included in Emacs before too long.
Think Python: One of the biggest strengths of the language was always the "Batteries Included" philosophy, which took Perl's CPAN idea (massively important for Perl's success, BTW) one step further and packaged common libraries into the base install. People got up and running faster, and Python prospered.
OTOH, another big strength is the near universal adoption of certain fast moving third party packages. For example, everyone uses Requests because it's better in almost every way than the built-in stuff, but because it's not included with Python its developer can move at a much faster pace.
What in the python standard library compares with the extraordinary diversity of functionality present in, say, org-mode?
That's a hard comparison to make, but I'm sure if the Python developers had a package they thought would be as well-loved as org-mode is among Emacs users, they'd package it in with the base install.
Magit is one of the most powerful pieces of software I use on a daily basis. It's incredibly well designed and I'd be seriously lost without it. That said, I think it's a good thing for MELPA and package.el in general that it's not built-in. It's a killer app, and I can only assume it encourages people to explore more packages.
I also totally agree with the post about contributing. Assignments aren't even the major issue, it's that with magit you can discuss issues, send a PR on GitHub and have a patch included in no-time. As part of Emacs, we'd have to go through mailing-list hell for any discussion and that's before considering the difficulties of actually getting a patch pulled in, at which point most people will have to wait for a new release? As part of MELPA I can update as soon as the PR is merged in.
Strange that people complain about the packaging system — I find it does the job and is super easy to get updates.
I also totally agree with the post about contributing. Assignments aren't even the major issue, it's that with magit you can discuss issues, send a PR on GitHub and have a patch included in no-time. As part of Emacs, we'd have to go through mailing-list hell for any discussion and that's before considering the difficulties of actually getting a patch pulled in, at which point most people will have to wait for a new release? As part of MELPA I can update as soon as the PR is merged in.
Strange that people complain about the packaging system — I find it does the job and is super easy to get updates.
As one of the small contributors (ranked #225 to be exact) I just became aware of this and emailed the FSF how I can assign them my copyright.
I'm not sure if this is a tedious process but I do believe that it is worth it in the end, when the FSF is able to legally defend this freedom.
I'm not sure if this is a tedious process but I do believe that it is worth it in the end, when the FSF is able to legally defend this freedom.
It's not difficult.
The process is described here: https://www.fsf.org/licensing/assigning.html
I've done this in the past for both Guile and Emacs.
For project maintainers it is a little bit more involved: https://www.gnu.org/prep/maintain/maintain.html#Legal-Matter...
I've done this in the past for both Guile and Emacs.
For project maintainers it is a little bit more involved: https://www.gnu.org/prep/maintain/maintain.html#Legal-Matter...
Magit is my one of my favorite Emacs packages. It's not entirely intuitive at first but once you get the hang of it, it streamlines the git workflow to a very pleasant interaction.
I highly recommend that anyone using Emacs and git gives Magit a try.
I highly recommend that anyone using Emacs and git gives Magit a try.
I gave Magit a try on Windows, and it failed miserably at finding git automagically. With no configurable option and no documented or at least easily hackable entry point, Magit was my quickest Emacs package removal.
Strange. It found git on my system automatically without any trouble.
Just because you did't make an effort to actually look for these things, that doesn't mean that they don't exist: https://magit.vc/manual/magit/Git-Executable.html.
What part of IGNORING THE PATH ENVIRONMENT VARIABLE you didn't understand? Magit is too clever for its own good.
From that link:
> This is necessary because Git on that platform comes with several wrapper scripts for the actual git binary, which are also placed on $PATH, and using one of these wrappers instead of the binary would degrade performance horribly.
That sounds like a good reason to be clever.
> This is necessary because Git on that platform comes with several wrapper scripts for the actual git binary, which are also placed on $PATH, and using one of these wrappers instead of the binary would degrade performance horribly.
That sounds like a good reason to be clever.
I can't imagine how painful it must be to develop software on windows.
Most of the pain comes from the fact that support for command line (and even things like concept of current directory) is bolted onto the win16 inspired win32 API as a complete afterthought.
Things that are implemented as command line utilities or call such commandline utilities (which includes Visual Studio and Windows SDK!) tend to cause these cludges to become painfully apparent.
Things that are implemented as command line utilities or call such commandline utilities (which includes Visual Studio and Windows SDK!) tend to cause these cludges to become painfully apparent.
If you've already learned to install and use Emacs, one more package aint gonna kill ya.
Whilst appearing even handed, in practice the article fails to mention a single reason for Stallman wanting the copyright assignment. I don't know what his reasons are, but he does tend to have thought through these issues carefully.
I think the article author assumes that the fact and the reasons for the FSF insisting on copyright assignment for its software are well known. https://www.gnu.org/licenses/why-assign.en.html has the answer, which basically boils down to "it ensures that there aren't going to be any awkward problems if the FSF ever needs to legally enforce the license."
I think you answered a different question from what GP was asking. The question for most people, which is answered in neither the article nor the email threads in emacs-devel, is why this stuff needs to be "in Emacs". What is wrong with it being a third-party package?
For example, these quotes from Stallman:
> We have a problem in Emacs: it doesn't contain a good interface to git. People often recommend something that is not in Emacs. That's not a good situation.
> When people ask here what they should do to use git with Emacs, the usual answer posted is "use Magit". Thus the problem: that the usual way people recommend to use Emacs with Git is via a package we have been unable to include in Emacs.
The obvious question is: what is wrong with using a package that is not in core Emacs?
https://lists.gnu.org/archive/html/emacs-devel/2017-07/msg00...
https://lists.gnu.org/archive/html/emacs-devel/2017-07/msg00...
For example, these quotes from Stallman:
> We have a problem in Emacs: it doesn't contain a good interface to git. People often recommend something that is not in Emacs. That's not a good situation.
> When people ask here what they should do to use git with Emacs, the usual answer posted is "use Magit". Thus the problem: that the usual way people recommend to use Emacs with Git is via a package we have been unable to include in Emacs.
The obvious question is: what is wrong with using a package that is not in core Emacs?
https://lists.gnu.org/archive/html/emacs-devel/2017-07/msg00...
https://lists.gnu.org/archive/html/emacs-devel/2017-07/msg00...
I love magit & git but emacs has seen many vcs come and go and I am not sure bundling it by default is crucial.
Who knows what vcs we'll be using in 10 years, let alone other specific packages that might follow the same route. I'd rather keep emacs core lean personally.
[deleted]
So like org mode and other packages they want to include magit in Emacs. Just got bigger but magit being such a great package I think they should do it. Hope the copyright assignment happens and FSF does it.
I saw this on Reddit, lwn and now here and I didn't see anyone comment on license upgrades. when FSF released GPLv3 they migrated a ton of software from one version to another.
although GPL is usually forward compatible with its newer versions I still wonder if that's the concern behind Stallman's opinion.
although GPL is usually forward compatible with its newer versions I still wonder if that's the concern behind Stallman's opinion.
This seems like an interesting idealogical argument to follow, but anybody using Emacs in the real world is going to just go ahead and install Magit. Nobody uses Emacs on the default settings anyways. Part of learning Emacs is sorting out your init file.
I tried for a long time to get Magit to work on OSX. Never could; anyone else? The way OSX was setup for emacs to hook into the git process was strange and not smooth for getting them to behave well together.
Works really well for me; zero effort to set up. Specific errors/point of difficulty would be interesting.
Also I hear plans are for it to switch to using libgit2.
Also I hear plans are for it to switch to using libgit2.
The number of people who use emacs, but also need a friendly front end for git has to be vanishingly tiny.
I think the appeal is more how it streamlines workflow, not how newbie-friendly it is. https://news.ycombinator.com/item?id=14819432
magit is the emacs killer app for me. It doesn't try to hide git in a generic VC interface, but it is really a self documenting, streamlined, alternative porcelain for the git plumbing.
Magit is the only thing that makes git usable to me.
the reason im not an emacs kind of person is that it comes with too many goodies. it becomes too complex. i have no need for org-mode and if i need a psychiatrist i can use a real one. including git wont help much. its almost as complex as Eclipse the way it is now. including some fancy git interface will not help matters.
so vim it is. if it does not have functionality i need i download it (or write it myself, easy enough). its a shame emacs is such a hodgepodge as i would definitely like to write new editor functionality using a lisp.
so vim it is. if it does not have functionality i need i download it (or write it myself, easy enough). its a shame emacs is such a hodgepodge as i would definitely like to write new editor functionality using a lisp.
I.e. you want to be able to program your editor in a Lisp, but nobody should upstream any such code into a distribution which accompanies the editor.
its fine if there are such distributions. i just dont think they should be the main distribution. by this i mean: i think the distro you get when you click the 'download editor' button on the site of the author of the editor or enter apt-get install editor, should eliminate these extras to avoid intimidating people too much and achieve a nice cleaned up aesthetic.
editors like emacs and vim are already have a steep learning curve without any extras and experts who need the extras will find them.
i am a great admirer of what stallman did for free software and i really like the idea of emacs. however i am also aware that its usage is declining. so i do believe taking a more critical look at his decisions is worth it.
editors like emacs and vim are already have a steep learning curve without any extras and experts who need the extras will find them.
i am a great admirer of what stallman did for free software and i really like the idea of emacs. however i am also aware that its usage is declining. so i do believe taking a more critical look at his decisions is worth it.
Right now Magit is hosted on Github and anyone can contribute by just sending a pull request.
If it were part of Emacs you'd need to use the FSF's collaboration tools which have a higher barrier of entry, and if you're a first-time contributor with a non-trivial contribution you're going to have to wait days/weeks as your copyright assignment papers make their way over snail-mail.
I've contributed several (trivial) patches to Magit, zero to Emacs itself, and would likely have contributed zero to Magit if it had been an FSF project to begin with.
I think the FSF has gotten their priorities seriously wrong. The package is already licensed under the GPLv3, they're wanting to subject everyone to a more onerous contribution process to guard against the edge case of someone ripping off one specific Emacs package and the FSF not being in a position to have standing in court if they wanted to sue them.