5 ms·

> because essentially these licenses say "your contribution is OSS today, but it might end up resulting as unintended free labor that helps build a commercial p

> because essentially these licenses say "your contribution is OSS today, but it might end up resulting as unintended free labor that helps build a commercial product of which you won't be part of". Contributions to non-copyleft OSS licenses _are_ actual contributions to the open source community as a whole. There's nothing preventing your GPL'd project from being used to make a commercial product that you are not a part of either. You're talking about enforcing perpetual conditions on the future of the product/license for your free labor. This is the reason why projects like MAME have contributor agreements now. Even if through some process the license changes in the future, your contributions were still to an open source license and that version of the code will remain open forever. I haven't seen anyone discouraged from contributing to OSS-licensed projects that are not GPL unless they are an extreme ideologue. I myself generally prefer to license my work with something like MIT or Apache (read: the ISC license, generally) and that choice is absolutely fine.

falcolas 6y ago
> There's nothing preventing your GPL'd project from being used to make a commercial product that you are not a part of either. Copyright law does exactly this. The role of the GPL is to carve out explicit exceptions to the "you can't copy this" rights granted by copyright law.
- busterarm 6y ago
  A lot of people seem to confuse Commercial with Proprietary... They are not the same.
  - falcolas 6y ago
    Doesn't matter. Copyright, without the licensing exceptions, won't allow EvilCorp Inc. use your code even if you publish it in the clear on the internet. Also, more relevant to the discussion I was responding to, the GPL license doesn't allow re-licensing without consent (or a pre-arranged copyright assignment - a contributor's agreement). And it's copyright law which enforces this.
    - busterarm 6y ago
      Given past experiences, I see large group projects trending towards having CLAs/DCOs where you give up ownership of your code anyway. Most people don't want to work with random contributors who wish to hold a gun to their heads in perpetuity.
      - falcolas 6y ago
        > who wish to hold a gun to their heads An aside, that's an awfully violent visual for discussing ownership of code.
      - gary-kim 6y ago
        DCOs don't give copyright ownership to anyone else or even any more rights to anyone else. It is simply a declaration that you have the permission to license the code you wrote under the license you're giving it for. This article gives a nice description of the differences: https://opensource.com/article/18/3/cla-vs-dco-whats-difference https://opensource.com/article/18/3/cla-vs-dco-whats-differe...
  - j1elo 6y ago
    True. Although in practice, the end-user freedoms that are guaranteed by copyleft practically destroy all, if not for a couple exceptions, of viable business plans. So even if theoretically the most aggressive licenses still allow for commercialization, the practical effect is that commercializing a copyleft codebase won't travel too far on its own as a business plan. This has been discussed a lot of times in HN, and the conclusion always is something on the lines of "don't do copyleft if you want to have any aspirations of commercialization on the software itself as opposed to peripheral elements such as support services or similar".
    - busterarm 6y ago
      > So even if theoretically the most aggressive licenses still allow for commercialization, the practical effect is that commercializing a copyleft codebase won't travel too far on its own as a business plan. Red Hat was acquired for $34 Billion. It really depends on what you're selling and how good your product is. > "don't do copyleft if you want to have any aspirations of commercialization on the software itself as opposed to peripheral elements such as support services or similar" Cop out argument. This comes from the same people who do split licenses that spit in the face of the spirit of OSS. It's people who want all of the benefits of writing OSS (outside contribution, growth in use of your product, less investment in sales) but none of the risks (someone else using what you offer for free and having a better product than you). It's purely anti-competitive.
      - falcolas 6y ago
        Redhat is the exception that proves the rule. How many more companies which relied upon selling services around GPL'ed code have died? Lots.
        busterarm 6y ago
        Canonical and SUSE are still around and have millions in revenue. Turns out that Linux is a good product that needs a lot of stewardship and support that's worth paying for. There's also hundreds of thousands of software developers and consultancies offering their services that make use of GPL'd (and other OSS-licensed) code. Probably 90% of this board is selling their services/labor of GPL'd projects. It's been my whole career. No, what it sounds like is we're talking about people who want to write OSS but also want ownership and exclusive rights to make money off of it. My argument there is pound sand.
j1elo 6y ago
> Even if through some process the license changes in the future, your contributions were still to an open source license and that version of the code will remain open forever. Well, that's a good take. You're right of course: the exact version of the codebase you contributed to, was licensed as OSS and it will always stay like that. So yes, copyleft is more about providing guarantees about the future, while non-copyleft can only provide guarantees about the present. I think this way of putting it is clearer than my previous way of saying it. Thanks for bringing up this point of view. > This is the reason why projects like MAME have contributor agreements now. Hence articles such as [1] and [2], which have been posted in HN before, albeit with pretty much zero conversation. Still, just like I'm interested in the topic of OSS licenses and the thought process of people who choose them for their projects, I find also interesting the matter about CLAs and whether to go on with one or instead opting to use a DCO [3], which some well known OSS projects have preferred in the past: [4], [5]. [1]: Why CLAs aren't good for open source -- https://opensource.com/article/19/2/cla-problems https://opensource.com/article/19/2/cla-problems [2]: Why you probably shouldn’t add a CLA to your open source project -- https://ben.balter.com/2018/01/02/why-you-probably-shouldnt-add-a-cla-to-your-open-source-project/ https://ben.balter.com/2018/01/02/why-you-probably-shouldnt-... [3]: CLA vs. DCO: What's the difference? -- https://opensource.com/article/18/3/cla-vs-dco-whats-difference https://opensource.com/article/18/3/cla-vs-dco-whats-differe... [4]: (GitLab) We're switching to a DCO for source code contributions -- https://about.gitlab.com/blog/2017/11/01/gitlab-switches-to-dco-license/ https://about.gitlab.com/blog/2017/11/01/gitlab-switches-to-... [5]: Helm Moves To DCO -- https://helm.sh/blog/helm-dco/ https://helm.sh/blog/helm-dco/

