4 ms·

If you own the copyright to the application then you do not need a license to use it. The case where you would be violating a license would be if someone else o

If you own the copyright to the application then you do not need a license to use it. The case where you would be violating a license would be if someone else owns the copyright to parts of the application, for example because you accepted code from external contributers under the AGPL, or reused other AGPL code.

Abishek_Muthian 4y ago
Thanks for the clarification. So, It's best to use permissible license for the open-source version of the application in case of dual-license if we want to take back the contributions to our non open-source version. I see this is what dual-licensed projects seem to do, I use open-source version of Aseprite[1] under MIT but I paid for the license on their website under EULA. If anyone has seen a dual-licensed project where the open-source version is under AGPL or similar restrictive license then please mention. [1] https://github.com/aseprite/aseprite/ https://github.com/aseprite/aseprite/
- dllthomas 4y ago
  > So, It's best to use permissible license for the open-source version of the application in case of dual-license if we want to take back the contributions to our non open-source version. That's one option; the other is to require that contributors assign you copyright of their contributions (perhaps with compensation) so you can release it in the same manner as your own code. Narrowly focused on the effectiveness of the dual license scheme itself, permissive licenses "don't work as well" because there is less incentive for anyone to pay you for the other license; typically all they'd be avoiding is the attribution requirements.
  - Abishek_Muthian 4y ago
    > That's one option; the other is to require that contributors assign you copyright of their contributions (perhaps with compensation) I thought about it before I made my previous comment, Good to know this is a thing. > permissive licenses "don't work as well" because there is less incentive for anyone to pay you for the other license; typically all they'd be avoiding is the attribution requirements. As far consumers are concerned, I think it largely depends upon the project; If it's complex to setup and run then I guess people would use the hosted version. I use open-source Aseprite because it's available on AUR, But I did pay for the license on their website which I presume most wouldn't. Perhaps the real concern with permissible license are the competitors, Who get to use your code to reduce their barrier for entry. Then again, Software code at current times aren't that big of a barrier to entry. One thing which all these discussions prove to me is that open-source application funding is very complex, Depending upon it for livelihood with just good will of the consumers is very risky as consumers are on average poor and corporations are on average greedy.
    - dllthomas 4y ago
      As you say, it depends a lot on the project, but you're thinking too narrowly when it comes to types of projects. IME, dual license is most applicable to libraries that might wind up in native applications. With, say, "GPL or pay us for proprietary" a company trying to ship a native app is faced with the choice of not using the library, paying for the library, or releasing their product under the GPL to use the library while avoiding paying for it.
      - Abishek_Muthian 4y ago
        Have you seen such dual-licensed library with GPL? Just curious for a real example.
        colejohnson66 4y ago
        Not the GPL, but Qt GUI toolkit is famously LGPL-or-cash
        Abishek_Muthian 4y ago
        Ah Qt! I knew we often discussed about license of some project. Thanks. Once again, LGPL being more permissible than AGPL shows IMO the need for having a permissible license for the dual-license.
        dllthomas 4y ago
        > the need for having a permissible license for the dual-license. A more permissive license generally improves adoption. For the same level of adoption, a less permissive license drives more revenue in the dual-license model. Maybe a permissive license is still the way to go (certainly getting adoption is often difficult), but it is not the dual license situation motivating that. Contrast a "give away the software and sell support" business model, where (sufficient) adoption is everything and more restrictions on the license doesn't do anything for the business. With a maximally permissive license, I hesitate to call it "dual licensing", as it stops being the license your paying customers are actually paying for but rather hosting, support, or warm fuzzies.

Abishek_Muthian 4y ago

Thanks for the clarification. So, It's best to use permissible license for the open-source version of the application in case of dual-license if we want to take back the contributions to our non open-source version. I see this is what dual-licensed projects seem to do, I use open-source version of Aseprite[1] under MIT but I paid for the license on their website under EULA. If anyone has seen a dual-licensed project where the open-source version is under AGPL or similar restrictive license then please mention. [1] https://github.com/aseprite/aseprite/ https://github.com/aseprite/aseprite/

dllthomas 4y ago
> So, It's best to use permissible license for the open-source version of the application in case of dual-license if we want to take back the contributions to our non open-source version. That's one option; the other is to require that contributors assign you copyright of their contributions (perhaps with compensation) so you can release it in the same manner as your own code. Narrowly focused on the effectiveness of the dual license scheme itself, permissive licenses "don't work as well" because there is less incentive for anyone to pay you for the other license; typically all they'd be avoiding is the attribution requirements.
- Abishek_Muthian 4y ago
  > That's one option; the other is to require that contributors assign you copyright of their contributions (perhaps with compensation) I thought about it before I made my previous comment, Good to know this is a thing. > permissive licenses "don't work as well" because there is less incentive for anyone to pay you for the other license; typically all they'd be avoiding is the attribution requirements. As far consumers are concerned, I think it largely depends upon the project; If it's complex to setup and run then I guess people would use the hosted version. I use open-source Aseprite because it's available on AUR, But I did pay for the license on their website which I presume most wouldn't. Perhaps the real concern with permissible license are the competitors, Who get to use your code to reduce their barrier for entry. Then again, Software code at current times aren't that big of a barrier to entry. One thing which all these discussions prove to me is that open-source application funding is very complex, Depending upon it for livelihood with just good will of the consumers is very risky as consumers are on average poor and corporations are on average greedy.
  - dllthomas 4y ago
    As you say, it depends a lot on the project, but you're thinking too narrowly when it comes to types of projects. IME, dual license is most applicable to libraries that might wind up in native applications. With, say, "GPL or pay us for proprietary" a company trying to ship a native app is faced with the choice of not using the library, paying for the library, or releasing their product under the GPL to use the library while avoiding paying for it.
    - Abishek_Muthian 4y ago
      Have you seen such dual-licensed library with GPL? Just curious for a real example.
      - colejohnson66 4y ago
        Not the GPL, but Qt GUI toolkit is famously LGPL-or-cash
        Abishek_Muthian 4y ago
        Ah Qt! I knew we often discussed about license of some project. Thanks. Once again, LGPL being more permissible than AGPL shows IMO the need for having a permissible license for the dual-license.
        dllthomas 4y ago
        > the need for having a permissible license for the dual-license. A more permissive license generally improves adoption. For the same level of adoption, a less permissive license drives more revenue in the dual-license model. Maybe a permissive license is still the way to go (certainly getting adoption is often difficult), but it is not the dual license situation motivating that. Contrast a "give away the software and sell support" business model, where (sufficient) adoption is everything and more restrictions on the license doesn't do anything for the business. With a maximally permissive license, I hesitate to call it "dual licensing", as it stops being the license your paying customers are actually paying for but rather hosting, support, or warm fuzzies.