Lazarus

Miscellaneous => Other => Topic started by: guest65405 on March 29, 2020, 10:53:43 am

Title: Qt offering changes 2020
Post by: guest65405 on March 29, 2020, 10:53:43 am
https://www.qt.io/blog/qt-offering-changes-2020

I took this recap from https://valdyas.org/fading/software/about-qt-offering-changes-2020:


Unrelated:

As my own experiment I copied cbindings from the qt5 inferface of Lazarus (2.0.6) and tried to port it to CopperSpice. Check CopperSpice here: https://www.copperspice.com/

But I can't get any further. Because even building the binding with Qt5 itself with Qt 5.11 from my Debian 10 system failed. QtCreator said there is no x11extras nor QX11Info. I don't know how you guys managed to got it build in the first place.

This mean the binding is lacked of maintenance. Could this Qt offering changes give us an opportunity to revisit it all?

Disclaimer:

I searched the internet for Qt fork and found CopperSpice. I'm not related with them. I don't hype for them.

The fact is I like CopperSpice because it has Qt MOC removed. But I also dislike their build system, CMake. I tried to port the Qt5Pas.pro to CMake but finally gave up. CMake just is not for me!

p/s: if I could get further, I still can't become the maintainer of this, potentially, CopperSpice Widgetset for Lazarus. My computer is too old and slow to be able to smoothly build C++. Someone with a more powerful computer if interested could try if it even possible. I think to conversion from Qt5 to CopperSpice is not very painful, as I ran CopperSpice's PepperMill conversion tool on the binding's header successfully without any warnings.

p/s: sorry if you found my English to be clumsy, it's all Google translate with manual fixes by me.
Title: Re: Qt offering changes 2020
Post by: avra on March 29, 2020, 01:21:13 pm
CopperSpice is LGPL 2.1. According to https://tldrlegal.com/license/gnu-lesser-general-public-license-v2.1-(lgpl-2.1) it means that
Quote
Anything statically linked to the library can only be redistributed under LGPL, but applications that use the library don't have to be. You must allow reverse engineering of your application as necessary to debug and relink the library.
Who ever wants to use it should keep this in mind. Last restriction is too much for my use case.
Title: Re: Qt offering changes 2020
Post by: guest65405 on March 29, 2020, 01:58:25 pm
CopperSpice is LGPL 2.1. According to https://tldrlegal.com/license/gnu-lesser-general-public-license-v2.1-(lgpl-2.1) it means that
Quote
Anything statically linked to the library can only be redistributed under LGPL, but applications that use the library don't have to be. You must allow reverse engineering of your application as necessary to debug and relink the library.
Who ever wants to use it should keep this in mind. Last restriction is too much for my use case.

Isn't the Qt community edition use this license too?

https://doc.qt.io/qt-5/lgpl.html

It's LGPL, but version 3. I don't know if there is different between version 2.1 and 3.

p/s: it has the same requirements as LGPLv2.1: https://tldrlegal.com/license/gnu-lesser-general-public-license-v3-(lgpl-3)

So it's not a problem at all. People still use and release software built with the LCL-Qt5 widgetset. Of course, they dynamic link it and ship the Qt dlls with their software.
Title: Re: Qt offering changes 2020
Post by: guest65405 on March 29, 2020, 02:10:31 pm
CopperSpice is LGPL 2.1. According to https://tldrlegal.com/license/gnu-lesser-general-public-license-v2.1-(lgpl-2.1) it means that
Quote
Anything statically linked to the library can only be redistributed under LGPL, but applications that use the library don't have to be. You must allow reverse engineering of your application as necessary to debug and relink the library.
Who ever wants to use it should keep this in mind. Last restriction is too much for my use case.

The link you posted doesn't work. I provide an updated link here: https://tldrlegal.com/license/gnu-lesser-general-public-license-v2.1-(lgpl-2.1)

Perhaps I misunderstood your post. The problematic statement is:

Quote
You must allow reverse engineering of your application as necessary to debug and relink the library.

I can't accept this, either. So we should forget about CopperSpice and come back to the main problem I want to discuss on this thread: Qt offering changes 2020.
Title: Re: Qt offering changes 2020
Post by: marcov on March 29, 2020, 06:37:57 pm
I read a bit and I don't really understand if this is only for official QT LTS binaries.

It seems at least the whole of *nix doesn't use these (https://tsdgeos.blogspot.com/2020/01/the-qt-company-is-stopping-qt-lts.html )

so the problems are (maybe?) mainly for QT users on OS X and Windows?

