4 ms·

While Qt is awesome, I'm not so sure about it's recent license change. I know lots of people would love that, but for other programmers (stuck in big companies)

by malkia 11y ago

While Qt is awesome, I'm not so sure about it's recent license change. I know lots of people would love that, but for other programmers (stuck in big companies) this simply means that they can't use it, as not always money would be approved for commercial projects, even if the project do have a big budget.

deleted 11y ago
[deleted]
dd9990 11y ago
I'm moving towards using Qt at work. My understanding is that nothing major changed with regards to licensing recently. Why do you think it is now more restrictive?
- malkia 11y ago
  It's not, but it scares company lawyers nonetheless. For example if you develop a tool for internal use, and later decide to ship to 3rd parties, or more general audience (say mod tool editor for a game).
SwellJoe 11y ago
I don't understand this comment. Isn't it still under LGPL or more liberal licenses, depending on the component, as it has always been? According to the website, it is. http://doc.qt.io/qt-5/licensing.html http://doc.qt.io/qt-5/licensing.html I see nothing in that list that seems different or that would prevent one from building commercial products on Qt without licensing fees.
- rcxdude 11y ago
  It's gone from (L)GPL v2 to v3, which some companies care a lot about (e.g. Apple).
  - SwellJoe 11y ago
    Apple already refused to use LGPL v2 stuff. They refused to use anything (L)GPL in the past and now they continue to refuse to use anything (L)GPL. Apple is not a useful data point about what has changed, because they have not changed position based on v2 vs v3.
- forgettableuser 11y ago
  LGPL v3 is _really_ complicated. That's a red flag for a lot of corporate lawyers. As a result, some issues arise, such as code that is stuck on GPLv2 (e.g. removed the upgrade clause like the Linux kernel) may be incompatible with LGPLv3. This blog tries to explain some of the issues. http://nmav.gnutls.org/2013/03/the-perils-of-lgplv3.html http://nmav.gnutls.org/2013/03/the-perils-of-lgplv3.html
  - belorn 11y ago
    I strongly disagree, since at a conceptual level it is a very simple license. As a distributor, you got provide users with the source code of the LGPLv3 parts and permit/provide so they can replace it with a modified version of their choice. To make a car analogy, if the tires are made under LGPLv3, you got to tell them what kind of rubber it is made of and permit car owners to change the tire without the car saying "unapproved parts used, so I will refuse to start now until you have bought approved tires from an official car dealer". Every car made before 2000 managed to do this without even thinking about it. FSF consider GPLv2 to be incompatible with this deal from a US-legal view, which is the same view that claim "further restrictions" only covers restrictions made from software licenses.
detaro 11y ago
The move from LGPL 2.1 to 3 should only affect you if you ship locked-down devices, not if you develop "normal" software.
- deleted 11y ago
  [deleted]
  - baghira 11y ago
    The FSF's interpretation is valid for GPLv2 and LGPLv2 as well, since the line "You may not impose any further restrictions on the recipients' exercise of the rights granted herein." is also in there (not everyone agrees with this interpreation, but that's beside the point). The anti-tivoization clauses are not considered to be the problem, generally, since app developers are not distributing tivoized hardware or tivoizing it with their software. Also, the path for solving compliance problems for (L)GPLv3 is much more well defined, as opposed to the case of v2. That's a plus.
  - detaro 11y ago
    But that isn't new with the version change, is it? LGPL 2.1 also requires you to make your source code or object files available for iOS apps, and the restrictions clause is there as well.
- mook 11y ago
  Wouldn't it prevent people writing GPL2 software from using it, as the anti-tivoization would not be GPL2 no additional restrictions clause friendly? See the GPL FAQ compatibility chart [1], bottom left. The case I'm thinking of is where if you fork somebody else's GPL2 project and don't expect to be able to ask them to relicense (e.g. code from a company that no longer exists). [1]: https://www.gnu.org/licenses/gpl-faq.html#gpl-compat-matrix https://www.gnu.org/licenses/gpl-faq.html#gpl-compat-matrix
  - detaro 11y ago
    Seems so, missed that aspect.

