Nano is no longer a GNU project | Hacker News Reader

Nano is no longer a GNU project

nano-editor.org

151 pointswtbob229 comments

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.

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.

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.

No, the courts have already handled cases around the GPL

https://en.wikipedia.org/wiki/GNU_General_Public_License#Leg...

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:

https://sfconservancy.org/blog/2016/feb/29/vmware-hearing/

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

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

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.

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.

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.

http://marc.info/?l=linux-kernel&m=146673699017938&w=2

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

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

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.

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

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

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.

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.

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

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

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.

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.

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.

http://www.copyright.gov/circs/circ09.pdf

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.

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

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

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

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

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

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.

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

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.

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.

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.

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

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

They are accessible over HTTP. http://git.savannah.gnu.org/cgit/nano.git/commit/?id=115aeda...

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.

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.

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.

Snap

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.

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.

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

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?

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.

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

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

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

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

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.

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.

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

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

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

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

so this is FFMPEG/LibAV all over again.

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/

    > > As you know, I will not assign my copyright to the FSF, 
    > > nor to anyone else. All the code I write is GPL'ed.
    > > You don't need to own the copyright on any code in
    > > order to be able to enforce the GPL.  [...]
    
    > Indeed, and in fact for a long time the copyright 
    > was owned by me before it was assigned to the FSF.  
    > It's not required per se, but generally speaking, 
    > there must be a Maintainer of the Software who 
    > believes in the ideals of the GNU system

    I do believe in the ideal of the GNU system: to have
    computer systems that consist entirely of libre 
    software.

    > and will adhere to the GNU coding standards

    That is too bureaucratic, not libre enough.

https://lists.gnu.org/archive/html/nano-devel/2016-05/msg000...

That's a great summary and an eye-opener on the whole situation. Everything aside, but isn't this FSF enforcement a little too much burden for some? Does it actually change anything? (apart from giving a bad sensation when you hear "now we own the copyright of your work")

I am not a lawyer.

The strength of the GNU licenses depends on existing copyright laws [plural]. As the copyright holder, GNU is more likely to have standing in an arbitrary jurisdiction when seeking to enforce the license.

Whether or not enforcement is important is another matter. If it isn't, then there's nothing but a fantastic warm fuzzy in choosing GNU over a "do whatever you want" license. To put it another way, license terms like other contract terms should align with what the author is willing to go through the bother of enforcing.

Copyright assignment isn’t actually required by the GNU project. It’s the maintainers choice whether to require it for the specific project or not.

I'm confused. The reason the FSF gives for copyright assignment is precisely in aid of their legal enforcement of the GPL. From their website [1]:

    ... enforcement of copyright is generally not possible 
    for distributors: only the copyright holder or someone 
    having assignment of the copyright can enforce the
    license.
    ...

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

That's a reason, but I suspect not the prime reason. The ACLU, the Institute for Justice, Pacific Legal Foundation, etc. usually never have a direct claim themselves in the cases they're involved in... they look for some other party that has standing and then assists that party in pursuing their case in court. I don't see why the FSF could not also follow that model by supporting any copyright holder in litigating/negotiating GPL license breaches.

What they do get with assignment is that they can ensure that the software is only ever issued under the license/license version of their choosing. Any other copyright holder can cease distributing their software under the GPL; true, they cannot revoke previously granted rights, but future versions, etc. can be made to be non-FOSS. An independent copyright holder could also dual license their code GPL and closed source. I think avoiding those scenarios is really why FSF wants the assignment. Not the ability to litigate, that's just an excuse.

Looks like the devels weren't all that happy about assigning the copyright of their code to the FSF.

Part of the e-mail thread discussing the move is here https://lists.gnu.org/archive/html/nano-devel/2016-05/msg000...

I did't have the time to dig out the whole conversation history.

I reviewed the discussion but I still can't understand what the controversy is about. According to the following explanatory note from the GNU project, developers don't have to assign copyright to the FSF for it to be an official GNU project:

When the developers of a program make it a GNU package, they can decide either to give the copyright to the FSF so it can enforce the GPL for the package, or else to keep the copyright as well as the responsibility for enforcing the GPL.

Source: https://www.gnu.org/licenses/why-assign.en.html

---

FYI this is the start of the discussion thread:

https://lists.gnu.org/archive/html/nano-devel/2016-05/msg000...

Interesting. It looks like the Nano devs have misunderstood what can be called a GNU package. If they don't assign copyright to the FSF, but want it to still be a GNU package, they just have to declare that they're taking responsibility for licensing enforcement.