See also https://www.reddit.com/r/kde/comments/euoujm/qt_offering_changes_2020/

Title: Re: Qt offering changes 2020
Post by: avra on March 30, 2020, 01:09:24 pm
The link you posted doesn't work. I provide an updated link here: https://tldrlegal.com/license/gnu-lesser-general-public-license-v2.1-(lgpl-2.1)
Try your link and it will also lead to 404 error. Both mine and yours URL are fine but forum has a bug of not including last bracket when converting text URLs to clickable links.

Quote
You must allow reverse engineering of your application as necessary to debug and relink the library.

I can't accept this, either. So we should forget about CopperSpice and come back to the main problem I want to discuss on this thread: Qt offering changes 2020.
Yes, LGPL 2.1 forces you to allow reverse engineering when dynamically linked to a library. That is why CopperSpice is a no go for me. Good news is that LGPL 3.0 does not have this request, and that since 2016 and version 5.7,  QT has changed licensing to this: "All Qt Essentials will from now on be licensed under LGPLv3, GPLv2 and commercial license terms." (source: https://www.qt.io/blog/2016/01/13/new-agreement-with-the-kde-free-qt-foundation). QT Essentials covers part used by Lazarus so we are safe. Safe only conditionally, since with 2020 changes, if your application links dynamically to new QT LTS and you do not have a commercial QT account you might be in trouble. QT offline installer is also not allowed to non commercial accounts any more. So you might be in trouble if your application runs on some distro which uses new QT LTS and doesn't provide it's own build or at least QT independent build. I did not find info how shady that could be for app owner. Although that is unlikely situation I can not say that such situation is impossible. Similar is for Windows. QT official offline installer will not be available any more, so you would have to provide your own custom built DLLs or use some other independent source for DLLs or installer. It seams that 2020 changes have been made by QT to force companies which software depends on some specific QT build to become their customers.

All said is just my (very possibly wrong) understanding and I am not a layer so do not depend on it.
Title: Re: Qt offering changes 2020
Post by: marcov on March 30, 2020, 03:04:18 pm
distros mostly don't use LTS.

Open source distros are becoming more and more just testing grounds for the commerial distros this way.
Title: Re: Qt offering changes 2020
Post by: AmatCoder on March 30, 2020, 03:46:14 pm
Quote
[...] LGPL 2.1 forces you to allow reverse engineering when dynamically linked to a library. [...] LGPL 3.0 does not have this request[...]
This is not true.
Edit: Re-reading the LGPL license is not completely clear to me...Definition of "Combined Work" seems ambiguous...

Read the official FAQ: https://www.gnu.org/licenses/gpl-faq.html#LGPLStaticVsDynamic (https://www.gnu.org/licenses/gpl-faq.html#LGPLStaticVsDynamic)

Quote
    For the purpose of complying with the LGPL (any extant version: v2, v2.1 or v3):

        (1) If you statically link against an LGPLed library, you must also provide your application in an object (not necessarily source) format, so that a user has the opportunity to modify the library and relink the application.

        (2) If you dynamically link against an LGPLed library already present on the user's computer, you need not convey the library's source. On the other hand, if you yourself convey the executable LGPLed library along with your application, whether linked with statically or dynamically, you must also convey the library's sources, in one of the ways for which the LGPL provides.

Edit: I am not a lawyer either... :-[
Title: Re: Qt offering changes 2020
Post by: Zoran on March 31, 2020, 06:38:31 am
The link you posted doesn't work. I provide an updated link here: https://tldrlegal.com/license/gnu-lesser-general-public-license-v2.1-(lgpl-2.1)
Try your link and it will also lead to 404 error. Both mine and yours URL are fine but forum has a bug of not including last bracket when converting text URLs to clickable links.


Always enclose all links in url tags. See the difference between these (the second one should work):
https://tldrlegal.com/license/gnu-lesser-general-public-license-v2.1-(lgpl-2.1)
https://tldrlegal.com/license/gnu-lesser-general-public-license-v2.1-(lgpl-2.1) (https://tldrlegal.com/license/gnu-lesser-general-public-license-v2.1-(lgpl-2.1))
Title: Re: Qt offering changes 2020
Post by: avra on March 31, 2020, 02:18:30 pm
Quote
[...] LGPL 2.1 forces you to allow reverse engineering when dynamically linked to a library. [...] LGPL 3.0 does not have this request[...]
This is not true.
Edit: Re-reading the LGPL license is not completely clear to me...Definition of "Combined Work" seems ambiguous...

Read the official FAQ: https://www.gnu.org/licenses/gpl-faq.html#LGPLStaticVsDynamic (https://www.gnu.org/licenses/gpl-faq.html#LGPLStaticVsDynamic)

In legal documents every word and comma count in, and you need a lawyer for proper understanding so I do read it but only from time to time. I use much more understandable explanations in non=lawyer english that can be found at tldrlegal.com. If they are wrong then I am wrong, too.

This is quick summary of LGPL 2.1 from https://tldrlegal.com/license/gnu-lesser-general-public-license-v2.1-(lgpl-2.1) (https://tldrlegal.com/license/gnu-lesser-general-public-license-v2.1-(lgpl-2.1))
Quote
This license mainly applies to libraries. You may copy, distribute and modify the software provided that you state modifications and license them under LGPL-2.1. Anything statically linked to the library can only be redistributed under LGPL, but applications that use the library don't have to be.  You must allow reverse engineering of your application as necessary to debug and relink the library.

and this is quick summary of LGPL 3.0 from https://tldrlegal.com/license/gnu-lesser-general-public-license-v3-(lgpl-3) (https://tldrlegal.com/license/gnu-lesser-general-public-license-v3-(lgpl-3))
Quote
This license is mainly applied to libraries. You may copy, distribute and modify the software provided that modifications are described and licensed for free under LGPL. Derivatives works (including modifications or anything statically linked to the library) can only be redistributed under LGPL, but applications that use the library don't have to be.

The main difference that I was interested was reverse engineering condition. You take your own conclusion.
Title: Re: Qt offering changes 2020
Post by: lucamar on March 31, 2020, 02:58:41 pm
The main difference that I was interested was reverse engineering condition. You take your own conclusion.

Read again, avra:

Quote
You must allow reverse engineering of your application as necessary to debug and relink the library.

If you're dinamically linking there is no need at all to "debug and relink" in the context of your application; that condition applies only when you link statically. The license doesn't go and says it explicitely but the concept appears when they talk about the differerence between a "work that uses the library" and a "work based on the Library".

But you're rigth in that it's not exactly clear, which was (IIRC) one of the reasons for the new phrasing in the LGPLv3.
Title: Re: Qt offering changes 2020
Post by: avra on March 31, 2020, 04:09:22 pm
Quote
You must allow reverse engineering of your application as necessary to debug and relink the library.

If you're dinamically linking there is no need at all to "debug and relink" in the context of your application; that condition applies only when you link statically

I understand it differently. If my app is dynamically linked to v5 of some lib and it works well, then someone updates that lib to v6 and there are some problems in my app because of that change, then I am obligated to allow reverse engineering in order to debug and link properly. Even if I am wrong that is fuzzy enough to become a show stopper for me.
Title: Re: Qt offering changes 2020
Post by: marcov on March 31, 2020, 04:11:52 pm
Quote
You must allow reverse engineering of your application as necessary to debug and relink the library.

If you're dinamically linking there is no need at all to "debug and relink" in the context of your application; that condition applies only when you link statically

I understand it differently. If my app is dynamically linked to v5 of some lib and it works well, then someone updates that lib to v6 and there are some problems in my app because of that change, then I am obligated to allow reverse engineering in order to debug and link properly. Even if I am wrong that is fuzzy enough to become a show stopper for me.

Random third party builds are not relevant, let alone major version differences. The user must be able to get the sourcecode through you, and rebuild with minimal changes. If you don't have to edit the binary for that to use the rebuild, it is not required I think.

I think this is mainly meant for older targets that link by offset in a library rather than by symbol resolving.
Title: Re: Qt offering changes 2020
Post by: avra on March 31, 2020, 06:04:04 pm
Random third party builds are not relevant, let alone major version differences.
I think that LGPL 2.1 protects used library in a way that whatever software is linked to that library, anyone experiencing problems should be allowed to debug and try to improve linking. That right is protected whether by allowing improving of linked application interface or by improving library it self. Such need usually happens when there is a new version of the library, or when some bug is found. Whatever the correct interpretation is, LGPL 2.1 is not good for use case when I want to keep my sources closed. If RTL and LCL didn't have linking exception license, I would personally have stayed away from Lazarus.
Title: Re: Qt offering changes 2020
Post by: guest65405 on April 01, 2020, 05:38:44 am
My interpretation relying solely on the page we linked:

First, if you link static you already have to release your source, so no reverse engineering needed.

So for reverse engineering to be useful, the code must be closed source, that also imply dynamic link.

Anyway, I consider this license to be not safe. I will not use it.
Title: Re: Qt offering changes 2020
Post by: ASBzone on April 01, 2020, 05:41:40 am
Random third party builds are not relevant, let alone major version differences.
I think that LGPL 2.1 protects used library in a way that whatever software is linked to that library, anyone experiencing problems should be allowed to debug and try to improve linking. That right is protected whether by allowing improving of linked application interface or by improving library it self. Such need usually happens when there is a new version of the library, or when some bug is found. Whatever the correct interpretation is, LGPL 2.1 is not good for use case when I want to keep my sources closed. If RTL and LCL didn't have linking exception license, I would personally have stayed away from Lazarus.


The reverse engineering requirement for LGPL 2.1 only applies if you statically link the LGPL'd library into your app.  If you only dynamically link it, there are no implications for your app.    (And, if you make the user get the library themselves, you won't even have to provide the library source.)


I'm not a lawyer, nor have I played one on TV, but I work closely with lawyers for the purpose of Cybersecurity, Compliance and Software Licensing issues.   
Plus, I have slept at Holiday Inn Express numerous times...
Title: Re: Qt offering changes 2020
Post by: avra on April 01, 2020, 09:37:52 am
The reverse engineering requirement for LGPL 2.1 only applies if you statically link the LGPL'd library into your app.  If you only dynamically link it, there are no implications for your app.
Otherwise commercial closed software software would not use Linux and dynamically link to it's libs which are mostly GPL and some LGPL.  :)
Title: Re: Qt offering changes 2020
Post by: af0815 on April 01, 2020, 03:56:30 pm
Otherwise commercial closed software software would not use Linux and dynamically link to it's libs which are mostly GPL and some LGPL.  :)
Closed software and LGPL is not a Problem, if the LGPL'ed Software is bundled with the distribution itself and the pascalinterfeces are LGPL'ed with exceptions too . Like widgetset, DB drivers, ....
Title: Re: Qt offering changes 2020
Post by: eljo on April 01, 2020, 05:17:11 pm
as far as I know the exception is there to allow you to not share your code if you staticaly link not to disallow others from reverse engineering your code so lgpl with or with out exception once staticaly linked its a reverse engineering play ground and you can't do anything about it.
Title: Re: Qt offering changes 2020
Post by: af0815 on April 01, 2020, 05:28:28 pm
as far as I know the exception is there to allow you to not share your code if you staticaly link not to disallow others from reverse engineering your code so lgpl with or with out exception once staticaly linked its a reverse engineering play ground and you can't do anything about it.
reverse engineeering is always a playgroud and you can do really nothing against, if your software is interesting enough  :)  :o
Title: Re: Qt offering changes 2020
Post by: eljo on April 01, 2020, 05:32:17 pm
as far as I know the exception is there to allow you to not share your code if you staticaly link not to disallow others from reverse engineering your code so lgpl with or with out exception once staticaly linked its a reverse engineering play ground and you can't do anything about it.
reverse engineeering is always a playgroud and you can do really nothing against, if your software is interesting enough  :)  :o
Why should I have to promise not to sue them though?
Title: Re: Qt offering changes 2020
Post by: marcov on April 01, 2020, 05:46:45 pm
Random third party builds are not relevant, let alone major version differences.
I think that LGPL 2.1 protects used library in a way that whatever software is linked to that library, anyone experiencing problems should be allowed to debug and try to improve linking.

