On 29 July 2015 at 22:39, Dennis E. Hamilton <dennis.hamil...@acm.org> wrote:
> While Corinthia is in the incubator, all releases, once approved by the > project, must be reviewed and approved by the Incubator PMC. > correct. > > For the first release there will be great scrutiny on IP provenance in the > source code. It is then expected that a mechanism to continue having clean > IP provenance will be sustained throughout incubation and into the future > whenever Corinthia becomes a Top-Level Apache Project (TLP). This scrutiny > also includes dealing with the presence of third party software, or > dependence on third-party software, essential to use of a built version of > the software. (There is no problem with tools used to build the software, > so long as they don't impose license conditions on what is built.) > That is new to me (as IPMC member). We did do a IP clearance earlier, and passed. Of course EVERY release is controlled of which libraries we use. For the first release, I anticipate (but being only one of many PPMC I cannot say) that we will not release all of trunk, I aim at releasing only docFormats, which sort of makes your point a bit strange. > > Part of the reason for incubation is to provide a learning curve for the > new project with respect to how ASF projects operate and the basic > principles and, in some cases, specific policies. > correct. > > It is not at all unusual that there will be some deconstruction of natural > inclinations and suppositions when the constraints on being an Apache > Project are encountered and then dealt with. > My english cannot cope with what you imply here. > > - Dennis > > PS: There is not scripture or holy writ anywhere that compels successful > open-source projects to be Apache Projects. > huh? > > -----Original Message----- > From: Peter Kelly [mailto:pmke...@apache.org] > Sent: Wednesday, July 29, 2015 10:17 > To: dev@corinthia.incubator.apache.org > Subject: Re: Proposal editor development framework. > > One other thought on the issue of Qt: I think we need to be careful to > balance the goals of getting to a functioning reference implementation, and > ensuring that we have an app that can be built without depending on any > LGPL libraries. Actually I thought the whole point of LGPL was that you can > use it in applications under any circumstance, and only need to distribute > any changes to the library itself. This is the first instance in which I’ve > been aware that it carries other obligations (which I’m still confused > about). > > Right now I think the discussion has turned too far towards the latter > licensing issue. We’re here to build great software (or at least, I am) - > that’s the goal, everything else is in support of that. Yes, we do need to > ensure that anything that we mark as part of the “core” (non-optional) part > of the codebase can be built by depending only on Apache-licensed code or > operating-system libraries. > > But to be honest, I see this issue as a block on development. If we get > too caught up in religiously following rules at the expense of development > speed, we put the project at risk - either by taking to long to eventually > get something done, or potentially alienating new or existing contributors. > [ ... ] > > >
