Lazarus
Miscellaneous => Other => Topic started 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:
- Long Term Support releases remain commercial only (the post doesn’t mention this, but those releases also need to be released under a free software license within a year to adhere to the agreement, at least to my understanding).
- Access to pre-built binaries will be restricted: put behind an account wall or be only available to commercial license holders
- And there’s a new, cheaper license for small companies that they can use to develop, but not deploy their work to customers.
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.
-
CopperSpice is LGPL 2.1. According to https://tldrlegal.com/license/gnu-lesser-general-public-license-v2.1-(lgpl-2.1) it means that
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.
-
CopperSpice is LGPL 2.1. According to https://tldrlegal.com/license/gnu-lesser-general-public-license-v2.1-(lgpl-2.1) it means that
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.
-
CopperSpice is LGPL 2.1. According to https://tldrlegal.com/license/gnu-lesser-general-public-license-v2.1-(lgpl-2.1) it means that
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:
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.
-
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/
-
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.
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.
-
distros mostly don't use LTS.
Open source distros are becoming more and more just testing grounds for the commerial distros this way.
-
[...] 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)
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... :-[
-
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))
-
[...] 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))
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))
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.
-
The main difference that I was interested was reverse engineering condition. You take your own conclusion.
Read again, avra:
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.
-
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.
-
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.
-
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.
-
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.
-
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...
-
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. :)
-
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, ....
-
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.
-
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
-
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?
-
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)
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.
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.
-
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.
-
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:
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.
-
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
-
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
-
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