zx2c4@thinkpad ~/nano $ git shortlog -sne --since '3 years ago'
1298 Benno Schulenberg <[email protected]>
64 Chris Allegretta <[email protected]>
6 Jordi Mallach <[email protected]>
3 Mike Frysinger <[email protected]>
3 Mike Scalora <[email protected]>
2 Rishabh Dave <[email protected]>
Maybe 10 years will be little more accurate?
git shortlog -sne --since '10 years ago'
1298 Benno Schulenberg <[email protected]>
481 David Lawrence Ramsey <[email protected]>
382 Chris Allegretta <[email protected]>
28 Jordi Mallach <[email protected]>
3 Mike Frysinger <[email protected]>
3 Mike Scalora <[email protected]>
2 Rishabh Dave <[email protected]>
git shortlog -sne --since '15 years ago'
2528 David Lawrence Ramsey <[email protected]>
1298 Benno Schulenberg <[email protected]>
803 Chris Allegretta <[email protected]>
355 Jordi Mallach <[email protected]>
3 Mike Frysinger <[email protected]>
3 Mike Scalora <[email protected]>
2 Rishabh Dave <[email protected]>
1 Rocco Corsi <[email protected]>
Any open source project is only as good as it is today not what it was.
Have kernel images doubled in the last years?
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.
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.
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.
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...
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.
There is no reason why the first sentence should imply the second.
--
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.
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.
Hint: I think gmail filters are good. The rest? Not so much.
(Thankfully we finally switched to another provider because the old one refused to support DKIM or even STARTTLS to other MX servers.)
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.
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.
There are separate state laws, iirc such as California, which makes parts of those kinds of provisions void.
In the past I've had contracts reprinted after pointing out errors in them.
So, yes, if it's a copy with my signature, it has the offending pieces crossed out.
Rather walk more slowly than walk in the wrong direction.
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.
That's why some OS projects require signing Developer Certificates of Origin etc.
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.
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.
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).
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.
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 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.
> 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).
»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.
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.
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.
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].
https://en.wikipedia.org/wiki/GNU_General_Public_License#Leg...
(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:
Isn't that what actually happened in the GPL-Violations.org project with netfilter?
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.
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.
Right, it's just that all the new revisions of Nano that anyone will use going forward have left 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.
Nano has been part of the GNU Project since 2001, and Benno has been contributing to that project for years.
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.
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.
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.
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
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.
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.
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).
[0] http://thread.gmane.org/gmane.editors.nano.devel/4598/focus=...
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.
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.