falcolas 6y ago

> There's nothing preventing your GPL'd project from being used to make a commercial product that you are not a part of either. Copyright law does exactly this. The role of the GPL is to carve out explicit exceptions to the "you can't copy this" rights granted by copyright law.

busterarm 6y ago
A lot of people seem to confuse Commercial with Proprietary... They are not the same.
- falcolas 6y ago
  Doesn't matter. Copyright, without the licensing exceptions, won't allow EvilCorp Inc. use your code even if you publish it in the clear on the internet. Also, more relevant to the discussion I was responding to, the GPL license doesn't allow re-licensing without consent (or a pre-arranged copyright assignment - a contributor's agreement). And it's copyright law which enforces this.
  - busterarm 6y ago
    Given past experiences, I see large group projects trending towards having CLAs/DCOs where you give up ownership of your code anyway. Most people don't want to work with random contributors who wish to hold a gun to their heads in perpetuity.
    - falcolas 6y ago
      > who wish to hold a gun to their heads An aside, that's an awfully violent visual for discussing ownership of code.
    - gary-kim 6y ago
      DCOs don't give copyright ownership to anyone else or even any more rights to anyone else. It is simply a declaration that you have the permission to license the code you wrote under the license you're giving it for. This article gives a nice description of the differences: https://opensource.com/article/18/3/cla-vs-dco-whats-difference https://opensource.com/article/18/3/cla-vs-dco-whats-differe...
- j1elo 6y ago
  True. Although in practice, the end-user freedoms that are guaranteed by copyleft practically destroy all, if not for a couple exceptions, of viable business plans. So even if theoretically the most aggressive licenses still allow for commercialization, the practical effect is that commercializing a copyleft codebase won't travel too far on its own as a business plan. This has been discussed a lot of times in HN, and the conclusion always is something on the lines of "don't do copyleft if you want to have any aspirations of commercialization on the software itself as opposed to peripheral elements such as support services or similar".
  - busterarm 6y ago
    > So even if theoretically the most aggressive licenses still allow for commercialization, the practical effect is that commercializing a copyleft codebase won't travel too far on its own as a business plan. Red Hat was acquired for $34 Billion. It really depends on what you're selling and how good your product is. > "don't do copyleft if you want to have any aspirations of commercialization on the software itself as opposed to peripheral elements such as support services or similar" Cop out argument. This comes from the same people who do split licenses that spit in the face of the spirit of OSS. It's people who want all of the benefits of writing OSS (outside contribution, growth in use of your product, less investment in sales) but none of the risks (someone else using what you offer for free and having a better product than you). It's purely anti-competitive.
    - falcolas 6y ago
      Redhat is the exception that proves the rule. How many more companies which relied upon selling services around GPL'ed code have died? Lots.
      - busterarm 6y ago
        Canonical and SUSE are still around and have millions in revenue. Turns out that Linux is a good product that needs a lot of stewardship and support that's worth paying for. There's also hundreds of thousands of software developers and consultancies offering their services that make use of GPL'd (and other OSS-licensed) code. Probably 90% of this board is selling their services/labor of GPL'd projects. It's been my whole career. No, what it sounds like is we're talking about people who want to write OSS but also want ownership and exclusive rights to make money off of it. My argument there is pound sand.

j1elo 6y ago

> Even if through some process the license changes in the future, your contributions were still to an open source license and that version of the code will remain open forever. Well, that's a good take. You're right of course: the exact version of the codebase you contributed to, was licensed as OSS and it will always stay like that. So yes, copyleft is more about providing guarantees about the future, while non-copyleft can only provide guarantees about the present. I think this way of putting it is clearer than my previous way of saying it. Thanks for bringing up this point of view. > This is the reason why projects like MAME have contributor agreements now. Hence articles such as [1] and [2], which have been posted in HN before, albeit with pretty much zero conversation. Still, just like I'm interested in the topic of OSS licenses and the thought process of people who choose them for their projects, I find also interesting the matter about CLAs and whether to go on with one or instead opting to use a DCO [3], which some well known OSS projects have preferred in the past: [4], [5]. [1]: Why CLAs aren't good for open source -- https://opensource.com/article/19/2/cla-problems https://opensource.com/article/19/2/cla-problems [2]: Why you probably shouldn’t add a CLA to your open source project -- https://ben.balter.com/2018/01/02/why-you-probably-shouldnt-add-a-cla-to-your-open-source-project/ https://ben.balter.com/2018/01/02/why-you-probably-shouldnt-... [3]: CLA vs. DCO: What's the difference? -- https://opensource.com/article/18/3/cla-vs-dco-whats-difference https://opensource.com/article/18/3/cla-vs-dco-whats-differe... [4]: (GitLab) We're switching to a DCO for source code contributions -- https://about.gitlab.com/blog/2017/11/01/gitlab-switches-to-dco-license/ https://about.gitlab.com/blog/2017/11/01/gitlab-switches-to-... [5]: Helm Moves To DCO -- https://helm.sh/blog/helm-dco/ https://helm.sh/blog/helm-dco/