>developers don't have to assign copyright to the FSF for it to be an official GNU project

This is correct, but it's up to the maintainer to decide if their project will require copyright assignment from all contributors or not. I send patches to a couple of GNU projects, Guile and Guix. Guile requires copyright assignment, Guix does not.

Assigning copyright to the FSF is very much unlike assigning copyright to a for-profit company. The terms that you sign and agree to with the FSF are very reasonable and they protect the developer from having the license changed should the FSF be taken over by people that would want to abuse your contributions.

As I recall the terms include some phrase like "we might change the license to be similar in spirit to the existing one" which gives FSF and anyone who controls it in the future a lot of wiggle room.

E.g. the GPL v2 to v3 transition was enabled by that, with the introduction of patent/"TiVo" clauses. No reason they couldn't make more drastic changes in the future.

That means that the contributors agreed to license the code as "GPL version 2, or at your option any later version", which means that they are amenable to changes to the GPL. The FSF could not, however, make a GPLv4 that was a proprietary software license or something. I wouldn't have signed copyright assignment forms if that was a possibility.

Really, FSF copyright is a very good thing, and you can even do it completely digitally in the US and Germany (used to be that you had to use snail mail to receive forms and send them back). People shouldn't get scared away from contributing to GNU projects that choose copyright assignment. There's no better place to protect the GPL than at the FSF.

And that's where I don't fully agree. There are many projects licenced under "GPL v2 or later" and they don't need copyright assignment. Copyright assignment is huge and opens the door for way too many legal stuff.

Also Copyright is a pretty US thing. Law differs and many Countries don't actually allow it. Also since you brought up Getmany already: https://en.wikipedia.org/wiki/Copyright_law_of_Germany#Trans... Germany is such a country and even if you were to assign copyright to them it would be legally void to the best of my knowledge. And also other countries that base it on moral rights.

Copyright law is very different between countries and way too strong to just transfer for such a use. If they really wanted to, they should have made a license to handle it exactly the way they wanted.

The problem is that in order to have the ability to register their copyright and do meaningful enforcement actions in the US, they need copyright assignment. Copyright cares about authorship, so if they don't have "authorship" (read: own the copyright) then they have very little power to enforce the GPL.

