I though Ross was very clear in his explanation, but apparently not...
<rant please-ignore="true">Unfortunately this thread (happens too often
at the ASF) is digressing into hypothetical, vague and philosophical
discussions.</rant>
Quoting Ross: "this *is* completely different". As an aside, I
personally don't consider subscribing a private@ PMC mailing list to
another list the smartest thing to do, I'd rather have individual PMC
members subscribe and inform the rest of the PMC. That however doesn't
cause any issue because, quoting Ross again, that's just a
"communication link". I would add that that is a unidirectional
communication link, by which the external project communicates something
of interest to an audience, and a PMC happens to be part of said
audience. The PMC is a *passive* participant.
This is not the case of the camel-extra project. Apache Camel is an
integration framework. Its intent is to simplify integration by
providing a common API and bridging glue components for a large number
of protocols and data formats. The specific protocol implementations
however come from 3rd party libraries. For most of the technologies of
interest, Camel found/uses libraries with a compatible license. The
camel-extra project was created to extend the reach of Apache Camel to
technologies available under non-compatible licenses (e.g. xGPL). The
project was started and controlled by Camel committers on google code
and later moved to apache-extras (kinda the same thing). The camel-extra
project was never governed as an ASF project from many points of view,
including oversight, release process and IP management. The project had
committers who are not ASF committers for instance. The Apache Camel
committers have control over the project and are *active* in the
government of the project *as individuals* (albeit not completely
following the ASF guidelines). This is the difference.
There is a (valid) perception that the camel-extra is an extension of
the Apache Camel project. That was fueled by the fact that some
camel-extra components are documented on the ASF camel site. This thread
was actually started by an enthusiastic request of a new Apache Camel
committer on the premises that "it would be nice if" Apache Camel were a
one stop shop for both projects/communities. I.e. why work in 2 places,
2 sets of infrastructure, etc, when Apache Camel is already the
established/recognized one. While it would be nice for users indeed, it
is not compatible to the way the ASF operates. (To use your analogy,
think more like the LibreOffice community operating from within the
Apache OpenOffice community, using the same site and mailing lists).
FWIW, this was mentioned on the camel lists, but that was probably not
considered enough. Christian, the Camel PMC chair, knowing full well the
dynamics of the community, did the right thing and decided to forward
the question/request to a more authoritative forum. In the meanwhile the
Camel community got the message from all replies in this thread (I
think) and the changes currently made to the camel-extra project reflect
the differences between the two communities. However the thread lingers
on on this list...
I hope this clarifies the current status a bit better.
Hadrian
On 09/28/2012 03:44 PM, Rob Weir wrote:
On Fri, Sep 28, 2012 at 4:13 AM, Ross Gardler
<rgard...@opendirective.com> wrote:
On 28 September 2012 02:41, Rob Weir <robw...@apache.org> wrote:
...
Specific example. OpenOffice podling has signed up for a security
mailing list where we receive security-related bug reports from
LibreOffice, an open source project that is LGPL/MPL, not ALv2. We do
this by subscribing our security list directly to theirs. Is this
against policy? This seems directly analogous to a project receiving
bug reports from a non ALv2 Apache Extras project.
This is completely different. LibreOffice is a separate project with a
separate infrastructure and community. The subscription of an ASF list
to a LibreOffice list is nothing more than a communication link
between two distinct entities. The proposal here is to not create a
separate project with a separate management structure but to simply
host incompatible code externally and manage it from within an ASF
PMC.
Exactly my point. To the question put earlier:
"whether mailing list connections and other conveniences would create
unacceptable confusion
about the distinction between 'things the PMC does' and 'things some
PMC members happen to do elsewhere.'"
IMHO, the mailing list connections are not the issue. The issue is
the relationship between the Apache Extras project and the Apache
projects. If the relationship is improper, from a control and
dependency perspective, then that is the problem. The mailing list
use connection does not create the problem. And I suspect that
avoiding the mailing list connections would change nothing fundamental
if there were a control and dependency issue.
Regards,
-Rob
Ross
--
Ross Gardler (@rgardler)
Programme Leader (Open Development)
OpenDirective http://opendirective.com
