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.