Hacker News new | past | comments | ask | show | jobs | submit login

I'm on the GNU maintainers team; I want to clarify a couple things about this:

First, Nano has _not_ left the GNU project; GNU Nano still does and will continue to exist. The current maintainer of GNU Nano---Chris Allegretta---was hoping to add Benno Schulenberg as a co-maintainer, citing numerous contributions by him. Unfortunately, Benno refused to accept GNU's maintainership agreement, and so was not appointed. Benno also did not want to assign copyright to the FSF for his contributions.

Instead, it seems, Benno decided to fork the project. But he did so with hostility: he updated the official GNU Nano website, rather than creating a website for the fork.

It's early, so there's still discussion going on, but again, to be clear: GNU Nano has absolutely not left GNU.

I don't know anything about the politics involved, and I don't even use nano (vim guy myself), but I just ran this out of curiosity:

    zx2c4@thinkpad ~/nano $ git shortlog -sne --since '3 years ago'
      1298  Benno Schulenberg <bensberg@justemail.net>
        64  Chris Allegretta <chrisa@asty.org>
         6  Jordi Mallach <jordi@gnu.org>
         3  Mike Frysinger <vapier@gentoo.org>
         3  Mike Scalora <mike@scalora.org>
         2  Rishabh Dave <rishabhddave@gmail.com>
Seems like Benno is clearly the driving force behind the project.

Why only 3 years ago?

Maybe 10 years will be little more accurate?

  git shortlog -sne --since '10 years ago'
    1298  Benno Schulenberg <bensberg@justemail.net>
     481  David Lawrence Ramsey <pooka109@gmail.com>
     382  Chris Allegretta <chrisa@asty.org>
      28  Jordi Mallach <jordi@gnu.org>
       3  Mike Frysinger <vapier@gentoo.org>
       3  Mike Scalora <mike@scalora.org>
       2  Rishabh Dave <rishabhddave@gmail.com>

  git shortlog -sne --since '15 years ago'
    2528  David Lawrence Ramsey <pooka109@gmail.com>
    1298  Benno Schulenberg <bensberg@justemail.net>
     803  Chris Allegretta <chrisa@asty.org>
     355  Jordi Mallach <jordi@gnu.org>
       3  Mike Frysinger <vapier@gentoo.org>
       3  Mike Scalora <mike@scalora.org>
       2  Rishabh Dave <rishabhddave@gmail.com>
       1  Rocco Corsi <rocco.corsi@sympatico.ca>
Well, now looks little different...

2001 was when Windows XP was released. That's at least a few "eras" in computing ago.

Any open source project is only as good as it is today not what it was.

If you like to test it, I would be very interested in the result of trying to get linux running with only code written from the last 3 years. I would assume that almost a majority of the code would be there, but then I would also assume that most of the essential core is basically untouched except for security patches. It would make for a very interesting read and a HN worthy article.

Have kernel images doubled in the last years?

Then again, in many orgs XP is barely being replaced with Windows 7...

With a record like that I think he should be allowed to do whatever he pleases with the project.

I don’t think so. With that argument, anyone could take over any project just because he/she has more free time than the current maintainer.

Would you want someone who steps up and does a lot of work in a project you started to suddenly tell you that he/she will now change the vision of the project and turn it in ways you don’t like?

Let’s assume that you take your time to write clean code, do changes slowly and deliberately and think long about how to do something right before you start coding. Then someone steps up and does lots of cool things in a flurry of activity, but does not do them right and you already see the maintenance fallout from that approaching. Would you want that contributor to take over the project and use the name you established for this new kind of project?

As a non-programming example: I’m writing a roleplaying system, and it took me several years to get from EWS-2.6 to having the concepts for EWS-3.0 nailed down — though without having finished text. If someone came in and did lots of work, I would still not want to see an EWS-3.0 which violates core principles I set down for the system. People are free to do that, but they have to do that in their own space, not in the space I created.

Also changing the name all over the source code in the main version tracking repository is a pretty hostile step. It implies that the other one now considers the project his/her own.

Essentially Benno should have made a bano, but I think that just turning GNU nano into his own project isn’t OK.

Isn't that the idea of open source software? The best maintainer is the one in charge.

I don't think Linus would object to someone replacing him if anyone was more qualified for the job. Hell he even openly encourages people to fork Linux, make improvements, and follow the license (copy left).

