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 <mar...@rectangular.com> wrote: > >> On Fri, Jan 15, 2016 at 6:55 AM, Peter Kelly <pmke...@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-unsubscr...@incubator.apache.org > For additional commands, e-mail: general-h...@incubator.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