Yeah, but that debugging is for the LGPLed work, iow the library, for which you must provide the source for  on demand. Nobody has said it is debugging from within your library.

Note that you can charge a $50 or more nominal fee for the providing of the source, so usually a URL or a pointer is enough. (and if not, they pay for the privilege)

Quote
That right is protected whether by allowing improving of linked application interface or by improving library it self.

Only for bugfixing. You don't have to allow the interface of the library to change. Getting that right is on the user.

Quote
Such need usually happens when there is a new version of the library, or when some bug is found. Whatever the correct interpretation is, LGPL 2.1 is not good for use case when I want to keep my sources closed. If RTL and LCL didn't have linking exception license, I would personally have stayed away from Lazarus.

This is overly panicky.  Just make sure you keep the source of LGPL libs you distribute.  (if you link to OS provide LGPL libs, referencing them should be enough). If not you can charge $50 to dl the sources of a linux distro.

The only problem I see is the many shaky 3rd party builds for OSS libs on Windows. These are less easy to track the exact source of, and many people distribute the DLLs without doing so. But that goes for postgresql as much as any third party sourcecode.

For Pascal code there is the problem that currently if you put something in a DLL, you must communicate with that code in a much more lowlevel manner.  Maybe packages solves that. (if somebody pesters you enough, you simply provide a lazarus snapshots that can generate packages for your app) But it is a burden, no doubt that.

