Hacker News Reader

Comment by avar | Hacker News Reader

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.

View on HN

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.

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

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.

This is a legit/acknowledged way to meet the FSF's requirements.

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.

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?

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.

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

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.

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.

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

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.

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

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

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.

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

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

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

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

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 assign@gnu.org. 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.

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.

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.

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

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

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

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.

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.

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

If they make it harder to contribute, you're guaranteed to get fewer contributions.

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

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

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.

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.

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

  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.

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.

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.

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.

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.

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

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.

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.

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

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.

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

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.

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 ?

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

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.

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

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.

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.

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

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?

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

Yes, you lack standing. The FSF owns copyright.

Is it legally possible to share copyright?

> I hope parent commentor clarifies this

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

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

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?

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

No, the FSF would have to.

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

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

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.

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

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.

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.

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.

Reply on news.ycombinator.com