3 ms·

You can sell GPL software. You can even sell GPL software under proprietary license as long as you are the copyright owner (dual-licensing). Really, when you t

You can sell GPL software. You can even sell GPL software under proprietary license as long as you are the copyright owner (dual-licensing). Really, when you take time to understand real restrictions, as opposed to repeated myths, the only argument in favor of permissive license is that they help big players use free labor.

mr_toad 1y ago
You don’t even need to be the copyright owner to sell GPL software, but it’s unlikely many would pay for it.
- bheadmaster 1y ago
  > You don't even need to be the copyright owner to sell GPL software You do, if sell means also allowing another vendor to use your software as a part of their proprietary software. GPL alone, if you're not the copyright owner, would not allow you to sell software in this way. But if you are the copyright owner, you can bypass GPL and sell a proprietary license to the vendor saying "you can use this software in your proprietary product if you pay me $XYZ".
  - bheadmaster 1y ago
    For anyone who thinks I'm talking out of my ass, consider Qt. If you don't own the Qt copyright, you cannot sell Qt to a company who wants to use it to build a proprietary product - since Qt is GPL licensed, using it in a proprietary product would not be permitted. But since The Qt Company owns the copyright, they can sell their own software to companies that want to build a proprietary product with it - they just sell it under a proprietary license, specifically tailored for this. The fact that it was previously released under GPL is irrelevant, because the copyright holder can license it under as many licenses as they want. If you don't own the copyright to it, you can only """sell""" GPL software in a manner in which local DVD shops sold pirated movies back in the early 2000s.
  - kmacleod 1y ago
    Red Hat, SUSE, Canonical, and myself, among many, "sell" GPL software that are used by others as part of their proprietary products. Each of those, and the customers, are required to make the source they received (not their own proprietary source), including changes, available to those that receive the software (thus indirectly back to the public and the authors). AGPL is similar but includes the case of providing sources for products used in Internet services.
- rerdavies 1y ago
  There are all kinds of nighmarishly horrible ways to sell GPL software. e.g. inscrutable build procedures, undocumented build dependencies, crippleware, indispensable non-open-source tools). A significant part of the reason why I avoid GPL software like the plague is all of the horrible schemes owners of GPL software have come up with in order to monetize their supposedly "free" software.
  - wolvesechoes 1y ago
    > A significant part of the reason why I avoid GPL software like the plague is all of the horrible schemes owners of GPL software have come up with in order to monetize their supposedly "free" software. These schemes wouldn't be necessary if industry would start paying for the stuff they use. And I wouldn't call it a "scheme" when the deal is clear - you either pay by giving money to the author or by giving source code to your users. Choice is yours, and since you are developing proprietary program you shouldn't really have any qualms with the first approach, unless you are a leech.
    - rerdavies 1y ago
      The one surefire way to ensure that you never get a big corporate sponsorship: ship your code with a GPL license. Industry does in fact sponsor a LOT of permissively-licensed opensource software. Apache. Webkit. Android. openssh. boost. x11. VSCode. react. jQuery. node.js. Ruby on Rails. llvm. The International Components for Unicode project. Mono (and now .net!). And an endless list of opensource libraries published by Google and Microsoft (and others). To cite really big examples. But there is a very long list of smaller examples as well. And the way I pay personally is by releasing my own software under a permissive license that respects and honors the intent of those whose permissively-licensed libraries are used by my project. Respectfully, I think it might be time to move on, and accept the fact that GPL is a failed experiment that has been superceded by permissive licenses.
  - kmacleod 1y ago
    If it helps any, at two companies I was responsible for ensuring that all FOSS was made available to customers in an easily re-buildable, re-imageable way alongside our proprietary binaries.
- em-bee 1y ago
  how would that be any different from selling someone elses permissibly licensed software? as a user i have the choice between yours and the original in both cases.
  - kmacleod 1y ago
    Permissibly licensed software does not require you to provide sources or the changes to it. Copyleft licenses require the source, including changes, to be provided. The original purpose of copyleft is roughly the "right to repair". When you buy a product: you receive the necessary source, build instructions, and tools in some cases, to update and replace the software you received. The use of copyleft software passes those requirements on through proprietary users. Note that one can still build a proprietary product as long as all the copyleft pass-through software can be modified and replaced on the product.