That's why FPC chose to use modified library, to avoid this endless grey area of opinions, and "it is possible, just not in a way a sane person would want to" like options.

But that matter less for libraries like postgres, qt etc.

Moreover, in QT's case, there is another layer inbetween. In a weird (and frankly quite unimaginable case) you could just surrender the QTPAS code, and let them fix it in there.
Title: Re: Qt offering changes 2020
Post by: guest65405 on April 01, 2020, 06:41:53 pm
They said we could develop commercial applications, but said nothing about reverse engineering:

https://www.copperspice.com/docs/cs_overview/main-cs-license.html

As they forked the LGPLv2.1 version of Qt4 and they are not the owner of Qt, they can't relicense it or at least dual license like the Qt company currently does. It's out of their ability.

If we really feared that reverse engineering term so much, why we have the Qt4 interface after all? Lazarus has the Qt4 interface long long before Qt5. People still build up on it. Some even sold their software. Why do we panic? LGPLv2.1 is nothing new.

Some could said they would bought the commercial version of Qt so they are safe using the Qt4 interface. Good luck for them, but I could make sure most of us use the free community LGPLv2.1 version.

p/s: it's clear now we could use CopperSpice the same way we use Qt4. It will be very good if someone could create a CopperSpice interface for Lazarus by adapting the current Qt4Pas (or Qt5Pas) but this one will not be me. My computer is too slow and I'm so lacked in knowledge of C++ to be able to play with it.

