Announcement

Collapse
No announcement yet.

Qt 6.1 Beta 2 Released, Qt-Project.org Called For Revival

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • #21
    Originally posted by ddriver View Post
    IIRC the commercial version will have features and fixes that will be withheld from the foss version. Or at the very least, the community binaries will not contain them.
    Going to need a citation on that. From everything that I have read, from the official announcements to the discussions on the mailing lists, the changes are strictly the following:

    - New LTS patch releases (which only include fixes, not features), binary and source, will become available to commercial customers only once the next minor version is released*. Qt have stated they will follow an "upstream first" philosophy, so those fixes should already be in the dev branches and new/upcoming non-LTS releases.

    - Binary downloads will require a Qt Account (free). Source tarballs are freely available without an account.

    - Offline installers of the binary packages will be under customer only availability.

    Cheers,
    Mike

    * And as far as I can tell, they will need to release those patches within 12 months after distributing them per the agreement with the KDE Free Qt Foundation.
    Last edited by mroche; 21 March 2021, 06:19 PM.

    Comment


    • #22
      Originally posted by dremon_nl View Post
      Theoretically yes, practically nobody provides a do-it-yourself commercial application to the end user along with object files, linking and packaging scripts and a detailed documentation how to relink it. For all practical purposes static linking is prohibited by LGPL.
      It has to be made available to the end user, so a website link is enough. Documentation doesn't need to be any more "detailed" than dynamic linking. The key feature of LGPL is that the end user is able to upgrade the LGPL code, and both static and dynamic linking provide that capability, so both comply with LGPL terms. (There are circumstances in which someone may want to do this, for instance if they wanted to provide a closed source GUI installer using Qt that is in a single dowloadable .exe.)

      Comment


      • #23
        Originally posted by ddriver View Post

        LGPL is not prohibitive of static linking. What it mandates is that the end user should be able to relink, and that's perfectly achievable by providing object files, you don't need to use dynamic linking, you don't need to open your code.
        Very good point! You're absolutely right. (and I would like it if you could make *that* point clear to the Qt Company)

        The Qt Company makes it very difficult to clarify the license situation. While their latest instructions just say "Provide a re-linking mechanism for Qt libraries", they are sort-of misleading in their standard "Licensing" article under the title: "Developing with LGPL". In the second point they say "In case of static linking of the library, the application itself may no longer be “work that uses the library” and thus become subject to LGPL." This was always, and still is, a grey area to me.

        So, the simplest way to develop a Qt application under the LGPL on Windows is to use dynamic linking. The situation on Linux may be different, but I have no substantial expertise there.

        Comment


        • #24
          Originally posted by ddriver View Post
          IIRC the commercial version will have features and fixes that will be withheld from the foss version. Or at the very least, the community binaries will not contain them.
          That's not quite the case in my experience. This is where the Qt marketing misleads. The emphasis is on "features". There are quite a number of addon modules that are not LGPL. To use these modules you need the commercial version. You get the "latest fixes" only via source. And you download from the same repository. So, if you're going with the binary packages (as most Windows dev's do) you'll not get any.

          Comment


          • #25
            Originally posted by DanL View Post

            You don't seem to understand this open source thing too well..
            Well, (s)he has a point. Yes, the open source Qt release certainly conforms to the open source definition (OSD).

            However, if we think of open source communities, they tend to work better when everybody has equal rights and responsibilities. Linus Torvalds gets to use the Linux kernel under the exact same provisions as you or I, no exceptions. But that is not Qt. In the Qt world, everybody is equal, except that some are more equal than others (to paraphrase Orwell). By assigning copyrights to the Qt company, they get the exclusive option of making money by selling the software under other terms than the rules that the rest of the contributors are playing by.

            Rightly or not, it's hard to escape the feeling that if you're contributing to Qt, you're working for free for the benefit of The Qt Company shareholders. Sure, it's not slavery in that nobody owns you and is forcing you to do that work under the threat of corporal punishment.

            Comment


            • #26
              > > this open source thing

              > working for free

              If I program using Qt I also get benefits that others get, but I don't pay developers and they do... It's also like if someone had worked for me for free.

              Comment


              • #27
                Originally posted by Nth_man View Post
                > > this open source thing

                > working for free

                If I program using Qt I also get benefits that others get, but I don't pay developers and they do... It's also like if someone had worked for me for free.
                Not really, because they didn't do it for you, they did it for their employer, and they got paid for it. It just so happens it costs next to nothing for that already paid for and done work to be digitally cloned and distributed to an arbitrary amount of people. The one major upside of digital data.

                Also, using foss software doesn't necessarily mean you are taking without giving, I for example haven't really contributed code to Qt directly but I have discovered, isolated and reported scores of issues, many of which critical. And I dare say discovering and reporting existing bugs is no less beneficial than writing code to introduce new bugs.

                Alas, digia is no good at listening to or appreciating its community. They made such a mess out of Qt through their misguided management, that now for Qt 6 they are writing off a tremendous amount of work, breaking backward compatibility, because they have finally come to a point where they cannot continue pushing the wrong way, so now they are resorting to excessive rewrites, to do what a sizable chunk of its community told it they should do almost a full decade ago.

                What a waste... so many developer efforts...

                Comment


                • #28
                  > > If I program using Qt I also get benefits that others get, but I don't pay developers and they do... It's also like if someone had worked for me for free.

                  > Not really, because they didn't do it for you, they did it for their employer, and they got paid for it.

                  Anyone that reads it can see that I'm talking about who pays developers.

                  Comment


                  • #29
                    A post from a KDE developer I saw said that since new Qt5 patches will no longer be available under LGPLv3, KDE is going to have to move to Qt6.

                    Understand this clearly: Qt now gets to dictate KDE's development schedule by withholding FOSS updates to branches that are in use.

                    So I will say this again: Now is a very good time to clone the FOSS repo and continue development of Qt5 under the LGPLv3 license. Except this time, contributors get to keep the rights to their contributions.

                    Comment


                    • #30
                      Originally posted by wswartzendruber View Post
                      A post from a KDE developer I saw said that [...]
                      As a Qt developer wrote:

                      Let me be very clear so there's no mistake: all security issues will be dealt
                      with in all branches, to the extent that we are able to reproduce them and
                      confirm them.


                      As Charlie68 wrote:

                      You may not know, but KDE software has always built on the latest stable Qt version, not the LTS one, which is mostly only used by some LTS distributions.

                      LTS is not synonymous with stability, but with "long-term support". KDE always recommends using the latest version of Qt.


                      Comment

                      Working...
                      X