I see nothing wrong with the most active/best maintainer having say over the project's future.

> Isn't that the idea of open source software? The best maintainer is the one in charge.

No, not really. Open source embraces the idea of forking - a hostile take over of the original project is most definitely not the idea - but it can be allowed depending on the projects charter.

Also - most active contribute =/= maintainer - I'm sure Red Hat adds more code to the kernel than Linus these days, but Linus is still the 'decider'.

To conclude, Benno is free to fork GNU Nano, but it will not be GNU Nano - he can call it 'New Nano' if he likes.

Pretty much. Especially if one i trying to introduce major changes.

Edit: That said, there seems to be more hostile takeovers happening these days. Perhaps because a new gen of devs care as much, or more, about brand as about code quality...

Arguably, if the situation is the one described, I'm not sure what "the best maintainer" is. :(

Changing name and leaving the old project eventually die or be subsumed by the fork (like egcs did with gcc) would have probably been a better choice.

> Isn't that the idea of open source software? The best maintainer is the one in charge.

There is no reason why the first sentence should imply the second.

Of course he can do anything he pleases with nano. (So can you, and so can I.) He just doesn't get to do anything he pleases with GNU nano.

Committing to an existing project doesn't give you exclusive license rights over the project.

It's free software, everybody is allowed to do whatever they please with the project. GNU doesn't have to support or endorse it, though.

I think he should have renamed the project when he forked it. This sounds disingenuous to me.

Was it really necessary to also publish their email addresses?


Edit: I know the addresses appear in the Git repo. But they are not accessible to web crawlers over HTTP. Most code hosting services require a login to see them as a spam control measure. Which is also why I think they should be obfuscated at least.

They are more accessible here on HN, though, because crawlers that obey robots.txt will not see it on git.savannah.gnu.org but will see it here on HN.

I suspect that if a crawler is being used to farm email addresses for spamming, it's highly unlikely that robots.txt would be any deterrent whatsoever.

Spammers' crawlers use URLs obtained from search engines and public sources. If the whole directory is blocked in robots.txt, it WILL reduce crawling activity massively.

I did not know that about Savannah. I am mainly familiar with Github, Bitbucket and Launchpad. I guess there is no point hiding from the bots these days.

Why is everyone so uptight about their emails being public? If you're planning on doing free software development in public, your email is going to have to be publicly available anyway (otherwise people can't contact your for legitimate reasons). Spend the 15 minutes it takes to set up SpamAssassin and then get on with your life.

SpamAssassin is about as effective as wet scotch tape.

The existence of your e-mail address in public does not grant members of public permission to Republish or use however they please outside its intended purpose.

Community standards say this information is mangled before republishing to the web, Otherwise, if you post someone's e-mail address, you are aiding and abetting spammers.

At the very best, It is highly inconsiderate to republish, and in other cases, may result in legal actionw, as in suit for damages against the person who republished your e-mail address.

I mean, they're right there in the git log

Publish? It's public already.

Spammers are already using emails from git repositories, especially from Github.

For whom is spam actually a problem? Filters are absurdly good.

Depends on the email service. Colleagues of mine who work at military research lab have their emails filtered to junk in my email but then I routinely receive email notices in my inbox from university emails warning me my "Account is expired/full/overdue" and I must take immediate action by clicking on a link.

Hint: I think gmail filters are good. The rest? Not so much.

They are, if you can get them. Until recently my employer was using a mail provider that had seriously neglected their product. The spam filtering was atrocious, so I tried to avoid giving out my work email as much as possible.

(Thankfully we finally switched to another provider because the old one refused to support DKIM or even STARTTLS to other MX servers.)

It can be additional work for people self-hosting their mail. But I base that on my own experience many years out of date.

2 orders of magnitude more commits? Yes, agree. And the argument that claims "a flurry of activity" doesn't wash. This is a bit more than a flurry.


But if a or the driving force of a project takes things elsewhere, the users will eventually follow. If the disagreement was over GNU's insistence to require assigning copyright to the FSF, then I can fully understand the reluctance. It's the same reason many contributors cannot officially submit patches to side projects of Google employees, Ubuntu projects, etc.

