> On 16 Jan 2016, at 12:32 AM, Alex Harui <aha...@adobe.com> wrote: > > Probably too late, but some comments in-line. > > On 1/15/16, 6:55 AM, "Peter Kelly" <pmke...@apache.org> wrote: >> >> However, one important factor which really killed things for us was the >> inability to use Qt. >> >> The desktop app was the main priority, however. >> >> To do a cross-platform desktop app, and to do it properly, it’s necessary >> to use a suitable UI toolkit which provides all the necessary >> functionality. As it turns out, the only viable candidates we were able >> to identify (Qt and GTK, with wxWidgets and fltk as less desirable >> fallback options) are all licensed under the LGPL. For most open source >> projects, this would be no problem - LGPL and ASLv2 are compatible with >> each other, in the sense that you can distribute software combining the >> code from the two licenses without problems; doing so just means that >> users of the software are bounds by the terms of both licenses. > > It appears that Qt is no longer under LGPL and now just GPL? [1] That > could limit the number of commercial users which is one reason why the ASF > has the CategoryX restriction.
It’s now available LGPLv3 - they’ve just LGPLv2.1 as an option, for new releases. > >> >> We very quickly settled on Qt as the toolkit of choice, on technical >> grounds. It seemed to us to be the most mature, feature-rich, and best >> designed library of the available choices, and some of us had already >> used it on other projects in the past. However, even if we had chosen one >> of the other libraries, the outcome would have been the same. > > FWIW, Apache Flex and Apache Cordova can create cross-platform desktop > apps. I think these are pretty mature projects. I recently discovered Electron (http://electron.atom.io <http://electron.atom.io/>) which I’ve used as part of some other work I’ve done recently and actually quite like. It also services as the framework for GitHub’s Atom text editor. If I’d known about it a few months ago when the podling was still active, I would have suggested using this for the editor. Having spent some time using Atom, I think that Electron would be have been a good solution for Corinthia’s editor. It’s available under the MIT license, which according to http://www.apache.org/legal/resolved.html <http://www.apache.org/legal/resolved.html> makes it acceptable to use as a project dependency. I would recommend this as an option to new ASF podlings that wish to build a cross-platform desktop app. Another advantage of Electron is that it’s all based on web technologies, so most if not all of your UI code can be used in a browser environment. Unfortunately, the hostility and attitude of specific individuals who objected to our proposed to of Qt lead the decision making off-track, and into arguments. The was essentially was basically "no, you cannot use Qt, and therefore the editor should not be part of the project” (i’m paraphrasing here). This caused the discussion to descend into arguments which severely harmed the community. My suggestion to people involved with ensuring that ASF policies are adhered to - such as the licensing issues I mentioned - is to say “Ok, this particular solution is not permitted within the rules. However, given the requirement in question is a very important part of the project, let’s work together to find a solution that allows us to achieve our goals within the context of ASF”. If this approach had been taken, I think there’s a pretty good chance we would have ended up conducting more research into available options, and ended up going with Electron. That didn’t happen though, and as result the whole podling fell apart and numerous people (myself included) left. In my particular case, the experience was stressful enough that I longer wish to have anything to do with an ASF ever again. > IMO, the ASF way of open source is a pseudo-religion. So is the FSF/GNU > way. The ASF says you must not scare away people who want to make money > by selling software. The FSF says you cannot make money selling software. > When you become an ASF project, then potential customers who want to make > money don't have to dig through your licensing to figure out if they can. > If you don't need that advantage, then yes, the ASF may not be a good fit. > But it sounds like you are choosing to not want for-profit customers. I > hope that's really what your community wants. I should explain a bit more about the nature of the way of the software we planned to to write which depended upon Qt. I’d like to first mention though that I own a company which is already using the non-UI Corinthia codebase in a for-profit manner (UX Write, a word processor for iOS) - in fact this is where the code originally came from. The iOS version has a (closed source) UI using Apple’s native APIs, and does not use Qt. There are three components to the project 1) A C-based file format conversion library, does not depend on any LGPL or other Category X libraries 2) A javascript-based WYSIWYG HTML editing library, which has no dependencies at all; other than the standard APIs provided by browser (and embedded web views, such as the UIWebView class on iOS) 3) A Qt-based desktop editor Parts 1 and 2 already exist, and have been deployed in production (as part of UX Write) for around three years. We had been working on improvements to these parts, and there were no licensing problems (actually there were originally, but we fixed them by replacing a couple of libraries e.g. minizip with our own implementations). Part 3 was brand new. Depending on the use cases, it is perfectly feasible to use only part 1 and/or part 2, without part 3. The latter was intended as a tool provided by end-users. We tried to arrange for this to be an “optional” component, in order to avoid the Category X restrictions, but this proposal was rejected. The question then arose, ok - what should we do? Should we do the Qt editor on GitHub, and keep the file format conversion and editing libraries as part of the ASF podling? To me, this seemed very problematic from the community perspective - we would have two different development venues, two different issue tracking systems, two different wikis, two different release processes (which we would have to figure out if/how to coordinate them). And would ASF accept the use of the Corinthia mailing list for discussions of development of a non-ASF project, particularly when a large portion of such discussions are likely to cover it? What about voting processes, commiter/PPMC membership? It probably could have been made to work with sufficient effort, but it seemed like an unnecessary hassle. For our situations, I feel that ASF’s policies are actively harmful to fostering a healthy community. The “community over code” mantra seems hypocritical when there are other aspects of ASF which, at least in certain cases, get in the way of building a strong community. The solution seemed pretty simple - just move everything to GitHub. All the code remains under ASLv2; anyone can use the components that do not rely on LGPL libraries. And those who wish to make commercial apps based on the editor are able to do so, so long as they are willing to comply with the conditions of the LGPL, or purchase a commercial license for Qt. I hope the above gives some food for thought. -- Dr. Peter M. Kelly kelly...@gmail.com http://www.kellypmk.net/ PGP key: http://www.kellypmk.net/pgp-key <http://www.kellypmk.net/pgp-key> (fingerprint 5435 6718 59F0 DD1F BFA0 5E46 2523 BAA1 44AE 2966)