Some other people argue it's not necessary, and while that might be true, it's better to be safe than sorry. Not to mention that all GNU projects are GPLv3-or-later anyway (so any contribution would be able to be upgraded anyway since it's licensed in such a way that you can use it under GPLv4). If you refuse and license your change under GPLv3, it won't get merged.

“similar in spirit” is a pretty strong condition, since there are lots of philosophy texts on the GNU pages which make it clear what “similar in spirit” means. A court would likely rely on these to decide a case.

It says:

5. FSF agrees that any program "based on the Works" offered to the public by FSF or its agents or assignees shall be offered in the form of machine-readable source code, in addition to any other forms of FSF's choosing. However, FSF is free to choose at its convenience the media of distribution for machine-readable source code and may charge a fee of its choosing for copies.

> Assigning copyright to the FSF is very much unlike assigning copyright to a for-profit company. The terms that you sign and agree to with the FSF are very reasonable and they protect the developer from having the license changed should the FSF be taken over by people that would want to abuse your contributions.

This does not comport with my understanding of how copyright works. Once you transfer your copyright to someone, the creative work is entirely theirs. So what standing would you have to object to what they do with it? It belongs to them now, not you.

It doesn't matter what an agreement says if you don't have standing in court to enforce it.

They set conditions (we will keep it free) just like any software contract where you only get the software if you promise to adhere to some rules.

I don’t think the FSF ever violated the condition, so there’s nothing you can do to test whether a court would follow that interpretation.

Software contracts with conditions are license agreements. You get to use Windows, Ubuntu Linux, Photoshop, Facebook, etc. as long as you adhere to the terms of the license.

You don't get the copyright. That's still held by the software company. That's how they can force you to adhere to their conditions--they own the software and they can take away your license.

But if they gave you the copyright, they couldn't take it away anymore, so you would have no reason to follow their conditions any more.

Contracts and copyright law are wildly different things. It's misleading and incorrect to conflate the two together.

Yes, that's my point--the person I replied to was confusing copyright assignment with buying software, and I am explaining how they are different.

> Software contracts with conditions are license agreements.

That sentence is blatantly false. A contract and a license are different concepts and bound by different laws. That was my point.

In addition, they weren't confused. It looks like you were:

> They set conditions (we will keep it free) just like any software contract where you only get the software if you promise to adhere to some rules.

"keep it free" refers to freedom (as in they will only ever use free software licenses). In fact the FSF also states they will only ever use licenses that are in the same spirit as the GPLvX. It is a contract, because you are assigning your copyright to them -- you have to have an agreement in place in order to do that. Software licensing is a different thing. The FSF actually requires you to give them your copyrights if you want to contribute some code to a project they manage. Many other projects do not do this, so the structure for things like Linux (and some GNU projects) is different and is based on licensing.

Well a license is just a form of contract. In particular, a license is only valid for the term of the licensing contract--once the term expires, so does the license. This permits the licensor to compel the licensee to comply with conditions during the term of the contract. If they don't, the contract is violated and the license is withdrawn.

Copyright assignment is more like a sales contract (at least in the U.S.). It doesn't have a term, but rather is complete once executed. Once it's executed, the new property owner can do what they want with the property. This makes it hard for the seller to compel the buyer to comply with conditions once the sale is done. Like selling a car to someone and saying "if you buy this car you can't drive it to to Texas." Once it's titled in their name, they can drive it wherever they want.

> Well a license is just a form of contract

Free software licenses (and some proprietary software licenses) are not contracts in any meaningful way. They do not require any of the tests of contract law (meeting of minds, bystander, willingness to be bound, etc) and are implicit agreements (to be fair, contracts can also be implicit but that's not what people are talking about when they say "contracts"). The reason you have to obey the GPL is because the only way you can do anything with the software is by obeying the terms of the license (assuming it's not dual-licensed). That doesn't smell or sound like a contract to me.

> Copyright assignment is more like a sales contract

Except free software copyright assignment gives you non-exclusive rights to licensing anyway (so you only lose the power to sue people, which is not something that software developers do regularly). In addition if you sign a contract to buy a car under the condition that you will drive it to Texas and you don't drive it to Texas, then the contract is voided. Same with houses, or anything else you could possibly sell.

It belongs to them now, but under the conditions that I agreed to. So, they have to keep the source free or they will have violated a legally binding agreement with me.

What is the penalty for that violation?

The same penalty as with violation of any other type of contract. They would also lose any rights under that contract because they violated their side of the deal.

Once you transfer your copyright to someone, the creative work is entirely theirs.

Note that in jurisdictions like Germany, it's impossible to sign away our version of copyright ('Urheberrecht', creator's rights): At most, you can grant exclusive usage rights.

My impression from that thread is the only problem some of the devs had was assigning copyright to the FSF. They insist on sticking to FSF's principles and in fact will continue to have their code hosted on Savannah because Github isn't Free enough.

Ah this looks like the important one: https://lists.gnu.org/archive/html/nano-devel/2016-05/msg000...

The current maintainer is/was A) looking to pass on responsibilities B) not get copyright assignment like GNU projects are supposed to

so they just decided fuck it.

Loads of us use nano.

Simple light editor without the overhead (read learning curve), of all the other big editors.

Sure, I might not write code in it, but when I need to edit a conf file or two, both on a server, and my desktop, it really hits the spot.

I use nano, because I didn't "get" Vim.

I hate to admit it, but that's more or less why I do as well. It's not that I don't get ViM, it's just that I don't like it. I have TRIED to force myself to use it. Something about that long reach for the Esc key? I don't know what it is really, but I just never felt comfortable using it. Emacs is such a huge monster of a program. 90% of what it does I never touch. Most of the time I just need to edit a conf file and move on. Being a sysadmin my needs are very few in a text editor.

As an emacs user, it is ironic I mention this tip!

You can use Control + [ as an alternative to using ESC in Vim. This solved my reluctance to reach for the ESC key in the far reaching corner of my keyboard.

This thread does remind me of nano. Maybe it is time to give it a try when editing files on servers.

Sysadmins are the primary candidates for vi/m ;)

I add "imap jj <Esc>`^" to my .vimrc That way, I don't leave the home row when trying to switch modes

This is what I do as well. I think it's pretty standard.

vi was written on an ADM-3A which had its escape key where tab is now typically located.

I remap caps lock to escape.

A bit strange, because as far as the history remembers, Nano was explicitly a fork of Pico, because of the license. [1]

Strange how history rewrites itself.

1 : https://en.wikipedia.org/wiki/Pico_(text_editor)

EDIT : Quotes from Wikipedia

