You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@corinthia.apache.org by Slow Joe <sl...@gmail.com> on 2016/01/08 23:48:17 UTC
Post mortem request for the handling of the Corinthia podling (was
Re: FYI, I have subscribed to this list and to your private list)
> Forming a podling is difficult as if often starts with a team that
> hasn't necessarily chosen to work together. I bet the situation > would
> have been very different if you guys had been able to meet in
> person,
> but in email that's quite hard.
> -Bertrand
Hi Bertrand
I observed the meltdown of the Corinthia podling from a distance with some
regret.
Since the project is now on the verge of withdrawal from the incubator,
could you and Dennis consider whether it would be valuable to collaborate
on a blame-free post-mortem describing the events which lead to the end of
Corinthia.
(A template for a postmortem document is at
https://lastbytes.wordpress.com/2013/01/15/a-postmortem-template/)
I would suggest that there are lessons for the Apache Project to learn from
this event.
Regards
Joe
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)
Posted by "Dennis E. Hamilton" <or...@apache.org>.
Not to put too much of a fine point on it, but that license provision strikes me as only half of the deal in the case of a submission to an ASF Project. The other key aspect has to do with the explicit assertion by the pull-requester that they have the right to make the contribution, which is to say that the commit contents not already in the code base are the original (in Copyright sense) work of the submitter and not constrained by a condition of employment, etc. Considering that there are varying degrees of understanding and casualness around this in the world of software developers, additional ceremony (whether involving a CLA or not) seems valuable as part of the ASF preservation of IP provenance by having the contributor be mindful of the assurance they are explicitly claiming in making a contribution.
More complicated is staging for a committer to vet the contribution and determine whether and how to accept it, preserve history, etc. (There is a great Google Talk by Linus on how that is organized for the Linux kernel, with a hierarchy of lieutenants.) That is also a factor around pull requests, although I don't think it came up at Corinthia. I believe ASF approaches for this situation, along with the preservation of history back to the contributor, have only recently (post-Corinthia) been worked up; I haven't followed the details, being on an SVN-harbored project.
For Git-harbored ASF projects (as the Corinthia podling was), the ability for committers to simply synchronize a clone is very nice and straightforward under a CTR regime.
- Dennis
PS: I think I created confusion about accepting DIFs (patches) versus pull requests myself, in a dev@ message very early in the setup for Corinthia (December 2014). That aside on a larger topic was never discussed though. I don't think there was ever a non-committer pull-request to deal with. Later, there was a time when one contributor's submissions became substantial enough to request an iCLA, and that contributor was invited to become a committer+PPMC almost concurrently. I think that happened every time and I don't recall complaint on those occasions. There was expressed concern that ceremonial requirements, process, etc., would discourage participation and that is where ideas about community may have collided.
> -----Original Message-----
> From: Rob Vesse [mailto:rvesse@dotnetrdf.org]
> Sent: Monday, January 18, 2016 01:30
> To: general@incubator.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)
>
> Just wanted to reply to one specific point:
>
> On 15/01/2016 14:55, "Peter Kelly" <pm...@apache.org> wrote:
>
> >I felt were unreasonable - the inability to accept pull requests from
> >anyone without first asking them to sign a CLA
>
> Who in particular told you this? I occasionally see communities
> operating
> under this misguided assumption and it frustrates me and I try and
> correct
> it whenever I see this
>
> The Apache License contains Clause 5 (Submission of Contributions) which
> says the following:
>
> "Unless You explicitly state otherwise, any Contribution intentionally
> submitted for inclusion in the Work by You to the Licensor shall be
> under
> the terms and conditions of this License, without any additional terms
> or
> conditions. Notwithstanding the above, nothing herein shall supersede or
> modify the terms of any separate license agreement you may have executed
> with Licensor regarding such Contributions."
>
>
> So basically anything anyone that intentionally submits something to
> your
> project for inclusion (and it's pretty clear that a pull request is an
> intentional submission) then it is fair game for inclusion in an Apache
> Licensed project without the need for any separate agreement.
>
> Now for large contributions (where large is arbitrarily defined by the
> accepting community) there may be a desire to always get a CLA but it is
> a
> fallacy to say that a ICLA is always required.
>
> As a corollary if someone is making large contributions they should be a
> candidate for committer and/or PMC status and if they were to be granted
> committer status then the ASF requires they have a ICLA on file
>
> Rob
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
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)
Posted by Rob Vesse <rv...@dotnetrdf.org>.
Just wanted to reply to one specific point:
On 15/01/2016 14:55, "Peter Kelly" <pm...@apache.org> wrote:
>I felt were unreasonable - the inability to accept pull requests from
>anyone without first asking them to sign a CLA
Who in particular told you this? I occasionally see communities operating
under this misguided assumption and it frustrates me and I try and correct
it whenever I see this
The Apache License contains Clause 5 (Submission of Contributions) which
says the following:
"Unless You explicitly state otherwise, any Contribution intentionally
submitted for inclusion in the Work by You to the Licensor shall be under
the terms and conditions of this License, without any additional terms or
conditions. Notwithstanding the above, nothing herein shall supersede or
modify the terms of any separate license agreement you may have executed
with Licensor regarding such Contributions."
So basically anything anyone that intentionally submits something to your
project for inclusion (and it's pretty clear that a pull request is an
intentional submission) then it is fair game for inclusion in an Apache
Licensed project without the need for any separate agreement.
Now for large contributions (where large is arbitrarily defined by the
accepting community) there may be a desire to always get a CLA but it is a
fallacy to say that a ICLA is always required.
As a corollary if someone is making large contributions they should be a
candidate for committer and/or PMC status and if they were to be granted
committer status then the ASF requires they have a ICLA on file
Rob
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
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)
Posted by Roman Shaposhnik <ro...@shaposhnik.org>.
On Fri, Jan 15, 2016 at 9:32 AM, Alex Harui <ah...@adobe.com> wrote:
>>The ticking time bomb, as we discovered several months in, was the
>>disconcertingly-named “Category X list”, described at
>>http://www.apache.org/legal/resolved.html (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.
Last time we had this very Qt related discussion it was (I think!) Greg
who pointed out that you should probably use a viability argument for
something like Qt. Is your project still viable if something like Qt is
no longer available to it? (note it may be reduced functionality but
still viable)
If the answer is yes -- getting Qt from the runtime binding should be ok.
If the answer is no -- this wouldn't really be a self-contained ASF project,
would it?
Thanks,
Roman.
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)
Posted by Roman Shaposhnik <ro...@shaposhnik.org>.
On Fri, Jan 15, 2016 at 1:39 PM, Ted Dunning <te...@gmail.com> wrote:
> On Fri, Jan 15, 2016 at 1:30 PM, Danese Cooper <da...@gmail.com> wrote:
>
>> 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.
>>
>
> Actually FSF explicitly says that ASL is compatible with GPL. The reverse
> is, of course, not true if you want to preserve the ASL semantics and both
> ASF and FSF agree on that.
A fun little fact that not a lot of zealots on both sides realize is
the above plus
the revers fact that FSF actually *recommends* ALv2 under certain conditions:
http://www.gnu.org/licenses/license-recommendations.en.html
(see the Small Programs ;-) and Libraries paragraph).
Thanks,
Roman.
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)
Posted by Roman Shaposhnik <ro...@shaposhnik.org>.
On Fri, Jan 15, 2016 at 1:39 PM, Ted Dunning <te...@gmail.com> wrote:
> On Fri, Jan 15, 2016 at 1:30 PM, Danese Cooper <da...@gmail.com> wrote:
>
>> 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.
>>
>
> Actually FSF explicitly says that ASL is compatible with GPL. The reverse
> is, of course, not true if you want to preserve the ASL semantics and both
> ASF and FSF agree on that.
A fun little fact that not a lot of zealots on both sides realize is
the above plus
the revers fact that FSF actually *recommends* ALv2 under certain conditions:
http://www.gnu.org/licenses/license-recommendations.en.html
(see the Small Programs ;-) and Libraries paragraph).
Thanks,
Roman.
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
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)
Posted by Ted Dunning <te...@gmail.com>.
On Fri, Jan 15, 2016 at 1:30 PM, Danese Cooper <da...@gmail.com> wrote:
> 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.
>
Actually FSF explicitly says that ASL is compatible with GPL. The reverse
is, of course, not true if you want to preserve the ASL semantics and both
ASF and FSF agree on that.
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)
Posted by Ted Dunning <te...@gmail.com>.
On Fri, Jan 15, 2016 at 1:30 PM, Danese Cooper <da...@gmail.com> wrote:
> 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.
>
Actually FSF explicitly says that ASL is compatible with GPL. The reverse
is, of course, not true if you want to preserve the ASL semantics and both
ASF and FSF agree on that.
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)
Posted by Danese Cooper <da...@gmail.com>.
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.
Danese
> On Jan 15, 2016, at 9:32 AM, Alex Harui <ah...@adobe.com> wrote:
>
> Probably too late, but some comments in-line.
>
>> On 1/15/16, 6:55 AM, "Peter Kelly" <pm...@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.
>
>>
>> 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
>> http://www.apache.org/legal/resolved.html (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 on
>> 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]
> http://www.qt.io/qt-news/qt-open-source-licensing-changed-product-structure
> -updated-strengthen-community-extend-adoption/
>
> B‹KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKCB•È [œÝXœØÜšX™KK[XZ[ˆÙ[™\˜[ ][œÝXœØÜšX™P[˜ÝX˜]Ü‹˜\XÚK›Ü™ÃB‘›ÜˆY][Û˜[ÛÛ[X[™ ËK[XZ[ˆÙ[™\˜[ Z[ [˜ÝX˜]Ü‹˜\XÚK›Ü™ÃB
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)
Posted by Danese Cooper <da...@gmail.com>.
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.
Danese
> On Jan 15, 2016, at 9:32 AM, Alex Harui <ah...@adobe.com> wrote:
>
> Probably too late, but some comments in-line.
>
>> On 1/15/16, 6:55 AM, "Peter Kelly" <pm...@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.
>
>>
>> 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
>> http://www.apache.org/legal/resolved.html (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 on
>> 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]
> http://www.qt.io/qt-news/qt-open-source-licensing-changed-product-structure
> -updated-strengthen-community-extend-adoption/
>
> B‹KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKCB•È [œÝXœØÜšX™KK[XZ[ˆÙ[™\˜[ ][œÝXœØÜšX™P[˜ÝX˜]Ü‹˜\XÚK›Ü™ÃB‘›ÜˆY][Û˜[ÛÛ[X[™ ËK[XZ[ˆÙ[™\˜[ Z[ [˜ÝX˜]Ü‹˜\XÚK›Ü™ÃB
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
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)
Posted by "Dennis E. Hamilton" <de...@acm.org>.
I have declined to participate in any post-mortem activity.
There are some relevant matters to clarify in the bringing of this thread to general@ incubator.a.o, however.
Comments in-line.
> -----Original Message-----
> From: Alex Harui [mailto:aharui@adobe.com]
> Sent: Friday, January 15, 2016 09:32
> To: general@incubator.apache.org; dev@corinthia.incubator.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)
>
> Probably too late, but some comments in-line.
[ ... ]
> 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.
[orcmid]
Not exactly. What has been removed is LGPL 2.1. LGPL3 remains an option, along with GPL2, GPL3, and a separate commercial license.
>
[ ... ]
> 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.
>
[orcmid]
There was a contortion of the optional dependency case for ASF releases. The proposed workaround was to make optional *substitutability* for the Qt dependency. But no substitute with equivalent functionality was proposed or on offer.
A concern posted on the dev@ list gave cautionary warning the project might hit a wall with regard to this reversal of how optional dependency becomes acceptable, i.e. <http://www.apache.org/legal/resolved.html#optional>.
Inability to use Qt as the core framework for portable GUI clients became a technical deal-breaker for the podling, as Peter Kelly has already reported.
[ ... ]
>
> [1]
> http://www.qt.io/qt-news/qt-open-source-licensing-changed-product-structure-updated-strengthen-community-extend-adoption/
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
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)
Posted by Peter Kelly <pm...@apache.org>.
> On 16 Jan 2016, at 12:32 AM, Alex Harui <ah...@adobe.com> wrote:
>
> Probably too late, but some comments in-line.
>
> On 1/15/16, 6:55 AM, "Peter Kelly" <pm...@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)
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)
Posted by Roman Shaposhnik <ro...@shaposhnik.org>.
On Fri, Jan 15, 2016 at 9:32 AM, Alex Harui <ah...@adobe.com> wrote:
>>The ticking time bomb, as we discovered several months in, was the
>>disconcertingly-named “Category X list”, described at
>>http://www.apache.org/legal/resolved.html (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.
Last time we had this very Qt related discussion it was (I think!) Greg
who pointed out that you should probably use a viability argument for
something like Qt. Is your project still viable if something like Qt is
no longer available to it? (note it may be reduced functionality but
still viable)
If the answer is yes -- getting Qt from the runtime binding should be ok.
If the answer is no -- this wouldn't really be a self-contained ASF project,
would it?
Thanks,
Roman.
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
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)
Posted by Alex Harui <ah...@adobe.com>.
Probably too late, but some comments in-line.
On 1/15/16, 6:55 AM, "Peter Kelly" <pm...@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.
>
>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
>http://www.apache.org/legal/resolved.html (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 on
>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]
http://www.qt.io/qt-news/qt-open-source-licensing-changed-product-structure
-updated-strengthen-community-extend-adoption/
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)
Posted by Dave Fisher <da...@comcast.net>.
The qt discussion was a community process during incubation. It was not known in advance. This process Marvin describes would not have caught the issue. The community wanted to find a way more slowly and focus on code efforts. When asked to help slow the discussion someone heated it up instead.
Regards,
Dave
Sent from my iPhone
> On Jan 18, 2016, at 8:07 PM, Marvin Humphrey <ma...@rectangular.com> wrote:
>
>> On Fri, Jan 15, 2016 at 6:55 AM, Peter Kelly <pm...@apache.org> wrote:
>> The big takeaway from my experience, in terms of suggestions, is to make it
>> *very* clear on both the incubator website, and impressed upon anyone
>> considering joining incubator, exactly what can and cannot be done in within
>> the context of an ASF projects.
>
> In the incubation proposal template, there is a space for listing the
> dependencies of the project.
>
> http://incubator.apache.org/guides/proposal.html#template-external-dependencies
>
> External dependencies for the initial source is important. Only some
> external dependencies are allowed by Apache policy. These restrictions are
> (to some extent) initially relaxed for projects under incubation.
>
> If the initial source has dependencies which would prevent graduation then
> this is the right place to indicate how these issues will be resolved.
>
> This catches most problematic dependencies. However, in Corinthia's case, it
> seems that because Qt was a *future* dependency, it wasn't listed.
>
> http://wiki.apache.org/incubator/CorinthiaProposal#External_Dependencies
>
> To be clear, I don't think anybody's at fault here -- glitches arise naturally
> and inevitably from complex requirements, and preparing an incubation proposal
> is a complex undertaking. What I'm saying is that the proposed safety
> mechanisms already exist, yet were not fully effective.
>
> This is not the only time that there's been an issue with licensing which was
> discovered only after incubation started. When Groovy came to the ASF, a
> significant portion of the Groovy documentation was under CC-BY-SA. The ASF
> allows CC-BY but not CC-BY-SA, but the Groovy team was mistakenly informed on
> a non-ASF list that CC-BY-SA was not a problem, and regrettably none of the
> ASF participants in that discussion (including me) caught the mistake. And so
> that potential blocker was not dealt with until incubation was already
> underway.
>
> Fortunately, after substantial effort, Groovy's documentation was able to be
> relicensed -- there were only 15 or so contributors to that particular section
> and they were contactable and willing to give consent. But if that had not
> been the case, it would have been a big deal, because a lot of effort had
> already gone into moving Groovy to the ASF.
>
>> stuff like this needs to be made really, really clear right from
>> the beginning, before large amounts of time are invested in podlings that
>> later discover themselves doomed to fail from the start.
>
> It seemed that volunteer goodwill boiled away very quickly with Corinthia's
> crisis reached critical mass, for a variety of reasons. Complexity of
> requirements does seem to have been a contributing factor, and I accept that
> we have work to do.
>
> Best regards,
>
> Marvin Humphrey
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
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)
Posted by Marvin Humphrey <ma...@rectangular.com>.
On Fri, Jan 15, 2016 at 6:55 AM, Peter Kelly <pm...@apache.org> wrote:
> The big takeaway from my experience, in terms of suggestions, is to make it
> *very* clear on both the incubator website, and impressed upon anyone
> considering joining incubator, exactly what can and cannot be done in within
> the context of an ASF projects.
In the incubation proposal template, there is a space for listing the
dependencies of the project.
http://incubator.apache.org/guides/proposal.html#template-external-dependencies
External dependencies for the initial source is important. Only some
external dependencies are allowed by Apache policy. These restrictions are
(to some extent) initially relaxed for projects under incubation.
If the initial source has dependencies which would prevent graduation then
this is the right place to indicate how these issues will be resolved.
This catches most problematic dependencies. However, in Corinthia's case, it
seems that because Qt was a *future* dependency, it wasn't listed.
http://wiki.apache.org/incubator/CorinthiaProposal#External_Dependencies
To be clear, I don't think anybody's at fault here -- glitches arise naturally
and inevitably from complex requirements, and preparing an incubation proposal
is a complex undertaking. What I'm saying is that the proposed safety
mechanisms already exist, yet were not fully effective.
This is not the only time that there's been an issue with licensing which was
discovered only after incubation started. When Groovy came to the ASF, a
significant portion of the Groovy documentation was under CC-BY-SA. The ASF
allows CC-BY but not CC-BY-SA, but the Groovy team was mistakenly informed on
a non-ASF list that CC-BY-SA was not a problem, and regrettably none of the
ASF participants in that discussion (including me) caught the mistake. And so
that potential blocker was not dealt with until incubation was already
underway.
Fortunately, after substantial effort, Groovy's documentation was able to be
relicensed -- there were only 15 or so contributors to that particular section
and they were contactable and willing to give consent. But if that had not
been the case, it would have been a big deal, because a lot of effort had
already gone into moving Groovy to the ASF.
> stuff like this needs to be made really, really clear right from
> the beginning, before large amounts of time are invested in podlings that
> later discover themselves doomed to fail from the start.
It seemed that volunteer goodwill boiled away very quickly with Corinthia's
crisis reached critical mass, for a variety of reasons. Complexity of
requirements does seem to have been a contributing factor, and I accept that
we have work to do.
Best regards,
Marvin Humphrey
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
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)
Posted by Alex Harui <ah...@adobe.com>.
Probably too late, but some comments in-line.
On 1/15/16, 6:55 AM, "Peter Kelly" <pm...@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.
>
>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
>http://www.apache.org/legal/resolved.html (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 on
>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]
http://www.qt.io/qt-news/qt-open-source-licensing-changed-product-structure
-updated-strengthen-community-extend-adoption/
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)
Posted by Peter Kelly <pm...@apache.org>.
> On 9 Jan 2016, at 5:48 AM, Slow Joe <sl...@gmail.com> wrote:
>
>> Forming a podling is difficult as if often starts with a team that
>> hasn't necessarily chosen to work together. I bet the situation > would
>> have been very different if you guys had been able to meet in
>
>> person,
>
>> but in email that's quite hard.
>
>> -Bertrand
>
>
> Hi Bertrand
>
> I observed the meltdown of the Corinthia podling from a distance with some
> regret.
>
> Since the project is now on the verge of withdrawal from the incubator,
> could you and Dennis consider whether it would be valuable to collaborate
> on a blame-free post-mortem describing the events which lead to the end of
> Corinthia.
>
> (A template for a postmortem document is at
> https://lastbytes.wordpress.com/2013/01/15/a-postmortem-template/)
>
> I would suggest that there are lessons for the Apache Project to learn from
> this event.
>
> Regards
>
> Joe
I just realised I’m still subscribed to the dev list for Apache Corinthia. After we left ASF, I decided not to comment further on the situation (feeling it was easiest just to walk away) - but since there’s been a request for a post-portem, and it’s been a few months now and I’ve had a chance to calm down a bit, I figured I’d offer my thoughts.
(Disclaimer: I am not a lawyer; what I’ve written below regarding licenses and ASF policies is my own understanding, which may or may not be accurate. I welcome corrections or clarifications)
There were a number of issues that lead to the project’s exit from Incubator, mostly relating to personal disagreements between project members, which I have no desire to revisit, especially not in public. Ultimately it was those issues which triggered our exit (when I say “our” or “we” here, i refer to the subset of project members who were actively involved in development). However, one important factor which really killed things for us was the inability to use Qt.
Corinthia was envisaged as a combination of libraries for translating and editing word processing & office documents (the first 50% of the project), and a desktop + web application providing an editor usable by end-users (the second 50% of the project). We planned to produce two different editors - one which ran as a regular native desktop app on Windows, Linux, and OS X - and the other which could operate in the browser. 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.
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.
The ticking time bomb, as we discovered several months in, was the disconcertingly-named “Category X list”, described at http://www.apache.org/legal/resolved.html (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.
So once we learnt about this, 50% of the project was basically off the cards. We were told that not only can source code for an app that uses the Qt APIs not be included in an official Apache release, but that it should not even exist in the git repository as a piece of example code demonstrating how to use our other libraries.
One somewhat unsettling aspect of discussions I observed was that they were predicated on the assumption that the project should be done as an ASF project, and thus following ASF rules. Anything that deviated from the rules was immediately rejected on this basis. Now, that’s fair enough - we agreed to be part of the organisation, and rules should be followed. But one thing that was never seriously considered, until fairly late in the piece, was whether the project really belonged at ASF in the first place. Eventually, we concluded the answer was no.
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 on this list just a few months ago).
The big takeaway from my experience, in terms of suggestions, is to make it *very* clear on both the incubator website, and impressed upon anyone considering joining incubator, exactly what can and cannot be done in within the context of an ASF projects. Without this, I expect there to be more people coming away from incubator with really bad experiences, and disliking ASF as a result, such as the author of this article:
http://www.futurealoof.com/posts/apache-considered-harmful.html
I would make priority #1 clarifying what “included within” actually means, closely followed by more generally revising the rules surrounding license restrictions and others, so they don’t require extensive study and debate before it can be determined whether or not a given project is possible to do within ASF. While “You cannot write cross-platform desktop apps at ASF” is probably a little too strong (technically speaking, you could use your own dedicated cross-platform toolkit like OpenOffice does, or a web app wrapper like Electron), stuff like this needs to be made really, really clear right from the beginning, before large amounts of time are invested in podlings that later discover themselves doomed to fail from the start.
The most important lesson I learnt is to not get attached to any one particular organisation for a project. GitHub is a popular choice for many projects, and I don’t consider there to be anything wrong with moving a project there if it turns out to not fit within ASF’s rules and policies. That’s what we did with Corinthia (http://corinthia.io).
[Unfortunately, there hasn’t been any further progress on the project since the move, but that’s due to unrelated reasons (some people left, others like myself have been to busy with other things to devote time to it). I’ve recently finished up a contract though and now have some spare time on my hands, so I hope to try and get it re-started soon.]
Most importantly, working on GitHub or a similar hosting site gives a project team complete freedom to operate how they want. ASF espouses the mantra “community over code”, but in reality it’s “restrictive policies over community over code”. My experience has been that if it’s necessary to destroy (or rather “jettison”) a community or project in order to ensure such a policy is enforced, then the tradeoff is worth it.
I don’t think that’s a healthy way of doing open source in 2016.
--
Dr. Peter M. Kelly
pmkelly@apache.org
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)
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)
Posted by Peter Kelly <pm...@apache.org>.
> On 9 Jan 2016, at 5:48 AM, Slow Joe <sl...@gmail.com> wrote:
>
>> Forming a podling is difficult as if often starts with a team that
>> hasn't necessarily chosen to work together. I bet the situation > would
>> have been very different if you guys had been able to meet in
>
>> person,
>
>> but in email that's quite hard.
>
>> -Bertrand
>
>
> Hi Bertrand
>
> I observed the meltdown of the Corinthia podling from a distance with some
> regret.
>
> Since the project is now on the verge of withdrawal from the incubator,
> could you and Dennis consider whether it would be valuable to collaborate
> on a blame-free post-mortem describing the events which lead to the end of
> Corinthia.
>
> (A template for a postmortem document is at
> https://lastbytes.wordpress.com/2013/01/15/a-postmortem-template/)
>
> I would suggest that there are lessons for the Apache Project to learn from
> this event.
>
> Regards
>
> Joe
I just realised I’m still subscribed to the dev list for Apache Corinthia. After we left ASF, I decided not to comment further on the situation (feeling it was easiest just to walk away) - but since there’s been a request for a post-portem, and it’s been a few months now and I’ve had a chance to calm down a bit, I figured I’d offer my thoughts.
(Disclaimer: I am not a lawyer; what I’ve written below regarding licenses and ASF policies is my own understanding, which may or may not be accurate. I welcome corrections or clarifications)
There were a number of issues that lead to the project’s exit from Incubator, mostly relating to personal disagreements between project members, which I have no desire to revisit, especially not in public. Ultimately it was those issues which triggered our exit (when I say “our” or “we” here, i refer to the subset of project members who were actively involved in development). However, one important factor which really killed things for us was the inability to use Qt.
Corinthia was envisaged as a combination of libraries for translating and editing word processing & office documents (the first 50% of the project), and a desktop + web application providing an editor usable by end-users (the second 50% of the project). We planned to produce two different editors - one which ran as a regular native desktop app on Windows, Linux, and OS X - and the other which could operate in the browser. 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.
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.
The ticking time bomb, as we discovered several months in, was the disconcertingly-named “Category X list”, described at http://www.apache.org/legal/resolved.html (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.
So once we learnt about this, 50% of the project was basically off the cards. We were told that not only can source code for an app that uses the Qt APIs not be included in an official Apache release, but that it should not even exist in the git repository as a piece of example code demonstrating how to use our other libraries.
One somewhat unsettling aspect of discussions I observed was that they were predicated on the assumption that the project should be done as an ASF project, and thus following ASF rules. Anything that deviated from the rules was immediately rejected on this basis. Now, that’s fair enough - we agreed to be part of the organisation, and rules should be followed. But one thing that was never seriously considered, until fairly late in the piece, was whether the project really belonged at ASF in the first place. Eventually, we concluded the answer was no.
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 on this list just a few months ago).
The big takeaway from my experience, in terms of suggestions, is to make it *very* clear on both the incubator website, and impressed upon anyone considering joining incubator, exactly what can and cannot be done in within the context of an ASF projects. Without this, I expect there to be more people coming away from incubator with really bad experiences, and disliking ASF as a result, such as the author of this article:
http://www.futurealoof.com/posts/apache-considered-harmful.html
I would make priority #1 clarifying what “included within” actually means, closely followed by more generally revising the rules surrounding license restrictions and others, so they don’t require extensive study and debate before it can be determined whether or not a given project is possible to do within ASF. While “You cannot write cross-platform desktop apps at ASF” is probably a little too strong (technically speaking, you could use your own dedicated cross-platform toolkit like OpenOffice does, or a web app wrapper like Electron), stuff like this needs to be made really, really clear right from the beginning, before large amounts of time are invested in podlings that later discover themselves doomed to fail from the start.
The most important lesson I learnt is to not get attached to any one particular organisation for a project. GitHub is a popular choice for many projects, and I don’t consider there to be anything wrong with moving a project there if it turns out to not fit within ASF’s rules and policies. That’s what we did with Corinthia (http://corinthia.io).
[Unfortunately, there hasn’t been any further progress on the project since the move, but that’s due to unrelated reasons (some people left, others like myself have been to busy with other things to devote time to it). I’ve recently finished up a contract though and now have some spare time on my hands, so I hope to try and get it re-started soon.]
Most importantly, working on GitHub or a similar hosting site gives a project team complete freedom to operate how they want. ASF espouses the mantra “community over code”, but in reality it’s “restrictive policies over community over code”. My experience has been that if it’s necessary to destroy (or rather “jettison”) a community or project in order to ensure such a policy is enforced, then the tradeoff is worth it.
I don’t think that’s a healthy way of doing open source in 2016.
--
Dr. Peter M. Kelly
pmkelly@apache.org
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)