What a bullshit. I'd call this Russian way of doing business, where you benefit from unhealthy connections with state. 2500 houses? Go find out how many houses are there in California.
We should worry because of the blurred responsibility. Have you ever seen large company responsible for death? This is how it works, you will die and there will be nobody responsible for this.
Tesla is not safe car, it is as safe as Honda Civic, with ~40 deaths per million cars. Do the math if you don't believe me.
Which is how it should be. If I die in my car, it's almost certainly going to be my fault or the fault of another driver, not the fault of the car maker. Of the ~30,000 traffic deaths/year in the US, how many are due to faulty equipment?
As far as doing the math, are we counting deaths like the guy who stole one and crashed it going 120MPH without a seat belt?
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).
Do you know that according to copy rights, open source projects are mess. Nobody tried it in the court, but if some developer contributing to project went to court saying "This part of code is mine, I don't want it to be modified by other people", then the project could be in trouble. Nobody tried that (yet).
That's why some OS projects require signing Developer Certificates of Origin etc.
The way I see it, if you contribute to a project for example by sending a patch to it by email or pull request then you agree to be bound by the license. Even if there is no copyright assignment. Otherwise you would not have the right to modify the software to write your patch in the first place. This just seems like common sense to me.
The problem is if the maintainer wants to change the license (Like GPL2 -> GPL3). That's only possible if the contributors have signed over copyright, or the maintainer can track down every person who ever sent a patch, and get them to agree.
I've been struggling with this question as well. If you want to maintain full control of your project, then you want any contributors to assign copyright, because it gives the maintainer the most flexibility.
On the other hand, as happened here, it makes people less likely to want to contribute to the project, because they probably feel like they are being taken advantage of or losing some right.
A counter argument to that, anyone is always free to fork the project, again, what happened here, but this has the obvious undesirable effect of splitting development effort.
> it makes people less likely to want to contribute to the project, because they probably feel like they are being taken advantage of or losing some right
I think it depends who the copyright is assigned to. I imagine people will have strong reservations about transferring copyright to a private company or individual.
But if the copyright is assigned to a mutually trusted organisation like a FLOSS foundation then I can't think of a good reason that a contributor would withhold copyright assignment.
They have nothing to lose and the project they care about will gain. There are even tools nowadays like CLAHub to make the process more convenient.
One exception might be corporate restrictions on contributors. Like if you need permission from your boss and it is denied.
I think the bigger issue with FLOSS projects is that often people are not always able to agree on an acceptable organisation to own the copyright let alone the kind of license to have.
> But if the copyright is assigned to a mutually trusted organization like a FLOSS foundation then I can't think of a good reason that a contributor would withhold copyright assignment.
How would one know beforehand what kind of license it will be re-licensed under in the future, and what kind of legal action that assigned copyright holder will take, which you may not agree with? You make valid arguments, but it's not that simple.
As a contributor it's easy to argue that there's no reason for something one contributes under license X to be put under license Y two years later without consent (not required in this case).
Copyright assignment isn't binary. It's a contractual agreement like anything else. You can make requirements like "it will always be under copyleft" (which is what the FSF and some Apache projects do). You should avoid projects that ask for blanket copyright assignment on a copylefted work.
> it's easy to argue that there's no reason for something one contributes under license X to be put under license Y two years later without consent
The problem isn't for the individual contributor, it's the project itself. Let's say for some reason you use Apache 2.0 and then decide you want to add MIT for better compatability with other license. You as the maintainer solicit from all contributors they're approval and you get 99/100, one person holds out and blocks it. What do you do in this case? Go back and remove all their contributions such that you can then continue with the general agreement?
A clause I've been considering, if it doesn't exist somewhere, is to have a majority rules portion to the agreement. But I'm not sure if this works without assigning copyright to the project.
> What do you do in this case? Go back and remove all their contributions such that you can then continue with the general agreement?
Yes, that's what you do, and it's the same in other industries.
For example, when Erlang/OTP contributors were asked to accept re-licensing under Apache2, a couple patches submitted by Netflix's Rick Reed were reverted prior to re-licensing because they didn't sign off.
The license is for all parties, not just to get contributions and then later do with it what you want. If that's how the project is governed, then the license has to reflect that (GPL3 or later) or a CLA must be in place. When that's clear, it's evident to contributors and many will refuse to contribute.
The whole point is to choose someone that you believe will make appropriate licensing decisions, both now and in the future. And that requires trust in the copyright holder. You cannot perfectly guarantee they will always do the right thing. But the legal structure of the organization can often reduce the risk of that.
I mostly agree, but unlike other legal agreements, contributing to a project under a FOSS license is not usually coupled with an expiry date after which there's room for radical re-licensing.
This is a really great point. Should there be a pay-to-play portion on these, e.g. Your copyright will "expire" and revert to the project(?) Should you not commit changes for a period of 2 years.
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.
> If the Program specifies a version number of this License which applies to it and "any later version",
I'm no lawyer, but I think the source has to mention that explicitly. So it's not true of ALL gpl projects. In this case though you are right because nano, it appears, specifies it's license as:
> License: GNU General Public License v3 or later
So, while true in this case it's not always true (see Linux kernel license, GPLv2, no upgrade).
Most GPL projects do this. I don't have access to my box, but if you did a search for licenses you'd find many use "or later" (and in fact a lot of code within Linux uses "or later" as well). So practically it's a very common upgrade path. And some people will actually email every contributor to ask to relicense the code.
Dual-license with a proprietary license is not allowed by the papers you sign when assigning copyright to the GNU project.
»We promise to always keep the software free. This promise extends to any successors in the copyright, meaning that even if the FSF were to go away the freedom of all users to share in the contributions wouldn't.« — https://www.fsf.org/bulletin/2014/spring/copyright-assignmen...
This is the difference between copyright assignment to the FSF and most other copyright assignment.
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.
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.
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.
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.
Note: I just realised that I licensed kernel/cgroup_pids.c under GPLv2-only. which is wrong. I've sent a patch that also includes a fix to that header.
That's not true. If your project is licensed under "GPLv3 or later" then you can relicense the project under GPLv4 when it comes out. This is the whole point of the "or later" clause in the GPL. It is also not true for lax licenses like MIT or Apache, since they allow sublicensing.
[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].
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.
And it's proof that like Oracle suing Google over 10 lines of code, it's enough for one or more contributors to claim ownership of some (small) part as a basis to take, say, Netgear to court. Thus you don't necessarily need to assign copyright over to a single person or organization.
What I meant here, is not that GPL was not tested in court. Just imagine situation of one of the authors saying: I no longer want to see my code on the Internet. Let's say he contributed 30% of the code. Now what? He is the author, he has the right to do it. In most cases developers sign no agreements when their patches are merged.
> I no longer want to see my code on the Internet.
Such a statement doesn't make sense. Not to mention that you can't retroactively un-license something (unless the license has a termination clause). Free software licenses do not have termination clauses (by definition, the FSF won't approve them if they do because it restricts practical freedom). Though I'm fairly sure it would count as an "open source" license under the OSI definition.
> In most cases developers sign no agreements when their patches are merged.
If you submitted code under the DCO, you've signed an affadavit saying that you have the right to license the code and that it is licensed under the license of the project. For copyleft projects, you don't even need that (if you've distributed it then you've implicitly licensed it under the original license). But in either case, once you've licensed you code under some license then you can't terminate that license if it's a free software license.
I don't fully understand. You cannot take back your public contribution, just as you cannot ask the patent office to erase the patent from all records and have everyone aware of it forget about it, and remove each and all references that build on that patent.
The world would be a much different place if smart people in the past hadn't invented Copyright and Patenting, which both are mostly being misused and are not used to foster innovation. Back then it was normal to hold onto secrets and patents and copyright were invented to incentivize publication under well-defined and not too long exclusivity periods after which other can freely improve on it. But today we have 20 year patent monopolies and Disney copyright absurdity.
If the code is under a copyleft license, then distributing a modified copy is only possible by complying with the license. So at the very least, you can get the code under that license. Non-copyleft licenses might fall into a worse trap here, but that's why we have the DCO. An affidavit is more than enough.
Try doing this - I created a full piano synth like Pianoteq working in realtime on Linux. Took me about year to complete (with breaks).
You can listen to it here: https://www.youtube.com/watch?v=U4I9SPCZIk4
Note that at least in Europe the toothpastes for children contain no fluoride.