`The GNU Project has a clone of Pico called nano which has been developed because Pico's earlier license was not a free software license, since distribution of a modified version of the code was ambiguously forbidden.[2] By default nano attempts to mimic Pico to replicate the environment users are used to. However it can be configured to offer mouse support, auto indentation, regular expression searches and even syntax highlighting making it more useful. Newer versions of Pico as part of Alpine are released under the Apache License.`

Not much history rewriting or strangeness: pico wasn't open source, nano was open source. nano is still open source.

Nothing has changed with this announcement except who own the copyrights to the open source code.

Pico was certainly open source; it was part of PINE, one of the older and more popular Unix mail programs.

I'm sure what the poster meant was the Pico wasn't free/libre software.

edit:

> because Pico's earlier license was not a free software license, since distribution of a modified version of the code was ambiguously forbidden.

I meant open source, but same requirement to allow distribution of modified software appears in both the free software list of freedoms [1] and the open source definition [2].

1. https://www.gnu.org/philosophy/free-sw.en.html

2. https://opensource.org/osd-annotated

Pine wasn't open source either. That's why the Linux distros couldn't include it.

From https://en.wikipedia.org/wiki/Pine_(email_client)

"The University of Washington later modified their license somewhat to allow unmodified distribution of Pine alongside collections of free software, but the license still does not conform to the Open Source and the Free Software Guidelines so it is semi-free software, effectively proprietary software."

A-ha. Thanks, that makes sense.

I was just having a hard time getting past the idea that I'd never have had PINE working if I didn't have the source. :)

I use nano all the time when teaching Python, before moving to other more feature rich editors. It is perfect for quickly explaining the importance of plain text files. A big thanks to the developers for making software that is simple, ubiquitous, and lasting!

From the mailing list, on using Github:

> Plus, in order to use their services, you need to assume liability

That sounds bad, as in really bad. One important function of Open Source licenses is to get as far away from liability as possible.

Do people here know whether that's just a misunderstanding, or a realistic risk of keeping code on Github?

Just read through their terms of service, and I don't see anything to that effect. You are responsible for not violating other people's copyright with stuff you upload to GitHub, and GitHub is not responsible for damage, etc. due to service outages. But that's it.

I think you're conflating the role of a host and the role of a OSS license.

As with most hosts, the issue of liability rests on the owner. I couldn't upload 50gb of pirated movies to github and cry "github save me, I used you and now I need you to protect me."

Your software license dictates your liability to users of your code.

GitHub is saying we're just a host, and we defer to the software liscensors on how their code should be used

Also worth mentioning that liability laws can be rather different from country to country. Germany (and Austria iirc) is somewhat notorious in that regard as you can't completely "get rid of" liability and warranty. There's no public domain for example (technically that's still debated but the main opinion seems to be it's not possible for me to release anything as public domain, see §29 UrhG-D).

don't want to sound nasty , but is anyone there using nano really ? i know it come by default in some distros but that's about it really.

I use it constantly, because I'm quicker making small edits with it than with vim. I would sorely miss it if it's not installed on a server.

I hear this faster for small things but if you use vim I would say I can make changes in a small document twice as fast.

They should have a new tag line:

Nano the plain text editor for non-Vim maybe EMACS users?

This is only true if you use vim at least once a week forever. Some people don't want to study a manual to change 1 config line. Call me crazy I know.

Yeah, maybe I'm just weird, but I like it when the down-arrow key makes the cursor go down a line.

Not saying they don't exist, but I don't think I've ever encountered a vim instance where that didn't happen.

I recall many frustrating days in college when I first learned vim but not enough to configure it (or was to lazy to). The arrow keys inserted control characters in edit mode on the basic Linux install I had at the time and on the school's computers (circa 2000-2004). It was annoying. It turned me off to vim for a while, but emacs and I were a better fit anyways.

Yeah, maybe I'm just weird, but modal editing is kind of a pain unless you do it every day. It's just a little too arcane for making a quick edit to a file in /etc. It's probably even more natural for me having grown up in the shadow of the University of Washington, so PINE was the popular email client and PICO was it's editor.

Don't get me wrong, I've watched Vim power users do amazing things in that editor but those people are not me and I can't find a good reason to climb that particular mountain.

arrows work in vim as default since 2000???

vim file_foo

press i for interactive and make changes then press :wq

:) I have that embedded in my brain after all these years.

You forgot ESC after making changes ;)

nano file_foo

make changes

ctrl-O-Enter - save ctrl-X-Enter - exit

Simpler, I think?

