5 ms·

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 i

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.

thomasahle 10y ago
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.
- nnutter 10y ago
  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.
  - bluejekyll 10y ago
    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).
    - cyphar 10y ago
      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.
  - mkesper 10y ago
    If your licence is GPLv2 only (like for example the linux kernel), there is NO upgrade path.
    - cyphar 10y ago
      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.
    - ArneBab 10y ago
      Mercurial went the hard road and asked all contributors to relicense under GPLv2 or later.
  - ArneBab 10y ago
    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-assignment-at-the-fsf https://www.fsf.org/bulletin/2014/spring/copyright-assignmen... This is the difference between copyright assignment to the FSF and most other copyright assignment.
    - cm3 10y ago
      While surely better than Google or Ubuntu, the new license can still be non-proprietary but highly controversial.
      - cyphar 10y ago
        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.
  - thomasahle 10y ago
    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.
    - cyphar 10y ago
      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.
      - synchronise 10y ago
        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+?
        cyphar 10y ago
        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.
        synchronise 10y ago
        Was there any specific reason that license was chosen for btrfs that you know of?
        cyphar 10y ago
        My guess is >Oracle. They want to make the minimum possible community contribution.
- bluejekyll 10y ago
  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.
  - infodroid 10y ago
    > 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.
    - cm3 10y ago
      > 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).
- busterarm 10y ago
  The MAME project is an example of the the latter happening successfully.
- mkesper 10y ago
  You can also use a Fidiuciary Licence Agreement, like for example KDE: https://ev.kde.org/rules/fla.php https://ev.kde.org/rules/fla.php
- cyphar 10y ago
  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.
nnutter 10y ago
What matters is the way the law sees it.
- klakier 10y ago
  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.
brudgers 10y ago
[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].

thomasahle 10y ago

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.

nnutter 10y ago
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.
- bluejekyll 10y ago
  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).
  - cyphar 10y ago
    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.
- mkesper 10y ago
  If your licence is GPLv2 only (like for example the linux kernel), there is NO upgrade path.
  - cyphar 10y ago
    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.
  - ArneBab 10y ago
    Mercurial went the hard road and asked all contributors to relicense under GPLv2 or later.
- ArneBab 10y ago
  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-assignment-at-the-fsf https://www.fsf.org/bulletin/2014/spring/copyright-assignmen... This is the difference between copyright assignment to the FSF and most other copyright assignment.
  - cm3 10y ago
    While surely better than Google or Ubuntu, the new license can still be non-proprietary but highly controversial.
    - cyphar 10y ago
      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.
- thomasahle 10y ago
  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.
  - cyphar 10y ago
    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.
    - synchronise 10y ago
      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+?
      - cyphar 10y ago
        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.
        synchronise 10y ago
        Was there any specific reason that license was chosen for btrfs that you know of?
        cyphar 10y ago
        My guess is >Oracle. They want to make the minimum possible community contribution.
bluejekyll 10y ago
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.
- infodroid 10y ago
  > 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.
  - cm3 10y ago
    > 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).
busterarm 10y ago
The MAME project is an example of the the latter happening successfully.
mkesper 10y ago
You can also use a Fidiuciary Licence Agreement, like for example KDE: https://ev.kde.org/rules/fla.php https://ev.kde.org/rules/fla.php
cyphar 10y ago
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.

nnutter 10y ago

What matters is the way the law sees it.

klakier 10y ago
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.

brudgers 10y ago

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