KDE Developers Discuss Merging Libraries With Qt

Quote:

---

Originally Posted by Teho

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.

Quote:

---

Originally Posted by pingufunkybeat

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.

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

Quote:

---

Originally Posted by V!NCENT

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.

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.

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.

Quote:

---

Originally Posted by pingufunkybeat

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.

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.

Quote:

---

Originally Posted by onety-three

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.

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.