4 ms·

I'd love to know more about opinions of fellow commenters, just a "what-if" question: If tomorrow you had some big project such as Qt in your hands, and had 10

by j1elo 7y ago

I'd love to know more about opinions of fellow commenters, just a "what-if" question: If tomorrow you had some big project such as Qt in your hands, and had 100% freedom to choose how to proceed with it (in matters such as what license to apply, what sustainability model to seek, etc.) what would you do? I always feel that pure GPL is the best but only idealistic way to go, because working for free is not compatible with paying your bills. Then LGPL, and maybe other licenses such as Apache, are nice but at the end of the day allow that private companies with private pockets benefit from the project without helping it at all (either with work or with cash), which I know is one side of the "freedom" that those open-source licenses bring, but it's one side that I personally don't really like (I'm more of a pragmatist than an idealist). For that reason I feel like dual GPL+Commercial might be the best of both worlds. It would allow basing a company around it, and paying other devs to feed their families, and at the same time users of the GPL variant would themselves be benefiting from and contributing to open-source.

jfkebwjsbx 7y ago
If your only goal is to pay devs fairly and do the best for the project, the best way for a library is MIT (for an app, GPL) and having a Foundation that companies support with money and development efforts. Examples: Linux, Blender. If you want to make actual profits, then it is the same license choice but with a company that sells valuable long-term support, development and perhaps proprietary extra features. Examples: RedHat, Canonical, GitLab.
yoz-y 7y ago
Assuming the project is a library or a tool that people will need to somehow embed in their program I wouldn't go with GPL. It has some restrictions that are for various reasons hard to accept for a large amount of clients. People try arguing that "you could do this or that to accommodate" but the fact is that many for-profit corporations, even those working with open projects, will have a no-GPL policy. Also with the current trend for web services and what not GPL can be worked around, hence the AGPL. I'd probably go with LGPL and commercial plugins that enhance the functionality. But this depends on the product having some features that could be mainly useful for companies but not really for individuals.
- jfkebwjsbx 7y ago
  Even LGPL is banned in many companies. And some devs want static linking without releasing object files.
  - jabl 7y ago
    To some extent LGPL and other "weak" copyleft licenses like MPL or EPL are in an awkward middle-way spot in that they have disadvantages of both full copyleft and liberal licenses, but not that much upside. Either go full GPL, or even AGPL, or then use a liberal license like Apache-2, IMHO.
troydavis 7y ago
One challenge specific to Qt is that their market is completely different than it was when KDE adopted Qt way back in the late 90s. I ran prerelease KDE briefly in that era and it was incredible for what it was. The other cross-platform options were things like Java Swing and Tk. They were ugly and had funky UI behavior. Even then, the total addressable market was pretty small, but at least it was anyone who wanted to make a cross-platform app. Now, most people who want to do that use Electron, React Native, or make a browser extension (or, of course, a Web site). The market is smaller: cross-platform makers who are absolutely committed to Qt or for whom it’s a uniquely good fit (like because they’re using C++). Think of it like a pharma company with a drug that only treats a rare disease. The TAM is tiny. Unless someone discovers that it also treats some other disease, there’s not a lot they can do to expand the customer base. If they want to make more money or want more short-term revenue (usually at the expense of long-term revenue), charging existing customers more may actually be the best option for them.
- j1elo 7y ago
  When I wrote my first Qt-based code, it still was Trolltech. C++ seemed the obvious choice for a performant application. But now, I think that C++ is more of a drawback than an advantage for the Qt project. C++ today seems a good fit for high-performance, very niche tools such as trading, games, machine learning libraries, and such, but not for "simpler" software such as the UI of an application. Also finding good competent C++ devs seems to be much harder now. I myself feel like having to go "back" to writing C++ is a bummer, having worked with other more modern technologies. Bindings to other languages have always been a second-class citizen. The Python one is very nice, though, but that's all. I believe it comes, again, as a difficulty introduced by the language itself.
  - pfranz 7y ago
    I feel like Python bindings came along kicking and screaming by the Qt owners. PyQt was originally developed and licensed independently. Nokia was negotiating a relicensing with Riverbank Software. When that broke down and they wrote PySide--basically a reimplementation. That was kind of abandoned with Python 3 and Qt5 until the VFX industry made a big push for PySide2 (rebranded Qt for Python). Even with all of that, you generally end up reading the C++ docs, it isn't particularly Pythonic, and there are weird gotchas. I can't really fault them for it because you're bound to get that with bindings to another language and it is much better than other UI toolkits.
