Sad to see this outdated info in the top comment.

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?

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.

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?

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.

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.

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.

[1] https://www.assuresign.com/electronic-signatures-vs-digital-...

Obviously, people selling centralized document storage and electronic signature services are incentivized to obfuscate this as much as possible.

> 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

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?

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

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.

Are you erring on the side of legal caution? 'Cause I assure you the FSF is.

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

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.

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

I still hate when I'm asked to do this but it's vastly more convenient than actually printing and scanning a form.

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.

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.

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.

https://git.savannah.gnu.org/cgit/emacs/elpa.git/tree/packag...

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.

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

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.

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

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.

Though Magit seems maybe a bit of a weird thing to be using on a minimal remote system.

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.

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.

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.

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.

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.

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

Same case with orgmode.

I.e., it can only be called a low barrier to entry if you're willing redefine "entry" to be something other than "entry".

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.

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

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 ?

The FSF's copyright assignment contract has clauses that prevent them from doing such things. It's really a very fair contract.

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

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.

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?

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.

And can I enforce copyright for those exceptions?

Clearly not, because the FSF owns the copyright.

Then it's not my code, and I don't have rights on it, do I?

I can't edit my comment; sorry. I meant "your project's code".

I believe so - as long as you license it with the GPL.

Oh, wait. Perhaps if those contributors assigned their copyright to you under a very permissive contract...

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

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

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.

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?

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

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.

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.