p/s: As CopperSpice removed MOC, someone could try to use Swig to generate the binding as well. But I'm not sure about this. They don't have MOC but they use template heavily and depends on the latest version of C++, C++17.
Title: Re: Qt offering changes 2020
Post by: avra on April 06, 2020, 02:02:32 pm
Quote
Such need usually happens when there is a new version of the library, or when some bug is found. Whatever the correct interpretation is, LGPL 2.1 is not good for use case when I want to keep my sources closed. If RTL and LCL didn't have linking exception license, I would personally have stayed away from Lazarus.
This is overly panicky.
I do not agree. Read this quote from https://wiki.lazarus.freepascal.org/FPC_modified_LGPL:
Quote
The difference with the regular LGPL is that it does not require programs/libraries using Modified LGPL licensed software (such as the RTL, FCL, LCL, ...) to be relinkable by the end user against newer versions of these Modified LGPL components.
This is exactly why I stay away from pure LGPL libraries, and I am thankful that someone recognized it too and allowed more liberal usage of LCL, FCL, RTL - and in general any other FPC modified LGPL lib. Otherwise whenever new lib version emerges I would be obligated to fix linking problem in one way or the other. And I do not care if at the end correct interpretation would be that it applies to just one specific type of linking. If I need an international licensing lawyer ($$$$) to understand properly such an important detail then it is shady enough for me to stay away. Just trying to be practical, not necessarily correct.
Title: Re: Qt offering changes 2020
Post by: dbannon on April 22, 2020, 02:23:58 am
KDE themselves don't seem particularly worried. Or at least appear to have a plan.

https://ev.kde.org/2020/04/06/changes-in-qt-and-the-kde-free-qt-foundation/

And the worst case changes discussed here will affect KDE far more than us .....

I summary, save you some time -

....
The successive versions of the agreement drawn between the owners of the commercial version of Qt and the Foundation have ensured that Qt remained free for all developers and added a provision that, if triggered, would entitle KDE to release Qt under a BSD license.
.....


(I wonder if this thread would have been better posted in the  Qt sub-forum, took a long time for me to find it. )
Davo
Title: Re: Qt offering changes 2020
Post by: mercurhyo on April 22, 2020, 02:36:58 am
philosophy moment around Qt

Yet another company 'sinking'/thinking that $500 from 100 users will be more efficient thant $1 from 1,000,000 users

end of my support!
 :D :D :D :D :D :D :D :D :D :D
I caught my brain years ago
Title: Re: Qt offering changes 2020
Post by: dbannon on April 22, 2020, 05:59:40 am
The trouble is it sometimes costs $2 to collect those fees.  So, if the fee is $500 you still clear $498, if you collect $1 .....

Honestly, no can object to a company trying to make money from its products, what worries me is when they say, initially its free, wait for a user base to build up then say, "free ?  well, not really ...."

Anyone remember Unisys and the GIF format ?   Anyone use GIF now ?

Davo
 
TinyPortal © 2005-2018