Don't even need the ^O, it asks if you want to save on exit if there are modifications.

Many many people who need to occasionally edit text in a terminal don't know how to use Vim OR Emacs.

I use it to hack config files on many distros because I find vi atrocious and don't want to install emacs on systems that aren't mine.

I seldom used it a long time ago, before learning the basics of vi(m). It's great when you need to change some random config and you need a commandline editor that has the basic commands listed in plain sight all the time.

> but is anyone there using nano really?

Yes, because vim is a pain in the ... and emacs is too big sometimes.

> emacs is too big sometimes

"Zile Is Lossy Emacs"

A fair few raspberry-pi tutorials seem to prefer Nano, for users new to Linux.

I am using it constantly. first thing on a rhel server: yum install nano

I only use it because sometimes vim doesn't work correctly over putty and I can't not verbally swear every time I have to search a vim issue.

Seriously, if you're spending more than a few minutes a week SSH'ing then forget PuTTY, grab yourself a copy of MobaXterm:

http://mobaxterm.mobatek.net/

It's also Pageant aware and will use that as your ssh key agent if you prefer. And vim works properly. We like it so much we pay for the Pro editions.

"Max. 12 sessions Max. 2 SSH tunnels Max. 4 macros Max. 360 seconds for Tftp, Nfs and Cron"

Not open source and heavily limited. Unless you pay for Pro, it's pretty useless...

If you just have a handful of servers you can still get a lot done with the free edition, not useless at all by any stretch of the imagination. Paying a few quid a year to keep up with the updates is peanuts compared to the extra productivity we get from it.

Sounds like VT emulation settings in PuTTY might be wrong. There's nothing in vim that PuTTY doesn't support - in fact I've used vim over PuTTY many times.

Back in the 1990s thru early 2000s, I used to use pico before I became comfortable with vi. For someone coming from a DOS/Windows/OS/2 background originally, it was less of a learning curve. I never used nano much, but I imagine the same reasons might apply for some people today.

(I also used to use emacs a lot, I first used it on OS/2 under EMX, but there were systems on which pico was installed but emacs wasn't. Nowadays, I'm so used to vim, I start emacs and can't remember most of the keystrokes. Oh, and the first ever email client I used was Pine.)

It's nice to have on boot disks, small enough to fit alongside busybox which ships with a lite vi[1] that some don't care for.

I personally love vi and am a bit taken aback sometimes when visudo pulls up nano instead of vi because I haven't installed it or made it my default editor yet.

So I'm not sure this means much to me personally but I'm always sad to see members of the community part ways. Still, I wish them all the luck and thank them for their efforts.

[1] https://en.wikibooks.org/wiki/Learning_the_vi_Editor/BusyBox...

Yes, it's much easier to work with than modal editors which I find clumsy and terrible. I don't use it intensively, just when I need to edit something quickly, usually in an SSH session.

on any server without a monitor, ofc i use nano!

Yup, love it.

Not as arcane as vim, great for small edits without the oh-crap-what-have-I-pressed-force-quit-start-over phenomenon that I get in vi. 'Serious' editing is done in gedit...

vi makes me angry. This was obvious when I installed Debian on a 1999-era iMac and had to edit (probably) x11 conf and had to use vi with JKL; instead of the arrow keys. It made me want to stab something.

nano makes me happy.

> had to use vi with JKL; instead of the arrow keys. It made me want to stab something.

I can see how this would be frustrating, given that the vi movement keys are in fact HJKL

That's probably what they were. I was trying to remember exactly, since that was over 6 years ago, and I've never had to use vi like that before or since.

I use it, as a terminal editor, whenever I can. On my machines I use it instead of vi(m), and if I have control over a remote machine, there as well, I only use VI if a server doesn't have nano and I can't install it.

It fills a real need as the console-based text editor for people who don't know vi (and would usually use e.g. gedit rather than emacs).

(I'm sure it has other purposes too, but it's the most motivating one I know.)

Ubuntu X11 stopped working? Or perhaps you need to tweak the nginx config on that tiny VPS you're renting? If you don't know vim, nano is something that's very easy to use and often pre-installed.

There was a nice xkcd about this [1]. I know HN is not the place for this comix, but anyway your question is a bit opinionated.

1 : http://xkcd.com/378/

> There was a nice xkcd about this

Also Hackles

https://web.archive.org/web/20160307122907/http://hackles.or...

When I used to work with PHP files directly on an ssh'd serve nano was my jam.

I find it very convenient to open large log files bc Nano is very lightweight. Something like that:

$ cat /var/log/logfile | grep -n section_start which gives me required line numbers. and then:

$ nano +lineno /var/log/logfile

and for configs, of course.

I would go straight to vim and type: "/section_start<cr>", which navigates straight to that line. Then navigate to the line, "i" to enter insert mode, make edits, and "<esc>:wq<cr>".

It is absolutely a learning curve, but the power of vim is insane. "dd" deletes lines, "A" appends to the end, "I" inserts at the beginning, "<lineno>G" jumps to a line number, all little tweaks that I use nearly every day in editing files quickly. It's especially nice when editing known_hosts where it tells you the line of the offending key, just "<line#>Gdd:wq" and it's done.

>I find it very convenient to open large log files bc Nano is very lightweight.

Nano seems to be far slower than vim for opening large files.

Just quickly testing on a 200M 500k row text file on a SSD:

Vim opens practically instantly.

nano takes over 10 seconds to display text, but works well after that.

I use nano whenever I have to mess on a server directly (which is rare). Rest of the time I'm in a JetBrains product I happily pay for.

Every once in a while I'm forced to use it because it's set as default on some servers until I close it in anger and get vim installed :P

How about vi for a quick edit? I haven't come across a distro without it so far (iirc it's part of the posix spec).