mr_toad 1y ago

You don’t even need to be the copyright owner to sell GPL software, but it’s unlikely many would pay for it.

bheadmaster 1y ago
> You don't even need to be the copyright owner to sell GPL software You do, if sell means also allowing another vendor to use your software as a part of their proprietary software. GPL alone, if you're not the copyright owner, would not allow you to sell software in this way. But if you are the copyright owner, you can bypass GPL and sell a proprietary license to the vendor saying "you can use this software in your proprietary product if you pay me $XYZ".
- bheadmaster 1y ago
  For anyone who thinks I'm talking out of my ass, consider Qt. If you don't own the Qt copyright, you cannot sell Qt to a company who wants to use it to build a proprietary product - since Qt is GPL licensed, using it in a proprietary product would not be permitted. But since The Qt Company owns the copyright, they can sell their own software to companies that want to build a proprietary product with it - they just sell it under a proprietary license, specifically tailored for this. The fact that it was previously released under GPL is irrelevant, because the copyright holder can license it under as many licenses as they want. If you don't own the copyright to it, you can only """sell""" GPL software in a manner in which local DVD shops sold pirated movies back in the early 2000s.
- kmacleod 1y ago
  Red Hat, SUSE, Canonical, and myself, among many, "sell" GPL software that are used by others as part of their proprietary products. Each of those, and the customers, are required to make the source they received (not their own proprietary source), including changes, available to those that receive the software (thus indirectly back to the public and the authors). AGPL is similar but includes the case of providing sources for products used in Internet services.
rerdavies 1y ago
There are all kinds of nighmarishly horrible ways to sell GPL software. e.g. inscrutable build procedures, undocumented build dependencies, crippleware, indispensable non-open-source tools). A significant part of the reason why I avoid GPL software like the plague is all of the horrible schemes owners of GPL software have come up with in order to monetize their supposedly "free" software.
- wolvesechoes 1y ago
  > A significant part of the reason why I avoid GPL software like the plague is all of the horrible schemes owners of GPL software have come up with in order to monetize their supposedly "free" software. These schemes wouldn't be necessary if industry would start paying for the stuff they use. And I wouldn't call it a "scheme" when the deal is clear - you either pay by giving money to the author or by giving source code to your users. Choice is yours, and since you are developing proprietary program you shouldn't really have any qualms with the first approach, unless you are a leech.
  - rerdavies 1y ago
    The one surefire way to ensure that you never get a big corporate sponsorship: ship your code with a GPL license. Industry does in fact sponsor a LOT of permissively-licensed opensource software. Apache. Webkit. Android. openssh. boost. x11. VSCode. react. jQuery. node.js. Ruby on Rails. llvm. The International Components for Unicode project. Mono (and now .net!). And an endless list of opensource libraries published by Google and Microsoft (and others). To cite really big examples. But there is a very long list of smaller examples as well. And the way I pay personally is by releasing my own software under a permissive license that respects and honors the intent of those whose permissively-licensed libraries are used by my project. Respectfully, I think it might be time to move on, and accept the fact that GPL is a failed experiment that has been superceded by permissive licenses.
- kmacleod 1y ago
  If it helps any, at two companies I was responsible for ensuring that all FOSS was made available to customers in an easily re-buildable, re-imageable way alongside our proprietary binaries.
em-bee 1y ago
how would that be any different from selling someone elses permissibly licensed software? as a user i have the choice between yours and the original in both cases.
- kmacleod 1y ago
  Permissibly licensed software does not require you to provide sources or the changes to it. Copyleft licenses require the source, including changes, to be provided. The original purpose of copyleft is roughly the "right to repair". When you buy a product: you receive the necessary source, build instructions, and tools in some cases, to update and replace the software you received. The use of copyleft software passes those requirements on through proprietary users. Note that one can still build a proprietary product as long as all the copyleft pass-through software can be modified and replaced on the product.