Just to be clear on this, Google projects (including side projects of Google employees) do not require copyright assignment in the way that FSF projects to. They require an explicit copyright license, but the author retains the copyright. Full details at https://cla.developers.google.com/about

Interesting, thanks for the correction.

Reading that page, it appears that this due to US IP ownership agreements for employees. Is that correct?

If so, why isn't there an exception for personal-time-only contributions by single developers, or at least those outside a jurisdiction like the US where an employer may own each and all of your ideas and intellectual output? To be clear, I haven't lived or worked in the US, so this is all foreign and weird to me.

US Copyright defaults to the author, it is only with employee contracts/agreements that one can forego the default and assign to the company. Something like the google license is there to help with making a clear distinction between google-owned copyright, author-owned copyright and author-owned copyright permanently licensed to google. Meaning that google will never be required to pay any kind of royalties for the author's work even after they leave employment at google.

> US Copyright defaults to the author, it is only with employee contracts/agreements that one can forego the default and assign to the company.

I'm pretty sure this is not true. In fact, it's the opposite of how it actually works. There's an explicit exception in the Copyright Act for a "work made for hire". If you're creating a opyrighted work for an employer, the employer is always the author of the work at the moment of inception.


I always line out those sections of employee agreements... Fortunately, haven't had a problem with it yet.

There are separate state laws, iirc such as California, which makes parts of those kinds of provisions void.

If you mean striking through some sections in contracts too, but wouldn't you have to do it in both copies to have some level of confidence? I cannot imagine you can do this with, say, an ISP contract where you don't agree with some clause.

In the past I've had contracts reprinted after pointing out errors in them.

If it's got my physical signature on it, I've blacked/crossed out the offending sections... recently, even an "online" contract had the option to blackout portions, which I thought was a pretty cool feature.

So, yes, if it's a copy with my signature, it has the offending pieces crossed out.

FSF copyright assignment is done such that they state they will always distribute your code under a copyleft license. So it's not an issue like with Canonical (which asks for the right to make copyleft code proprietary). Copyright assignment is important if you register your copyright to make strong enforcement possible. US copyright law doesn't deal with communities of contributors very well, in terms of those copyright holders exercising their rights.

It’s the current maintainer who wants copyright assignment. He does not want to hand over the project to someone who refuses to lead it in a way consistent with his vision.

Rather walk more slowly than walk in the wrong direction.

Isn't that even worse then? I mean, the FSF has a good track record and less people would object to assigning copyright over to the org.

As far as I can tell, the current maintainer wants copyright assigned to the FSF. He is not willing to hand the project over to someone who isn't willing to do that.

The proposed new maintainer is not willing to assign copyright to the FSF, and so seems to be forking the project instead.

But it's not 100% clear exactly what's going on.

Do you know that according to copy rights, open source projects are mess. Nobody tried it in the court, but if some developer contributing to project went to court saying "This part of code is mine, I don't want it to be modified by other people", then the project could be in trouble. Nobody tried that (yet).

That's why some OS projects require signing Developer Certificates of Origin etc.

The way I see it, if you contribute to a project for example by sending a patch to it by email or pull request then you agree to be bound by the license. Even if there is no copyright assignment. Otherwise you would not have the right to modify the software to write your patch in the first place. This just seems like common sense to me.

The problem is if the maintainer wants to change the license (Like GPL2 -> GPL3). That's only possible if the contributors have signed over copyright, or the maintainer can track down every person who ever sent a patch, and get them to agree.

I've been struggling with this question as well. If you want to maintain full control of your project, then you want any contributors to assign copyright, because it gives the maintainer the most flexibility.

On the other hand, as happened here, it makes people less likely to want to contribute to the project, because they probably feel like they are being taken advantage of or losing some right.

A counter argument to that, anyone is always free to fork the project, again, what happened here, but this has the obvious undesirable effect of splitting development effort.

> it makes people less likely to want to contribute to the project, because they probably feel like they are being taken advantage of or losing some right

I think it depends who the copyright is assigned to. I imagine people will have strong reservations about transferring copyright to a private company or individual.

But if the copyright is assigned to a mutually trusted organisation like a FLOSS foundation then I can't think of a good reason that a contributor would withhold copyright assignment.

They have nothing to lose and the project they care about will gain. There are even tools nowadays like CLAHub to make the process more convenient.