jabl 7y ago
GPL+Commercial requires copyright assignment, which is a pretty sure way to turn off potential contributors. I mean, if you don't want to contribute to BSD-style licensed projects because you don't want others to leech without giving anything back, how on earth could you simultaneously be ok with assigning your copyright to some (sleezy/evil/you name it) corporation? And no, I don't really have an answer either. Successful open source business models are few and far between. Redhat is perhaps the one big example of a (very) successful open source company. To some extent I think the worry about leeching is something which can be addressed with culture as well as licenses. Plenty of successful BSD/apache licensed projects around, including with largely corporate contributors, because they understand the long-term value from contributing to the common pool rather than forking and trying to sell "proprietary enhanced" versions.

by j1elo 7y ago

jfkebwjsbx 7y ago

If your only goal is to pay devs fairly and do the best for the project, the best way for a library is MIT (for an app, GPL) and having a Foundation that companies support with money and development efforts. Examples: Linux, Blender. If you want to make actual profits, then it is the same license choice but with a company that sells valuable long-term support, development and perhaps proprietary extra features. Examples: RedHat, Canonical, GitLab.

yoz-y 7y ago

Assuming the project is a library or a tool that people will need to somehow embed in their program I wouldn't go with GPL. It has some restrictions that are for various reasons hard to accept for a large amount of clients. People try arguing that "you could do this or that to accommodate" but the fact is that many for-profit corporations, even those working with open projects, will have a no-GPL policy. Also with the current trend for web services and what not GPL can be worked around, hence the AGPL. I'd probably go with LGPL and commercial plugins that enhance the functionality. But this depends on the product having some features that could be mainly useful for companies but not really for individuals.

jfkebwjsbx 7y ago
Even LGPL is banned in many companies. And some devs want static linking without releasing object files.
- jabl 7y ago
  To some extent LGPL and other "weak" copyleft licenses like MPL or EPL are in an awkward middle-way spot in that they have disadvantages of both full copyleft and liberal licenses, but not that much upside. Either go full GPL, or even AGPL, or then use a liberal license like Apache-2, IMHO.

troydavis 7y ago

One challenge specific to Qt is that their market is completely different than it was when KDE adopted Qt way back in the late 90s. I ran prerelease KDE briefly in that era and it was incredible for what it was. The other cross-platform options were things like Java Swing and Tk. They were ugly and had funky UI behavior. Even then, the total addressable market was pretty small, but at least it was anyone who wanted to make a cross-platform app. Now, most people who want to do that use Electron, React Native, or make a browser extension (or, of course, a Web site). The market is smaller: cross-platform makers who are absolutely committed to Qt or for whom it’s a uniquely good fit (like because they’re using C++). Think of it like a pharma company with a drug that only treats a rare disease. The TAM is tiny. Unless someone discovers that it also treats some other disease, there’s not a lot they can do to expand the customer base. If they want to make more money or want more short-term revenue (usually at the expense of long-term revenue), charging existing customers more may actually be the best option for them.

j1elo 7y ago
When I wrote my first Qt-based code, it still was Trolltech. C++ seemed the obvious choice for a performant application. But now, I think that C++ is more of a drawback than an advantage for the Qt project. C++ today seems a good fit for high-performance, very niche tools such as trading, games, machine learning libraries, and such, but not for "simpler" software such as the UI of an application. Also finding good competent C++ devs seems to be much harder now. I myself feel like having to go "back" to writing C++ is a bummer, having worked with other more modern technologies. Bindings to other languages have always been a second-class citizen. The Python one is very nice, though, but that's all. I believe it comes, again, as a difficulty introduced by the language itself.
- pfranz 7y ago
  I feel like Python bindings came along kicking and screaming by the Qt owners. PyQt was originally developed and licensed independently. Nokia was negotiating a relicensing with Riverbank Software. When that broke down and they wrote PySide--basically a reimplementation. That was kind of abandoned with Python 3 and Qt5 until the VFX industry made a big push for PySide2 (rebranded Qt for Python). Even with all of that, you generally end up reading the C++ docs, it isn't particularly Pythonic, and there are weird gotchas. I can't really fault them for it because you're bound to get that with bindings to another language and it is much better than other UI toolkits.

jabl 7y ago

GPL+Commercial requires copyright assignment, which is a pretty sure way to turn off potential contributors. I mean, if you don't want to contribute to BSD-style licensed projects because you don't want others to leech without giving anything back, how on earth could you simultaneously be ok with assigning your copyright to some (sleezy/evil/you name it) corporation? And no, I don't really have an answer either. Successful open source business models are few and far between. Redhat is perhaps the one big example of a (very) successful open source company. To some extent I think the worry about leeching is something which can be addressed with culture as well as licenses. Plenty of successful BSD/apache licensed projects around, including with largely corporate contributors, because they understand the long-term value from contributing to the common pool rather than forking and trying to sell "proprietary enhanced" versions.