incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Kelly <pmke...@apache.org>
Subject Re: Post mortem request for the handling of the Corinthia podling (was Re: FYI, I have subscribed to this list and to your private list)
Date Sat, 16 Jan 2016 16:02:42 GMT

> On 16 Jan 2016, at 12:32 AM, Alex Harui <aharui@adobe.com> wrote:
> 
> Probably too late, but some comments in-line.
> 
> On 1/15/16, 6:55 AM, "Peter Kelly" <pmkelly@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
kellypmk@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)


Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message