One exception might be corporate restrictions on contributors. Like if you need permission from your boss and it is denied.

I think the bigger issue with FLOSS projects is that often people are not always able to agree on an acceptable organisation to own the copyright let alone the kind of license to have.

> But if the copyright is assigned to a mutually trusted organization like a FLOSS foundation then I can't think of a good reason that a contributor would withhold copyright assignment.

How would one know beforehand what kind of license it will be re-licensed under in the future, and what kind of legal action that assigned copyright holder will take, which you may not agree with? You make valid arguments, but it's not that simple.

As a contributor it's easy to argue that there's no reason for something one contributes under license X to be put under license Y two years later without consent (not required in this case).

Copyright assignment isn't binary. It's a contractual agreement like anything else. You can make requirements like "it will always be under copyleft" (which is what the FSF and some Apache projects do). You should avoid projects that ask for blanket copyright assignment on a copylefted work.

> it's easy to argue that there's no reason for something one contributes under license X to be put under license Y two years later without consent

The problem isn't for the individual contributor, it's the project itself. Let's say for some reason you use Apache 2.0 and then decide you want to add MIT for better compatability with other license. You as the maintainer solicit from all contributors they're approval and you get 99/100, one person holds out and blocks it. What do you do in this case? Go back and remove all their contributions such that you can then continue with the general agreement?

A clause I've been considering, if it doesn't exist somewhere, is to have a majority rules portion to the agreement. But I'm not sure if this works without assigning copyright to the project.

> What do you do in this case? Go back and remove all their contributions such that you can then continue with the general agreement?

Yes, that's what you do, and it's the same in other industries.

For example, when Erlang/OTP contributors were asked to accept re-licensing under Apache2, a couple patches submitted by Netflix's Rick Reed were reverted prior to re-licensing because they didn't sign off.

The license is for all parties, not just to get contributions and then later do with it what you want. If that's how the project is governed, then the license has to reflect that (GPL3 or later) or a CLA must be in place. When that's clear, it's evident to contributors and many will refuse to contribute.

The whole point is to choose someone that you believe will make appropriate licensing decisions, both now and in the future. And that requires trust in the copyright holder. You cannot perfectly guarantee they will always do the right thing. But the legal structure of the organization can often reduce the risk of that.

I mostly agree, but unlike other legal agreements, contributing to a project under a FOSS license is not usually coupled with an expiry date after which there's room for radical re-licensing.

This is a really great point. Should there be a pay-to-play portion on these, e.g. Your copyright will "expire" and revert to the project(?) Should you not commit changes for a period of 2 years.

The MAME project is an example of the the latter happening successfully.

I don't think GPL2 -> GPL3 is a valid example of that. Usually it is to dual-license with a non-open-source license or some other incompatible open-source licenses.

The GPL "upgrade" clause,

> Each version is given a distinguishing version number. If the Program specifies a version number of this License which applies to it and "any later version", you have the option of following the terms and conditions either of that version or of any later version published by the Free Software Foundation.

I think you missed the if clause:

> If the Program specifies a version number of this License which applies to it and "any later version",

I'm no lawyer, but I think the source has to mention that explicitly. So it's not true of ALL gpl projects. In this case though you are right because nano, it appears, specifies it's license as:

> License: GNU General Public License v3 or later

So, while true in this case it's not always true (see Linux kernel license, GPLv2, no upgrade).

Most GPL projects do this. I don't have access to my box, but if you did a search for licenses you'd find many use "or later" (and in fact a lot of code within Linux uses "or later" as well). So practically it's a very common upgrade path. And some people will actually email every contributor to ask to relicense the code.

Dual-license with a proprietary license is not allowed by the papers you sign when assigning copyright to the GNU project.

»We promise to always keep the software free. This promise extends to any successors in the copyright, meaning that even if the FSF were to go away the freedom of all users to share in the contributions wouldn't.« — https://www.fsf.org/bulletin/2014/spring/copyright-assignmen...

This is the difference between copyright assignment to the FSF and most other copyright assignment.

While surely better than Google or Ubuntu, the new license can still be non-proprietary but highly controversial.

If that happened, people could fork the projects immediately and continue under the old licenses. Sure, the FSF would be able to distribute code in an unfriendly license, but the community backlash would be so bad they wouldn't even consider doing that.

