Qt in the land of Gnome-based desktops: The issue of copyright in Free software

Recently Mark Shuttleworth wrote about how Qt will become part of the Ubuntu 11.10 desktop, and that Qt-based apps will eventually be considered as possible default Ubuntu apps. Obviously, this would be a big change from using GTK-only applications (that is, aside from Firefox and Open/Libreoffice applications), but Mark encourages GNOME developers to consider using Qt, too. He writes, "Perhaps GNOME itself will embrace Qt, perhaps not, but if it does then our willingness to blaze this trail would be a contribution in leadership."

I agree on this, and think that enabling usage of Qt in GNOME projects would be a contribution in leadership. It would be great if developers had the option of using tools like Qt Creator and Qt Quick when building applications for GNOME-based desktops (or other devices!).

The question is: How do you make that happen? All technical matters aside, how do you encourage GNOME developers to consider using Qt for their applications?

To me, one major consideration in further developing the Qt-to-GNOME bridge, and encouraging developers to use Qt in GNOME-based desktops, involves copyright. I think the GNOME project, and its large group of developers, would be more likely to embrace Qt if Canonical did not put the dconf binding work (or other such Qt/GNOME integration work) under strict Canonical ownership via their contributor agreement.

The issue is that the contributor agreement gives all copyrights of the work (even contributions made by non-Canonical employees) to Canonical, and permits Canonical to relicense the work (even make it proprietary) at their discretion. To me, this would present a considerable risk for the GNOME developers and for the GNOME project.

The folks at Canonical have not yet indicated whether or not the contributor agreement applies, or will apply, to the early QT/dconf binding work. My thinking is that, if Canonical is disinclined to having the larger GNOME project use Qt, Canonical will request full copyright ownership of any Qt/dconf work. Thus, Canonical would "own the bridge" between the land of Qt and the land of GNOME, and anyone who wants to use that bridge would have to do so knowing that it could eventually be made proprietary.

Moreover, I think it would be a bit ironic if Canonical put the Qt/dconf work under their contributor agreement. As I understand it, Canonical’s main justification for requiring copyright assignment is that they "wrote the code," for that project, and would like to maintain ownership of it. While folks at Canonical may have done the initial Qt/dconf bindings work, a primary reason that Canonical is even able to safely use Qt in their business is because Nokia opened up Qt, and removed the copyright assignment requirement from Qt contributions. Surely the Qt codebase, along with all of its associated tools, is much larger than any binding work (no matter how significant), so Canonical’s reasoning wouldn’t seem to be as applicable here.

However, if Mark and the rest of the folks at Canonical actually wants GNOME developers to embrace Qt on equal footing with GTK, they will either donate out the Qt/GNOME integration work to the larger GNOME community, or they will push the integration work upstream to Qt.

I’m hopeful that the folks at Canonical will choose either of the latter two options and make their initial Qt/Gnome integration work available under the same copyright-free terms that Qt has been made available to them. I agree with Mark when he writes, "it’s the values which are important, and the toolkit is only a means to that end." While it may ruffle some feathers initially, having Qt as a viable option for development in GNOME-based desktops can only improve the free software ecosystem by giving developers more choices in the tools that they are able to use.

As a closing note, some of what I’ve written here is speculation and opinion, but if I’ve misunderstood anything, or if anyone can shed further light on this topic, please share a note in the comments.