by malkia 11y ago

deleted 11y ago

[deleted]

dd9990 11y ago

I'm moving towards using Qt at work. My understanding is that nothing major changed with regards to licensing recently. Why do you think it is now more restrictive?

malkia 11y ago
It's not, but it scares company lawyers nonetheless. For example if you develop a tool for internal use, and later decide to ship to 3rd parties, or more general audience (say mod tool editor for a game).

SwellJoe 11y ago

I don't understand this comment. Isn't it still under LGPL or more liberal licenses, depending on the component, as it has always been? According to the website, it is. http://doc.qt.io/qt-5/licensing.html http://doc.qt.io/qt-5/licensing.html I see nothing in that list that seems different or that would prevent one from building commercial products on Qt without licensing fees.

rcxdude 11y ago
It's gone from (L)GPL v2 to v3, which some companies care a lot about (e.g. Apple).
- SwellJoe 11y ago
  Apple already refused to use LGPL v2 stuff. They refused to use anything (L)GPL in the past and now they continue to refuse to use anything (L)GPL. Apple is not a useful data point about what has changed, because they have not changed position based on v2 vs v3.
forgettableuser 11y ago
LGPL v3 is _really_ complicated. That's a red flag for a lot of corporate lawyers. As a result, some issues arise, such as code that is stuck on GPLv2 (e.g. removed the upgrade clause like the Linux kernel) may be incompatible with LGPLv3. This blog tries to explain some of the issues. http://nmav.gnutls.org/2013/03/the-perils-of-lgplv3.html http://nmav.gnutls.org/2013/03/the-perils-of-lgplv3.html
- belorn 11y ago
  I strongly disagree, since at a conceptual level it is a very simple license. As a distributor, you got provide users with the source code of the LGPLv3 parts and permit/provide so they can replace it with a modified version of their choice. To make a car analogy, if the tires are made under LGPLv3, you got to tell them what kind of rubber it is made of and permit car owners to change the tire without the car saying "unapproved parts used, so I will refuse to start now until you have bought approved tires from an official car dealer". Every car made before 2000 managed to do this without even thinking about it. FSF consider GPLv2 to be incompatible with this deal from a US-legal view, which is the same view that claim "further restrictions" only covers restrictions made from software licenses.

detaro 11y ago

The move from LGPL 2.1 to 3 should only affect you if you ship locked-down devices, not if you develop "normal" software.

deleted 11y ago
[deleted]
- baghira 11y ago
  The FSF's interpretation is valid for GPLv2 and LGPLv2 as well, since the line "You may not impose any further restrictions on the recipients' exercise of the rights granted herein." is also in there (not everyone agrees with this interpreation, but that's beside the point). The anti-tivoization clauses are not considered to be the problem, generally, since app developers are not distributing tivoized hardware or tivoizing it with their software. Also, the path for solving compliance problems for (L)GPLv3 is much more well defined, as opposed to the case of v2. That's a plus.
- detaro 11y ago
  But that isn't new with the version change, is it? LGPL 2.1 also requires you to make your source code or object files available for iOS apps, and the restrictions clause is there as well.
mook 11y ago
Wouldn't it prevent people writing GPL2 software from using it, as the anti-tivoization would not be GPL2 no additional restrictions clause friendly? See the GPL FAQ compatibility chart [1], bottom left. The case I'm thinking of is where if you fork somebody else's GPL2 project and don't expect to be able to ask them to relicense (e.g. code from a company that no longer exists). [1]: https://www.gnu.org/licenses/gpl-faq.html#gpl-compat-matrix https://www.gnu.org/licenses/gpl-faq.html#gpl-compat-matrix
- detaro 11y ago
  Seems so, missed that aspect.