corinthia-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Danese Cooper <>
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 Fri, 15 Jan 2016 21:30:49 GMT
One nit with this discussion.

It's not true that GPL says it's not okay to make money. If it were then RedHat couldn't exist.

It is true that the ASF and the FSF have historically been religiously incompatible on the
subject of licensing combinatorics. As I usually explain to my clients, the worst case scenario
for the FSF is that code become unfree (in the non-proprietary sense); the worst case scenario
for the ASF is that code become unused (in the code reuse sense). Both points have their validity.


> On Jan 15, 2016, at 9:32 AM, Alex Harui <> wrote:
> Probably too late, but some comments in-line.
>> On 1/15/16, 6:55 AM, "Peter Kelly" <> 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.
>> 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.
>> The ticking time bomb, as we discovered several months in, was the
>> disconcertingly-named “Category X list”, described at
>> (under "Which licenses may not
>> be included within apache products?”). This lists several licenses,
>> including the LGPL, regarding which it states:
>> "The LGPL is ineligible primarily due to the restrictions it places on
>> larger works, violating the third license criterion. Therefore,
>> LGPL-licensed works must not be included in Apache products.”
>> When I (and some others) on the project read this, we did not see it as a
>> problem. We were not distributing any LGPL-licensed code, but merely
>> writing an application conforming to an API whose only currently-existing
>> implementation is licensed under the LGPL (there are commercially-licened
>> versions of the library as well, for those who want them).
>> It all hinges on the phrase “included within” - I do not consider a
>> third-party library, that is not distributed as part of an ASF release,
>> to fit within that definition, according to my understanding of the
>> English language (and I’m a native speaker). However, the relevant ASF
>> policy makers have a different interpretation. It’s extremely subtle -
>> basically the policy equivalent of an OpenSSL bug.
> I don't know how Qt is packaged, but AIUI, the CategoryX restriction does
> not apply to build tools and runtimes.  But whether you package it or
> download it, if using it places restrictions on your customers than that's
> a problem.
>> For what we were trying to achieve, and the ways in which we were going
>> about it, it turned out that ASF was not an appropriate choice of venue.
>> There were several other things I felt were unreasonable - the inability
>> to accept pull requests from anyone without first asking them to sign a
>> CLA, the prohibition against binary distributions of support libraries
>> for convenience of building, and the constant deference to the
>> pseudo-religious “Apache Way” (which I still haven’t seen a coherent
>> explanation of, despite the very long “What is the Apache Way?” thread
>> this list just a few months ago).
> 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.
> -Alex
> [1] 
> -updated-strengthen-community-extend-adoption/

View raw message