Announcement

Collapse
No announcement yet.

KDE Developers Discuss Merging Libraries With Qt

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

  • #16
    Originally posted by deanjo View Post
    It's not stupid at all to plan that far ahead. Most larger projects give similar time lines when a radical change is desired.
    Yes, I guess I put it in a wrong way. Of course one should plan before taking action, but waiting for too long can also be harmful in fast moving world. Truth is that I have no idea how long this kind of projects take but I doubt that neither planning nor coding take that long.

    Comment


    • #17
      Originally posted by TemplarGR View Post
      It is funny. When in another old thread i said that KDE is just a tech demo from Qt developers designed to showcase Qt's abilities, many people said that i do not know what i am talking about... That this is FUD. Well... explain this smart guys... For this discussion to even happen, it proves my point...

      Sure, KDE is a community project. Sure, some people from all over the world contribute to it. But it's core team that drives it, is from Trolltech. Trolltech points, they follow. It is that simple.
      You got called on your bullshit back then and you'll get called again.

      Trolltech funds exactly ONE KDE developer. That's it.

      Comment


      • #18
        Originally posted by Teho View Post
        It would be nice but only after Qt's licencing issues etc. are fixed.
        Which issues would those be?

        Comment


        • #19
          Originally posted by pingufunkybeat View Post
          Which issues would those be?
          Well that's the thing, I don't really know but I have heard that there's some promblems somewhere regarding licensing, copyright, "merge control" or something like that. However I don't have the knowledge myself, so I take as "uncertain truth". If there really isn't anything that's truly splendid.

          But how should I understand something like this: "Albert also does not agree with the Qt licensing requirements."?

          Comment


          • #20
            Qt can also be sold for proprietary software. KDE has to hand over copyright to Nokia so then Nokia can give it back as GPL'd code.

            Comment


            • #21
              Originally posted by Teho View Post
              Yes, I guess I put it in a wrong way. Of course one should plan before taking action, but waiting for too long can also be harmful in fast moving world. Truth is that I have no idea how long this kind of projects take but I doubt that neither planning nor coding take that long.
              On big projects it does take a long time if it is to be done properly. 3rd party developers hate having radical changes pop up over night especially when 1/2 of the code is still "baking in the oven". A lot of development requires planning and communication with the other parties involved and effected by the proposed changes and this takes quite sometime when dealing with entities on which you rely on and vice versa. Technology may appear to the end user as quickly changing but almost every technology spends years in planning and preparation.

              Comment


              • #22
                Originally posted by pingufunkybeat View Post
                Which issues would those be?
                The biggest would be that you need to basically give Nokia all rights to the code you want them to integrate into Qt. Apparently this involves signing an agreement of some sort, I'm not quite sure about the details there. Either way many of the original contributors aren't even around any more, so getting their approval for a relicensing is close to impossible.

                Another problem is that only employees of Nokia have commit rights thus far and they're already overwhelmed with the amount of merge requests they're getting at the moment. Something would need to change drastically to allow proper development by KDE developers inside of Nokia's repository.

                A more general problem would be that Qt and KDE release separately, so it could become problematic to decide which features that are in development can be used and which won't make it into a Qt release in time.

                Last but not least, many of the customizations KDE does to various Qt classes wouldn't really be welcomed by Qt proper because they're too niche or whatever.

                All said, I wouldn't expect a real merger of Qt and KDELibs. The discussion trends more to a multi-pronged approach where
                - as much as possible is merged into Qt
                - other stuff would go into KDE-maintained Qt modules
                - the rest goes either into a minimal KDELibs or gets tossed out completely

                I wouldn't bet on _anything_ happening, to be honest.

                Comment


                • #23
                  That's quite a good summary, thanks. I tend to agree with it for the most part.

                  Comment


                  • #24
                    Originally posted by V!NCENT View Post
                    Qt can also be sold for proprietary software. KDE has to hand over copyright to Nokia so then Nokia can give it back as GPL'd code.
                    kdelibs are mostly LGPL, which presents no problem for proprietary software.

                    Comment


                    • #25
                      I don't know if I really like this. Merging stuff into Qt (in a modular fashion, of course) would be a really nice solution technically, but I don't feel too comfortable about giving Nokia too much control. They have enough control already, for my taste.

                      Comment


                      • #26
                        There's so much talk about open governance and such, so would it be possible (or likely) that Nokia changed their current policy? Or is it something that they will stick to for sure.

                        Comment


                        • #27
                          Originally posted by pingufunkybeat View Post
                          kdelibs are mostly LGPL, which presents no problem for proprietary software.
                          Qt offers a commercial license to allow companies to avoid the one big restriction that is imposed even by the LGPL:
                          If you want to modify the library that is LGPL (Qt in this case) and then distribute that modified version of the library, you need to open up these changes. Basically, the library itself is under some sort of quasi-GPL even though you can write closed source applications using it.

                          So yeah, the LGPL is a problem here.

                          Comment


                          • #28
                            I don't know if Nokia should care that much.

                            Unlike Trolltech, Qt is not their core business. That's also why Qt was LGPL'ed, something Trolltech could not do on their own.

                            Comment


                            • #29
                              Originally posted by onety-three View Post
                              Qt offers a commercial license to allow companies to avoid the one big restriction that is imposed even by the LGPL:
                              If you want to modify the library that is LGPL (Qt in this case) and then distribute that modified version of the library, you need to open up these changes. Basically, the library itself is under some sort of quasi-GPL even though you can write closed source applications using it.

                              So yeah, the LGPL is a problem here.
                              Is this really a major problem in any practical scenario?

                              Which company needs to both modify the Qt source code AND distribute those changes while keeping them secret?

                              For most (proprietary) software developers, Qt is a tool that takes care of things they don't want to deal with. Even if they need to patch it for some added functionality, the patches should be small and unimportant enough to release them as LGPL.

                              If anyone suggests closing KDElibs and making them proprietary, there will be a war of epic proporsions. I can't imagine ANY KDE contributor going along with that.

                              Comment


                              • #30
                                Not too fast

                                I think the process does not necessarily need to be so sudden, I think we can start with small things and progressively slim down kdelibs until they disappear (or leave them very slim).
                                Like this guy said (http://lists.kde.org/?l=kde-core-dev...3163506010&w=2) kdelibs can be divided in 4 parts:

                                1. Small improvements to the Qt Libraries
                                This are things that were done when qt wasn't truly open (It has started trying to be AFAIK), and are small changes, like adding a little option to that widget making that a bit nicer, And most of these changes could be merged into qt (if kde contributors accept qt license and nokia accept them)

                                2. Additional Functionality
                                This kind of things are also like "1", if nokia wants them and contributors don't have any problem with qt license, then they could be merged.

                                3. KDE Classes that do not require the complete KDE Environment
                                This things are kde specific and should stay in kdelibs(things like kde styling classes)

                                4. KDE Classes that require the complete KDE Environment
                                Same thing as "3"

                                This way kde will progressively get closer to qt. So making a kde app and port it to qt and vice-versa will be easy
                                Also to keep BC compatibility: Kdelib classes that go upstream ("1" and "2" I guess) should become wrappers of qt classes, but should be flagged as deprecated, and in kde 5 they should be dropped.
                                Also if nokia doesn't want any of kdelibs we can't do nothing about it, but they may want part of it, and getting that bit would already be an advantage.

                                Comment

                                Working...
                                X