On some distros nano is the default editor for crontab. I run into it when I ssh to servers and have to setup cronjobs. I set EDITOR=vim if it's already installed there or I keep using nano and look at the help at the bottom of the page every single time I use it. I use emacs for editing code on my computer. It has got a different set of ctrl-* and I can't remember nano's ones.

nano allows for less key strokes for simple edits to config files.

I use it once per install. Something runs an editor and it's nano and I think oops, and exit and install gvim.

Constantly - for editing crontab, or occasionally to tweak some config stuff on dev boxes. I also do a lot of PHP though so that could explain it...

yep. Beeing a DevOps since many years and still use nano for quick edits on ssh because I don't use vi(m) anywhere. Why should I learn a new editor which behaves totally different when I can use nano which behaves quite similar to my existing tools. And as you say it's on nearly every distro. On emergency I still know how to use vi... but that does not mean I like it very much.

I use it on some dev servers I can't install software on as an alternative to vi. Otherwise I use emacs+tramp to edit files remotely. It's not a huge use case or most of my editing. Anything to avoid vi though.

Nano is extremely valuable for people learning the system. Typical alternatives are vi and emacs, which are extremely opaque, to the point that it's not even obvious how to exit them. UNIX tutorials will often say "use control-C to kill a command" and then that doesn't even work for this!

Nano tells you how to use it right on the screen. Control-C still doesn't work, but it tells you how to exit. Saving files, paging, cut and paste commands are all shown. There's easily accessible help!

If you're learning UNIX then editing files is handy. Without nano, you'd have to spend a bunch of time learning how to use a text editor before you could do anything that needs text editing.

7 years after getting into Linux, I still prefer Nano to make fast edits to text files. Coming from a Windows history shortcut keys are fairly natural to me, and although I disagree with some of the mnemonics, I've got the improtant ones memorised. There's enough features to even do light coding in it (syntax highlighting, auto-indenting etc.). Basically, I can pull up, edit and save a file before vim has even entered Insert mode.

Don't get me wrong, I understand the need for a feature-complex editor like vim, but I have never, ever gotten on with it.

yes: It’s my goto tool for quick edits, especially when working over SSH. For larger work I use Emacs.

also if I wanted to tell others to edit something, I‘d point them to nano.

When I'm not in an Emacs session (which is rare) I use zile for quick edits instead of nano.

I just hate when I'm in sublime and I hit ctrl+w to search and it closes the file #fml

Yup, I wouldn't mind a version of nano but with keybindings more like Windows or even MS Edit.

Something like https://github.com/rgburke/wed ?

Hit something similar today where I tried to raw insert emacs-style with Ctrl-Q...in Atom...went about as well as you'd expect

old habits die hard

For me it's when I'm in Firefox and hit C-s to search and it pops up a save dialogue …

I like that Firefox uses '/' for that like vim/less/etc...

Took me a while to get used to it on Windows, was always reaching for C-f, but once you get used to it it's great!

Love nano - been using it for something like 18 years or whenever I had my first Linux server online. I couldn't survive a *nix environment without it.

All night will be spent desperately trying to get all the FTP logins back from this man! facepalm

Reply on news.ycombinator.com