If your licence is GPLv2 only (like for example the linux kernel), there is NO upgrade path.

Mercurial went the hard road and asked all contributors to relicense under GPLv2 or later.

Actually, a lot of code in the Linux kernel is GPLv2-or-later. Its just that there's a lot of GPLv2-only code that means the final product is GPLv2-only. In fact there was a time when Linus asked people to show their opinion on the licensing exactly by doing that and specifying in every file what the author licensed their changes under.

It's possible that this has been 'fixed' with GPL3. I just know Linus used it as a reason not to change the license of the Linux kernel.

Linus explicitly opted out of the "or any later version" clause because he doesn't agree with the ideals of free software (seeing it as more of a practical convenience). All versions of the GPL have had an upgrade clause, mainly so that GNU projects can upgrade the license.

Not to mention that much of the code inside Linux is under GPLv2-or-later, but because some of it is GPLv2-only the whole work is GPLv2-only.

Out of curiosity, how much code is actually GPLv2 only, and how hard would it be to replace those sections with code that was GPLv2+?

A lot of the core code (and dissapointingly, btrfs) is GPLv2-only. So rewrites are unlikely, you'd have to ask contributors to update the license.

Just do a grep for "at your option", since that's the wording in the copyright header to specify that it's released under GPLv2-or-later, tells me that it isn't that great. It's around 10000 files (Linux has ~50000 files) so it's ~20% of files. This doesn't account for documentation or files that don't specify that they are under GPLv2-or-later.

Was there any specific reason that license was chosen for btrfs that you know of?

My guess is >Oracle. They want to make the minimum possible community contribution.

Note: I just realised that I licensed kernel/cgroup_pids.c under GPLv2-only. which is wrong. I've sent a patch that also includes a fix to that header.


That's not true. If your project is licensed under "GPLv3 or later" then you can relicense the project under GPLv4 when it comes out. This is the whole point of the "or later" clause in the GPL. It is also not true for lax licenses like MIT or Apache, since they allow sublicensing.

You can also use a Fidiuciary Licence Agreement, like for example KDE: https://ev.kde.org/rules/fla.php

