The TL;DR: I don't think there is a reasonable way to depend on Qt in AOO. I also don't think that depending on Qt, were it feasible, would satisfy the concern that started this thread concerning the difficulty of maintaining [with] VCL. It might just move the pea to a more-difficult third-party dependency, after requiring a mammoth cut-over to a new GUI framework.
-- replying below to -- From: Louis Suárez-Potts [mailto:lui...@gmail.com] Sent: Tuesday, January 13, 2015 20:59 To: dev@openoffice.apache.org Subject: Re: [DISCUSS] Qt as a replacement for VCL > On 13 Jan 2015, at 23:04, Dennis E. Hamilton <dennis.hamil...@acm.org> wrote: [ ... ] > PS: I thought there was a LGPL case where you could run QT as a DLL > underneath an application, but I don't see how that can work with an ASF > Project for a number of reasons. I also don't see anything about that > featured in the current materials (although Wikipedia points to the Digia QT > LGPL Exception, which is at the bottom of this page: > <http://doc.qt.io/qt-5/lgpl.html#digia-qt-lgpl-exception-version-1-1>. > Some of the gyrations may be related to how QT was spun into and out of > Nokia. According to my email archives, I apparently stopped paying attention > to it at the end of 2011. I may also may be thinking of a different project > with regard to using a pre-built DLL and LIB. > > I think Dennis summarised the point well, However, some more: I had the impression that ASL 2 was compatible with (L)GPL3--but there is some salt here, and it also depends on what you want to infer by “compatible”. Where work would be done on the product using Qt licensed under LGPL or GPL is one issue, and the scope of the work is another. In this case, given the nature of the VCL, the result would probably also be licensed under Qt’s license. <orcmid> The ASLv2 compatibility with GPL is from the GPL side. That is, ASLv2 code can be depended on in GPL projects. The Apache Software Foundation has more constraints on what releases under its auspices may depend upon. There is a nice summary of the applicable principles under discussion at this very moment: <https://wiki.apache.org/incubator/ApacheProjectMaturityModel>. </orcmid> However, that does not mean that add-ons, plug-ins, and other such enhancements couldn’t be made using Qt and hosted off-site. And, yes, we’ve had this very discussion before, many times before, *many* times. (And also hosted extensions off-site, with varying licenses, to the annoyance of the FSF.) <orcmid> I don't doubt that an ALv2-licensed deliverable could depend on LGPL-licensed code so long as the combined rules of LGPL and GPL are satisfied by the way the LGPL-licensed code is handled. However, what the ASF requires of its projects is more stringent than that, going beyond the FSF-accepted compatibility to limit what ASF-approved releases can impose on someone who wants to employ them. As far as I recall, that's why AOO must be buildable without reliance on what are called category-X dependencies. The case of writing tools and some others tend to be finessed via the plug-in extension route, even if bundled in the AOO-provided distributions. Depending on Qt for being able to use AOO at all goes way beyond that tolerance, it seems to me. </orcmid> Originally, the issue preventing use of Qt with OOo was that it forbade free commercial application. Sun didn’t like that as it loved StarOffice. But then Sun sank, OpenOffice got Apache’d and Qt’s license changed (wonder why) and went as Dennis describes it: open and also proprietary. There are some Apache projects that do use Qt, and Qt itself does use ASL2 for some modules. But I think that replacing the longstanding VCL with the popular favourite Qt is not exactly feasible and that there are likely easier alternatives, if we want to change. Is it worth investigating again? I mean not just to reconsider Qt but also VCL. <orcmid> I am curious about Apache projects that use Qt. I'd like to see how they navigate that. Any links? </orcmid> But back to Qt: hope springs eternal, and Qt remains popular, whatever its license and other flaws. I don’t just mean that the Digia exception should give us hope—though why not? Establishing useful compatibility with Apache and for Apache, as well as for users of Qt independent of Apache, would dramatically expand the tool’s usage, I’d guess. Qt’s pages are fairly good, and probably better than my interpretations. Stackoverflow is also good. See: louis [ ... ] --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
