10 ms·

If it were to be accepted into Emacs itself that would only be the beginning of the story. Right now Magit is hosted on Github and anyone can contribute by jus

by avar 9y ago

If it were to be accepted into Emacs itself that would only be the beginning of the story. 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.

danieldk 9y ago
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.
sillysaurus3 9y ago
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.
- kronos29296 9y ago
  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).
  - deleted 9y ago
    [deleted]
- throwanem 9y ago
  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.
- aerique 9y ago
  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.
  - ethelward 9y ago
    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.
- tangue 9y ago
  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 ?
  - davexunit 9y ago
    >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.
    - mikegerwitz 9y ago
      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.
      - tangue 9y ago
        Ok this seems more reasonnable than I thought.
jonathanstrange 9y ago
Why would it be important to distribute Magit as part of Emacs? Why not just install it via MELPA?
- gh02t 9y ago
  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.
  - Myrmornis 9y ago
    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 apt-get install emacs-core-plus-standard-packages or apt-get install emacs-core emacs-magit emacs-org-mode i.e. people produce linux packages that set up emacs with its MELPA packages. 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.
  - Grue3 9y ago
    There's no need to install Magit on remote systems. It works flawlessly over TRAMP and I use it every day like that.
- 0xcde4c3db 9y ago
  > 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.
josteink 9y ago
> 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.
- adekok 9y ago
  If they make it harder to contribute, you're guaranteed to get fewer contributions.
- torrent-of-ions 9y ago
  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).
tarsius 9y ago
> 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 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.
- ivanbakel 9y ago
  >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.
  - kingbirdy 9y ago
    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.
    - ivanbakel 9y ago
      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.
torrent-of-ions 9y ago
A higher barrier to entry or a different barrier to entry. Nobody was born with the ability to "just submit a pull request".
- carussell 9y ago
  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".
adekok 9y ago
> 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".
- jordigh 9y ago
  > 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.
mikegerwitz 9y ago
> 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-gpg-signed-assignments-from-the-u-s 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-gpg-signatures-for-copyright-assignments-from-italy https://www.fsf.org/blogs/licensing/fsf-to-begin-accepting-g...
- IanKelling 9y ago
  FSF assignments have had full digital support in every country since 11/2016. https://www.fsf.org/blogs/licensing/fsf-now-offering-paperless-option-for-all-copyright-assignments https://www.fsf.org/blogs/licensing/fsf-now-offering-paperle...
davexunit 9y ago
Copyright assignment papers no longer need to be sent over snail mail in most cases.
e40 9y ago
Other projects have git access (outside the Emacs review process) and are included in Emacs. MH-E, for example.
IanKelling 9y ago
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-paperless-option-for-all-copyright-assignments https://www.fsf.org/blogs/licensing/fsf-now-offering-paperle... Sad to see this outdated info in the top comment.
- xyzzy_plugh 9y ago
  > 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?
  - throwaway287391 9y ago
    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.
    - confounded 9y ago
      This is a legit/acknowledged way to meet the FSF's requirements.
    - problems 9y ago
      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.
  - 9y ago
ungzd 9y ago
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 https://bugs.ruby-lang.org/projects/ruby/wiki/StdlibGem.
- BeetleB 9y ago
  Yes, although you'll always have the option to install updates from Github. Same case with orgmode.
tmalsburg2 9y ago
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.
wbolster 9y ago
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).

by avar 9y ago

danieldk 9y ago

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.

sillysaurus3 9y ago

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.

kronos29296 9y ago
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).
- deleted 9y ago
  [deleted]
throwanem 9y ago
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.
aerique 9y ago
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.
- ethelward 9y ago
  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.
tangue 9y ago
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 ?
- davexunit 9y ago
  >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.
  - mikegerwitz 9y ago
    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.
    - tangue 9y ago
      Ok this seems more reasonnable than I thought.

jonathanstrange 9y ago

Why would it be important to distribute Magit as part of Emacs? Why not just install it via MELPA?

gh02t 9y ago
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.
- Myrmornis 9y ago
  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 apt-get install emacs-core-plus-standard-packages or apt-get install emacs-core emacs-magit emacs-org-mode i.e. people produce linux packages that set up emacs with its MELPA packages. 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.
- Grue3 9y ago
  There's no need to install Magit on remote systems. It works flawlessly over TRAMP and I use it every day like that.
0xcde4c3db 9y ago
> 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.

josteink 9y ago

> 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.

adekok 9y ago
If they make it harder to contribute, you're guaranteed to get fewer contributions.
torrent-of-ions 9y ago
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).

tarsius 9y ago

> 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 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.

ivanbakel 9y ago
>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.
- kingbirdy 9y ago
  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.
  - ivanbakel 9y ago
    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.

torrent-of-ions 9y ago

A higher barrier to entry or a different barrier to entry. Nobody was born with the ability to "just submit a pull request".

carussell 9y ago
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".

adekok 9y ago

> 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".

jordigh 9y ago
> 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.

mikegerwitz 9y ago

> 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-gpg-signed-assignments-from-the-u-s 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-gpg-signatures-for-copyright-assignments-from-italy https://www.fsf.org/blogs/licensing/fsf-to-begin-accepting-g...

IanKelling 9y ago
FSF assignments have had full digital support in every country since 11/2016. https://www.fsf.org/blogs/licensing/fsf-now-offering-paperless-option-for-all-copyright-assignments https://www.fsf.org/blogs/licensing/fsf-now-offering-paperle...

davexunit 9y ago

e40 9y ago

Other projects have git access (outside the Emacs review process) and are included in Emacs. MH-E, for example.

IanKelling 9y ago

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-paperless-option-for-all-copyright-assignments https://www.fsf.org/blogs/licensing/fsf-now-offering-paperle... Sad to see this outdated info in the top comment.

xyzzy_plugh 9y ago
> 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?
- throwaway287391 9y ago
  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.
  - confounded 9y ago
    This is a legit/acknowledged way to meet the FSF's requirements.
  - problems 9y ago
    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.
- 9y ago

ungzd 9y ago

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 https://bugs.ruby-lang.org/projects/ruby/wiki/StdlibGem.

BeetleB 9y ago
Yes, although you'll always have the option to install updates from Github. Same case with orgmode.

tmalsburg2 9y ago

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.

wbolster 9y ago

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).