[I am not a lawyer. I've written and signed and worked under many contracts where the details of copyright are critical to the transaction]

The US and some other jurisdictions use common law. It may be the case that common law is a subset of common sense intended to deal with issues of scale and perpetuity. It may not. Even among common law jurisdictions, copyright laws vary.

In the US, the default stance is that the author of a work owns the copyright. Hence, without explicit reassignment, contributing does not transfer copyright. As an aside, in the US, copyright does not transfer just because money changes hands either [though it generally does in cases of statutory employment].

What matters is the way the law sees it.

In most countries law does not `see` GPL. Law sees authorship. And in open source projects the authorship is not clear. You can be 5% author of the code. So be careful what you are doing with the code.

No, the courts have already handled cases around the GPL


These are about violation of GPL, none of the suits was filed by individual developer who was contributing to the code base. Show me better examples.

> none of the suits was filed by individual developer who was contributing to the code base

(You're not implying otherwise, but this seems like a good place to put this comment.)

An individual developer can bring a case against a distributor violating the GPL if they can prove that their code was involved in the violation.

A good example are the contributors who brought a Linux (kernel) case against VMWare:


> none of the suits was filed by individual developer who was contributing to the code base

Isn't that what actually happened in the GPL-Violations.org project with netfilter?

It makes me happy to see this. But still I'd advise using developer agreements, if you want the control of the project. And correct license of course!

And it's proof that like Oracle suing Google over 10 lines of code, it's enough for one or more contributors to claim ownership of some (small) part as a basis to take, say, Netgear to court. Thus you don't necessarily need to assign copyright over to a single person or organization.

What I meant here, is not that GPL was not tested in court. Just imagine situation of one of the authors saying: I no longer want to see my code on the Internet. Let's say he contributed 30% of the code. Now what? He is the author, he has the right to do it. In most cases developers sign no agreements when their patches are merged.

> I no longer want to see my code on the Internet.

Such a statement doesn't make sense. Not to mention that you can't retroactively un-license something (unless the license has a termination clause). Free software licenses do not have termination clauses (by definition, the FSF won't approve them if they do because it restricts practical freedom). Though I'm fairly sure it would count as an "open source" license under the OSI definition.

> In most cases developers sign no agreements when their patches are merged.

If you submitted code under the DCO, you've signed an affadavit saying that you have the right to license the code and that it is licensed under the license of the project. For copyleft projects, you don't even need that (if you've distributed it then you've implicitly licensed it under the original license). But in either case, once you've licensed you code under some license then you can't terminate that license if it's a free software license.

I don't fully understand. You cannot take back your public contribution, just as you cannot ask the patent office to erase the patent from all records and have everyone aware of it forget about it, and remove each and all references that build on that patent.

The world would be a much different place if smart people in the past hadn't invented Copyright and Patenting, which both are mostly being misused and are not used to foster innovation. Back then it was normal to hold onto secrets and patents and copyright were invented to incentivize publication under well-defined and not too long exclusivity periods after which other can freely improve on it. But today we have 20 year patent monopolies and Disney copyright absurdity.

If the code is under a copyleft license, then distributing a modified copy is only possible by complying with the license. So at the very least, you can get the code under that license. Non-copyleft licenses might fall into a worse trap here, but that's why we have the DCO. An affidavit is more than enough.

> GNU Nano has absolutely not left GNU.

Right, it's just that all the new revisions of Nano that anyone will use going forward have left GNU.

Correct me if I am wrong here, but it sounds like GNU project requires that either all code is assigned to FSF, or none and then the project need to enforce copyright themselves. In this case, the current maintainer want to assign copyright, the new co-mainter don't, and thus the project got an internal conflict between the maintainer and co-maintainer. The hostility is thus primarily between the two maintainers, rather than between GNU and Benno.

It seems to me he's not forking. He's leaving GNU.

That you intend to continue having a "GNU nano" doesn't change that. Just because it happened to be on your web space doesn't make it your project.

A project is first and foremost the people behind it. Not a hosting provider.

I consider you the fork. Without hostility.

Edit: I may have missed/confused the acting people here. I'm not sure anymore if my comment above really hits the nail on its head.

> I consider you the fork. Without hostility.

Nano has been part of the GNU Project since 2001, and Benno has been contributing to that project for years.

I agree - if he wanted to fork, he should created a new website.

The copyright assignment requirements in GNU projects point to the GPL not being good enough, thereby undermining it.

They are obviously rooted in the fear that in fact the FSF cannot use code that is merely GPL-ed, if someone else owns the copyright.

"Use the GPL for your code to grant everyone rights and freedoms. Just not when giving to us; we would prefer your right, not your left, thank you very much."

There is a legitimate concern that someone apparently placing code under the GPL might not have the right to do so. But for that, an affidavit should be good enough, not an affidavit plus assignment of copyright to the FSF.

The paranoid copyright assignment obviously guards against the possibility that a rightfully proclaimed GPL can be retroactively revoked. Someone in the project changes their mind and says that these pieces which are wrote are no longer GPLed; not going forward, nor in any past revisions. (That author him or herself, not some previous employer or other third party, from whom permission had not been properly obtained to have that work under the GPL.)

If the FSF believes this to be a real threat, any group of users anywhere relying on the GPL should take the same view.

GNU copyright assignment is to make enforcement actions possible[1]. In the US, copyright law doesn't really give a community much power to enforce their copyright claims. The GPL is not weak because of this, it's just how the FSF operates. The SFConservancy doesn't have this requirement for projects they support, but it's clear that the FSF lawyers believe that having copyright assignment makes enforcement much more powerful.

As for "taking away people's freedom", the copyright assignment explicitly states that your contributions will always be under a copyleft license. So you're not losing any protection of the GPL if you contribute to GNU. That's just an insane proposition.

[1] https://www.gnu.org/licenses/why-assign.en.html

There is a much less paranoid reason that an organization like the FSF might want copyright assignment. Suppose I take some portions of a GNU project program and incorporate them into my proprietary program. The FSF takes umbrage at this, and sues me for copyright infringement.

Without copyright assignment, I'm going to go over every single piece of code they say I took and I'm going to allege that the FSF does not have standing to sue because they are not the copyright owner for that particular piece of code. They will have to prove that the pieces of code they are suing over are just ones that they have the copyright on. The accuracy of how they track code ownership will become an issue, and I'll get to annoy their admins and IT guys with depositions about all that. It makes the lawsuit much messier and annoying to the FSF. Or maybe they can add all the contributors as plaintiffs, if they can get them to agree, and that would blunt my ownership arguments, but now I get to hassle all the contributors with depositions!

If the FSF owns the copyright on the whole program, all of that crap goes away. They just file copies of the copyright assignments with their lawsuit. If I want to seriously question their right to sue over some of the code after that, I'm going to have to find a way to argue that the assignment was invalid, such as arguing that the contributor did not have the right to assign copyright. That is going to take a lot of effort on my part (or on my bank account's part to pay investigators), and if the FSF was reasonably careful it is unlikely to pay off for me.

In summary, if you take code from other people AND you intend to legally try to enforce your license, then you probably should get copyright assignments. If you don't intend to enforce the license, then there is much less need.

The FSF is at least as much a political organization as it is a technical organization, and to achieve their political goals they need to enforce GPL, so they need copyright assignment.

If I, on the other hand, were to release a project under GPL, I would not care at all about enforcing GPL. I normally use a BSD license, and the only likely reason that I would be releasing a project under GPL is that I wanted to use someone else's GPL code in my project and so used that license to allow this. Hence, there would be no need for me to ask for copyright assignment.

If the copywrite owners take no umbrage to the use of their code in proprietary software then the company shouldn't be able to sue.

This will probably not be the case if the code is licensed under GPL because the devs are probably going to want to enforce their OSS principles.

You can say the FSF wants to provide a more "convenient" way to handle it but I don't think that "I'll take care of that for you" is a good argument.

It's very much reminiscent Leon the Professional

> The copyright assignment requirements in GNU projects point to the GPL not being good enough, thereby undermining it.

FSF copyright assignment for GNU projects is optional, and simply allows them to enforce the copyright on your behalf; most individuals don't have such resources available.

> If the FSF believes this to be a real threat, any group of users anywhere relying on the GPL should take the same view.

The issue with GNU license assignment (at least in the years I worked on) was the "defense of infringement".

The only legal recourse for a GPL violation is a copyright lawsuit and that can only be made by the copyright holder in question.

If FSF wants to defend a GNU project in a court of law against infringement, they need to represent the copyright holders.

As a GNU project, you opt into their legal infra as well as the technical ones.

The most prominent claim in your comment is that Benno forked the project "with hostility" by updating the official GNU Nano website. Can you explain why you consider nano-editor.org to officially "belong" to GNU? Chris Allegretta, whom you call the current maintainer, has gone on record saying he's the one who changed the website, and that Benno did not take over the website in a hostile way: http://www.asty.org/2016/06/23/whats-up-with-nano/

Why doesn't Chris just go update the website to clarify this? Surely Benno isn't the only one with access to change the site. Even if so, the domain is registered to Chris.

> Benno also did not want to assign copyright to the FSF for his contributions.

In Germany, you cannot legally sign away copyright (i.e. signing away your copyright is either an empty action or may even void other agreements contained in a larger contract).

I think the FSF sorted that out, although I haven't seen their paperwork. It popped up a lot some years ago, and it seemed to have been solved.

I suppose in most countries, one cannot sign away personal copy rights. You are always the author. But one can easily give right to use the work because of author's economic rights (and one must obligatory specify the fields of exploration in such agreement).

C'mon now. It is Wednesday my dudes. Please don't mess up my favorite little text editor.

Do I understand it right that Benno is doing a lot of work, but he does not want to continue the project in a manner which is consistent with the vision Chris as the principal maintainer of the project holds?

Chris does not have any vision of the project anymore. He does not have enough time even to publish releases [0]. And it was actually he who suggested Benno to fork GNU nano.

[0] http://thread.gmane.org/gmane.editors.nano.devel/4598/focus=...

<understate>This seems relevant.</understate> I wish I could upvote it twice.

> ...it was actually he who suggested Benno to fork GNU nano

I did not see any evidence for this in the discussions on the mailing list. Could you give some references?

    If folks are not interested in following that process, the best thing
    might just be to move to github or another repository and abandon the
    guise that we are acting according to GNU guidelines. Benno, Mike S,
    Mike F, Mark M, especially interested in hearing your take.
~Chris Allegretta - http://thread.gmane.org/gmane.editors.nano.devel/4598/focus=...

so this is FFMPEG/LibAV all over again.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact