incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Konstantin Boudnik <>
Subject Re: [DISCUSS] BOM and supported platforms for Bigtop 0.4.0
Date Sat, 05 May 2012 18:53:52 GMT
On Fri, May 04, 2012 at 11:02AM, Patrick Hunt wrote:
> On Fri, May 4, 2012 at 9:47 AM, Owen O'Malley <> wrote:
> > On Fri, May 4, 2012 at 8:58 AM, Patrick Hunt <> wrote:
> >> It's not the job of the incubator to create new rules, but rather to
> >> help podlings to graduation while following existing Apache
> >> guidelines.
> >
> > We aren't making new rules. We are trying to help the Bigtop project
> > understand the rules about not releasing non-Apache software. There is
> > a huge difference between depending on an artifact from another
> > project and building and distributing non-Apache rpms in the project's
> > /dist directory.
> They are not releasing non-Apache software. They are not forking an
> existing project. Bigtop's release artifact will contain packaging
> code which allows users to compile packages (deb, rpm, etc...) for
> this ASL licensed component, not the source/binaries of the component
> itself.

Thank you Patrick to bringing this back again! It seems that this point keeps
dropping on the floor all the time. BigTop releases are merely a source code
for tools to produce and validate the integrity of software stacks. Let's keep
in mind at the next round of deliberations.

Packages are secondary and can be stored someplace else, because really anyone
can produce them with ease using BigTop. If someone dislike component-A for
one reason or another - it is easy to remote it from a particular release's
BOM file. 


> >> It's very clear from
> >> that what has been proposed
> >> is acceptable under existing Apache rules.
> >
> > Can you find a single instance other than the disagreement between
> > Apache Lucene and Apache Commons where one project is distributing
> > another project's rpms? Are there any other non-Apache rpms in /dist?
> > Clearly the answer is a resounding NO. It would be a huge violation of
> > the trust the incubator is putting in me as a mentor if I didn't block
> > Bigtop's plan to do so.
> If the component made an objection to being included in Bigtop then I
> could see an argument to be made, that's not the case here. The
> opposite is true from what I've seen -- people want their software to
> be included so that users can more easily consume it. That's why they
> released their software under a less restrictive license in the first
> place.
> EOD existing Apache rules/license make no such distinction. "Works
> under the following licenses may be included within Apache products"
> (includes ASL).
> Patrick

View raw message