Re: Some clarification needed for Apache Extra projects - Apache Extra in specific
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. Ross -- Ross Gardler (@rgardler) Programme Leader (Open Development) OpenDirective http://opendirective.com
Re: Some clarification needed for Apache Extra projects - Apache Extra in specific
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
Re: Some clarification needed for Apache Extra projects - Apache Extra in specific
I though Ross was very clear in his explanation, but apparently not... rant please-ignore=trueUnfortunately 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.
Re: Some clarification needed for Apache Extra projects - Apache Extra in specific
Hadrian, thanks for the excellent summary. Best, Christian On Fri, Sep 28, 2012 at 11:45 PM, Hadrian Zbarcea hzbar...@gmail.comwrote: 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
Re: Some clarification needed for Apache Extra projects - Apache Extra in specific
On Thu, September 27, 2012 11:24, Ross Gardler wrote: On 27 September 2012 10:17, Ulrich Stärk u...@spielviel.de wrote: So an additional binary package including e.g. your Hibernate integration and a separate location in SVN/GIT where users can get the sources are OK IMO as long as both are not part of your official source distribution. This is not correct. The ASF does not maintain code under incompatible licenses. Ross Were did I say that? I'm talking about code depending on software with incompatible licenses, such as a Hibernate integration. Specifically the Hibernate integrations have been discussed several times and if I'm not mistaken the resolutions were always deal with them according to http://www.apache.org/legal/resolved.html#optional; (e.g. [1]). So yes, the integration code may be maintained at the ASF (under the ASL of course) but not included in your distribution. I can imagine the same holds true for other integrations. But really, this is a question for legal and the PMC to decide. From a community point of view Ross is absolutely right. The ASF is not a place where non-ASL licensed software is developed and maintained. I simply wanted to point a way out of this dilemma. Uli [1] https://issues.apache.org/jira/browse/LEGAL-8
Re: Some clarification needed for Apache Extra projects - Apache Extra in specific
On 27 September 2012 11:01, Ulrich Stärk u...@spielviel.de wrote: On Thu, September 27, 2012 11:24, Ross Gardler wrote: On 27 September 2012 10:17, Ulrich Stärk u...@spielviel.de wrote: So an additional binary package including e.g. your Hibernate integration and a separate location in SVN/GIT where users can get the sources are OK IMO as long as both are not part of your official source distribution. This is not correct. The ASF does not maintain code under incompatible licenses. Ross Were did I say that? I'm talking about code depending on software with incompatible licenses, such as a Hibernate integration. If you didn't mean a separate SVN/Git repo on ASF hardware then you didn't say it and I misunderstood. The code in question, at http://code.google.com/a/apache-extras.org/p/camel-extra/ is under the GPL. The questions, as I read them, can be paraphrased as can we develop GPL code using ASF infrastructure for everything else, from a community perspective I would say the answer is no (which you seem to agree with). I don't believe the question is about being legal able to use the code, the PMC is already using it. Ross
Re: Some clarification needed for Apache Extra projects - Apache Extra in specific
Perhaps I can help here. The root of all this, as I understand it, is an optional dependency. There is, of course, code that depends on the optional dependency. However, no one has mentioned any *source* code that is under an incompatible license, such as modified sources of an LGPL component. This is the critical question. If this is AL source code that makes calls to an LGPL component, then it can live in an ordinary AL source repository and be distributed in an ordinary AL release. However, a user must be able to build the release, by default, without the LGPL binary dependency.Thus, 'optional'. If, on the other hand, some members of a PMC wish to build source code that is not under the AL, it cannot be at Apache and there must be a bright line that avoids any confusion. Such a project could be at Extras, but then the question arises about 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.'
Re: Some clarification needed for Apache Extra projects - Apache Extra in specific
On 27.09.2012 12:34, Ross Gardler wrote: On 27 September 2012 11:01, Ulrich Stärk u...@spielviel.de wrote: On Thu, September 27, 2012 11:24, Ross Gardler wrote: On 27 September 2012 10:17, Ulrich Stärk u...@spielviel.de wrote: So an additional binary package including e.g. your Hibernate integration and a separate location in SVN/GIT where users can get the sources are OK IMO as long as both are not part of your official source distribution. This is not correct. The ASF does not maintain code under incompatible licenses. Ross Were did I say that? I'm talking about code depending on software with incompatible licenses, such as a Hibernate integration. If you didn't mean a separate SVN/Git repo on ASF hardware then you didn't say it and I misunderstood. I said separate location in SVN/GIT and meant a separate folder or whatever but not a separate repo. The code in question, at http://code.google.com/a/apache-extras.org/p/camel-extra/ is under the GPL. The questions, as I read them, can be paraphrased as can we develop GPL code using ASF infrastructure for everything else, from a community perspective I would say the answer is no (which you seem to agree with). I don't believe the question is about being legal able to use the code, the PMC is already using it. Ross So everyone agrees. Great ;) Uli
Re: Some clarification needed for Apache Extra projects - Apache Extra in specific
On 27.09.2012 13:26, Benson Margulies wrote: Perhaps I can help here. The root of all this, as I understand it, is an optional dependency. There is, of course, code that depends on the optional dependency. However, no one has mentioned any *source* code that is under an incompatible license, such as modified sources of an LGPL component. This is the critical question. If this is AL source code that makes calls to an LGPL component, then it can live in an ordinary AL source repository and be distributed in an ordinary AL release. However, a user must be able to build the release, by default, without the LGPL binary dependency.Thus, 'optional'. If, on the other hand, some members of a PMC wish to build source code that is not under the AL, it cannot be at Apache and there must be a bright line that avoids any confusion. Such a project could be at Extras, but then the question arises about 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.' +1
Re: Some clarification needed for Apache Extra projects - Apache Extra in specific
I'm replying to the original message as this thread seems to be taking a different direction. Based on the Apache Extras guidelines snippet below: Projects hosted on Apache Extras are not considered official Apache Software Foundation projects and they are also not associated, allied, or otherwise organizationally related to The Apache Software Foundation. Therefore, we require project owners to respect the Apache Software Foundation trademark policy by clearly indicating that your Apache Extras project name is not an official project of the Apache Software Foundation. In general, projects hosted on Apache Extras must not portray themselves as official Apache Software Foundation projects. Clarification on these rules should be sought from the Apache Project Committees related to your Apache Extras project, or to the Apache Community Development Committee in general. Apache Extras projects are like external projects, with possible license aggravates. In general, I'd say that, if the project is hosted in Apache Extras because it's not compatible with AL2 (or for some other reason), the related Apache project can point/link to the external project (e.g. BTW, here are a list of external projects related to Apache Camel link), but should not actually host code, defects, etc related to these external projects. Now, see inline comments related to the specific questions : On Wed, Sep 26, 2012 at 2:06 PM, Christian Müller christian.muel...@gmail.com wrote: Hello! A few day ago, I started a thread [1], mainly because we wanted to forward our Camel Extra [2] commit and issue notifications to our regular Camel mailing list. We had some issues with this and asked INFRA for help. Now we realized, there are different understandings what we can do (allowed to do) and what not. I didn't found an answer at [3] or [4]. I want clarification about the following question: - Is it inline with the Apache policy to forward commit notifications from Apache Extra projects to the regular Apache project mailing list (INFRA managed)? Apache Extras projects are external to Apache and should be treated as so. Having non AL2 compatible code snippets being mixed together with Apache project commits can and will cause confusion to people searching the commit archives. - Is it inline with the Apache policy to forward issue notifications from Apache Extra issue tracker (Google code) to the regular Apache project mailing list (INFRA managed)? See above. - Is it inline with the Apache policy to direct users from Apache Extra to raise issues at the regular Apache issue tracker (JIRA)? Yes, if indeed there is a bug in the core Apache Project. - Is it inline with the Apache policy to host content on Apache Confluence which covers Apache Extra artifacts (e.g. http://camel.apache.org/hibernate.html)? The Apache Guidelines mention Each Apache Extras project is encouraged to publish their releases and complete the project tagging information available on Apache Extras. Which to me translates in each Apache Extras projects being responsible for their own releases, documentation, etc. and an Apache project would point to other extensions available in ... and link to the Apache Extras release and documentation page. Which would clearly identify the official disassociation and any possible confusion of an Apache Extra project being an Apache project. I'd also mention that the Apache Extras projects should not use org.apache.xxx packages, but org.apache-extras.xxx package. [1] http://camel.465427.n5.nabble.com/Re-Apache-Extras-notifications-was-Disable-GitHub-commenting-httpd-td5719778.html [2] http://code.google.com/a/apache-extras.org/p/camel-extra/ [3] https://blogs.apache.org/foundation/entry/the_apache_software_foundation_launches [4] http://community.apache.org/apache-extras/guidelines.html Thanks in advance, Christian -- -- Luciano Resende http://people.apache.org/~lresende http://twitter.com/lresende1975 http://lresende.blogspot.com/
RE: Some clarification needed for Apache Extra projects - Apache Extra in specific
Luciano's account identifies a clean, bright line between Apache Extras and any Apache project. One point of clarification, however, since I see this statement repeatedly. It is clear that an Apache Extras project should not *deliver* packages or components on any org.apache.xxx... class path. *Using* packages and definitions on such class paths is a different story. Those are usable under provisions of the ALv2 license. I see no useful purpose in prohibition external code declaring entities having types defined on an org.apache.xxx class path. Obvious cases are the provision of interfaces, declaration of subordinate classes, and declaration of instances of classes all defined for public use in org.apache.xxx... packages. I think any prohibition on *use* must be in the reverse direction. The Apache project source code cannot have such dependencies on entities defined in an org.apache-extras.xxx... package. - Dennis -Original Message- From: Luciano Resende [mailto:luckbr1...@gmail.com] Sent: Thursday, September 27, 2012 10:24 To: dev@community.apache.org Subject: Re: Some clarification needed for Apache Extra projects - Apache Extra in specific [ ... ] I'd also mention that the Apache Extras projects should not use org.apache.xxx packages, but org.apache-extras.xxx package. [ ... ] -- Luciano Resende http://people.apache.org/~lresende http://twitter.com/lresende1975 http://lresende.blogspot.com/
RE: Some clarification needed for Apache Extra projects - Apache Extra in specific
Sent from my tablet On Sep 27, 2012 9:51 PM, Dennis E. Hamilton orc...@apache.org wrote: Luciano's account identifies a clean, bright line between Apache Extras and any Apache project. One point of clarification, however, since I see this statement repeatedly. It is clear that an Apache Extras project should not *deliver* packages or components on any org.apache.xxx... class path. *Using* packages and definitions on such class paths is a different story. Those are usable under provisions of the ALv2 license. I see no useful purpose in prohibition external code declaring entities having types defined on an org.apache.xxx class path. Obvious cases are the provision of interfaces, declaration of subordinate classes, and declaration of instances of classes all defined for public use in org.apache.xxx... packages. It's a trademark issue. Since we don't want to actively police extras managing trademark usage there would be too onerous. I think any prohibition on *use* must be in the reverse direction. The Apache project source code cannot have such dependencies on entities defined in an org.apache-extras.xxx... package. Why? Perhaps you are assuming that all code at extras is incompatibly licensed, that is not the case, or perhaps you have some other reason in mind. Ross - Dennis -Original Message- From: Luciano Resende [mailto:luckbr1...@gmail.com] Sent: Thursday, September 27, 2012 10:24 To: dev@community.apache.org Subject: Re: Some clarification needed for Apache Extra projects - Apache Extra in specific [ ... ] I'd also mention that the Apache Extras projects should not use org.apache.xxx packages, but org.apache-extras.xxx package. [ ... ] -- Luciano Resende http://people.apache.org/~lresende http://twitter.com/lresende1975 http://lresende.blogspot.com/
RE: Some clarification needed for Apache Extra projects - Apache Extra in specific
Yes, I did presume that the case at hand involved incompatible licensing or the source code could be used in the Apache project without any fuss. A Category B Java Package dependency would be awkward but I presume surmountable. -Original Message- From: Ross Gardler [mailto:rgard...@opendirective.com] Sent: Thursday, September 27, 2012 13:56 To: Dennis Hamilton; dev@community.apache.org Subject: RE: Some clarification needed for Apache Extra projects - Apache Extra in specific Sent from my tablet On Sep 27, 2012 9:51 PM, Dennis E. Hamilton orc...@apache.org wrote: [ ... ] I think any prohibition on *use* must be in the reverse direction. The Apache project source code cannot have such dependencies on entities defined in an org.apache-extras.xxx... package. Why? Perhaps you are assuming that all code at extras is incompatibly licensed, that is not the case, or perhaps you have some other reason in mind. Ross - Dennis -Original Message- From: Luciano Resende [mailto:luckbr1...@gmail.com] Sent: Thursday, September 27, 2012 10:24 To: dev@community.apache.org Subject: Re: Some clarification needed for Apache Extra projects - Apache Extra in specific [ ... ] I'd also mention that the Apache Extras projects should not use org.apache.xxx packages, but org.apache-extras.xxx package. [ ... ] -- Luciano Resende http://people.apache.org/~lresende http://twitter.com/lresende1975 http://lresende.blogspot.com/
Re: Some clarification needed for Apache Extra projects - Apache Extra in specific
On Thu, Sep 27, 2012 at 6:41 PM, Rob Weir robw...@apache.org wrote: I think that is just engineering prudence. Take the example of a component that you might have a dependency. I see no problem with a PMC wanting to be informed about all changes to that component as well as all bugs found in that component. That information is entirely relevant to the Apache project. At the very least a PMC should be aware of security flaws identified in any dependencies, optional or otherwise, since this may require steps such as a patch to interface code. This is a very common scenario at Apache, when project A has a dependency in project B, does it start forwarding mailing lists or particular members go subscribe to the mailing lists of the other project ? When someone comes to project A and says there is a problem, which is really a big in project B, we might create a jira in project A, but we really send people to create a defect in project B. There is clear boundaries between the two projects, and in case of apache projects, they have compatible licenses. When we consider Apache Extras, most of the time there will be license issues and that's why we want to make clear they are different projects. I understand the concern about avoiding the appearance that the PMC is building source code that is not under the AL, but surely that depends on what the PMC *pushes or writes* to the Apache Extras, not on what they *read*. Being informed is never a crime. 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. My main concerns are with commit notifications, which will contain non AL2 code being forwarded to the same archive where the main apache commits are being archived and can cause confusion with in the long run. Regards, -Rob -- Luciano Resende http://people.apache.org/~lresende http://twitter.com/lresende1975 http://lresende.blogspot.com/
Some clarification needed for Apache Extra projects - Apache Extra in specific
Hello! A few day ago, I started a thread [1], mainly because we wanted to forward our Camel Extra [2] commit and issue notifications to our regular Camel mailing list. We had some issues with this and asked INFRA for help. Now we realized, there are different understandings what we can do (allowed to do) and what not. I didn't found an answer at [3] or [4]. I want clarification about the following question: - Is it inline with the Apache policy to forward commit notifications from Apache Extra projects to the regular Apache project mailing list (INFRA managed)? - Is it inline with the Apache policy to forward issue notifications from Apache Extra issue tracker (Google code) to the regular Apache project mailing list (INFRA managed)? - Is it inline with the Apache policy to direct users from Apache Extra to raise issues at the regular Apache issue tracker (JIRA)? - Is it inline with the Apache policy to host content on Apache Confluence which covers Apache Extra artifacts (e.g. http://camel.apache.org/hibernate.html)? [1] http://camel.465427.n5.nabble.com/Re-Apache-Extras-notifications-was-Disable-GitHub-commenting-httpd-td5719778.html [2] http://code.google.com/a/apache-extras.org/p/camel-extra/ [3] https://blogs.apache.org/foundation/entry/the_apache_software_foundation_launches [4] http://community.apache.org/apache-extras/guidelines.html Thanks in advance, Christian --
Re: Some clarification needed for Apache Extra projects - Apache Extra in specific
As I see it the end result of the proposed activity is an Apache community producing GPL code. Extras is not intended to be a way to route around ASF policies relating to licence choice. It is intended to be a place for apache related projects. Others may see it differently. Sent from my tablet On Sep 26, 2012 10:07 PM, Christian Müller christian.muel...@gmail.com wrote: Hello! A few day ago, I started a thread [1], mainly because we wanted to forward our Camel Extra [2] commit and issue notifications to our regular Camel mailing list. We had some issues with this and asked INFRA for help. Now we realized, there are different understandings what we can do (allowed to do) and what not. I didn't found an answer at [3] or [4]. I want clarification about the following question: - Is it inline with the Apache policy to forward commit notifications from Apache Extra projects to the regular Apache project mailing list (INFRA managed)? - Is it inline with the Apache policy to forward issue notifications from Apache Extra issue tracker (Google code) to the regular Apache project mailing list (INFRA managed)? - Is it inline with the Apache policy to direct users from Apache Extra to raise issues at the regular Apache issue tracker (JIRA)? - Is it inline with the Apache policy to host content on Apache Confluence which covers Apache Extra artifacts (e.g. http://camel.apache.org/hibernate.html)? [1] http://camel.465427.n5.nabble.com/Re-Apache-Extras-notifications-was-Disable-GitHub-commenting-httpd-td5719778.html [2] http://code.google.com/a/apache-extras.org/p/camel-extra/ [3] https://blogs.apache.org/foundation/entry/the_apache_software_foundation_launches [4] http://community.apache.org/apache-extras/guidelines.html Thanks in advance, Christian --
