I don't know if I'm subscribed to dev@community, so any future replies
may not reach me.

Let me give you what I think is an equivalent analogy.

Assume Microsoft sets up a community hosting site for projects related
to Microsoft products.

Assume you are an employee of Microsoft.

Assume that Microsoft states that, while they are providing the site,
you may not include "Microsoft" in your project name or use the
Microsoft branding, nor may you use "com.microsoft" as a java package.

You, as an ASF member and PMC chair are equivalent to the employee in
this scenario.   Even though you are an ASF member or PMC chair, you
do not have the right to use the company assets without permission.
In this case, the real permission you are seeking is the right to
release an Apache product that contains LGPL-licensed code.   The
Apache Extras site isn't going to provide you a loophole to do this.


On Thu, Dec 29, 2011 at 1:35 PM, Mattmann, Chris A (388J)
<chris.a.mattm...@jpl.nasa.gov> wrote:
> (cc'ing dev@community and setting reply-to: header so that replies
> go there)
>
> Hi Mike,
>
> First off, thanks for replying. Comments inline below:
>
> On Dec 29, 2011, at 6:33 AM, Mike Kienenberger wrote:
>
>> I am not an official Apache member, but here's my take on it.
>>
>> The Extras project area is for projects related to Apache, but not in
>> any way managed by the Apache Software Foundation.  Because of that,
>> it may not use the Apache brand-name, trademarks, nor the "org.apache"
>> namespace.
>
> It's my understanding that anyone can start up a project at Apache Extras,
> in which case, if that person doesn't have an availid here at the ASF, and
> doesn't have an ICLA on file, then that's another situation that I won't
> speculate on. What I'm much more interested in is in the situation I presented
> within this thread. I have an availid. I am an ASF member. I was looking
> at Apache Extras as a place to share some Apache OODT plugins that
> leverage code that is LGPL licensed, that I couldn't otherwise share within
> the normal Apache OODT SVN home. Prior to me coming to Apache Extras,
> this has been code housed in an internal JPL SVN repository for years, even
> before we brought the software to Apache. I'd like to use Apache Extras to
> facilitate sharing with an even broader community and to share the plugins
> we've developed (which themselves are ALv2 licensed) with others.
>
>>
>> Consider Apache Extras to be more of an unofficial fan site of Apache.
>>
>> If someone (in this case, you) wants to create something that directly
>> interacts or is related to Apache OODT, this non-related site gives
>> you a place to put it where other Apache OODT users are more likely to
>> find it.
>
> Yep that's what I thought to, which is why I cam here. However, 3.1 and 3.2
> are in direct conflict with the mannerism in which I'd like to share the code.
> I *want* to use the org.apache.oodt Java package namespace. I'm a PMC member 
> for
> OODT. The project at Extras is admin'ed by me and open to any OODT PMC
> members. I think we should be able to indicate our relationship to Apache
> OODT via use of the namespace and via calling my project 
> oodt-pushpull-plugins.
>
>>  But how the project is managed is up to you, and the
>> ownership of the project and its assets remains with you.
>
> That's not how I read 3.1 and 3.2. Because if what you're saying is true, then
> we wouldn't have 3.1 and 3.2 because I would abide by them per my comments
> above.
>
> I guess to boil it down: as an ASF member, and a PMC chair for Apache OODT,
> Apache Extras (with 3.1 and 3.2) isn't serving our needs as a community. I'd 
> like
> to fix that. Here's 2 concrete suggestions:
>
> 1. remove 3.1 and 3.2 -- I don't think in reality they are needed and I think 
> they serve
> to discourage folks from actually being an "Apache Extra" project -- a 
> closely related
> to an Apache project set of code that because of e.g., licensing 
> restrictions, etc.,
> couldn't normally be housed at Apache. The Apache Extras use cases I distill 
> from
> FAQ section 5 here [1]:
>
> {quote}
> We recommend starting a project here if one or more of the following is true:
>        • the project is experimental and the committers are not sure of the 
> future direction.
>        • the project has a license or depends on a license that is not 
> compatible with the Apache License 2.0
>        • the project is targeted at a small niche and might not benefit from 
> the wider exposure of being an Apache Software project.
> {quote}
>
> are precisely the reason that I thought that Apache Extras was the right 
> place to bring
> my code. What I'm proposing IMHO falls into the 2nd bullet.
>
> 2. loosen the language in 3.1 and 3.2 -- for example, an exception mechanism 
> in which
> if an Apache Extras project is operated by an ASF member, and the 
> PMC/committee doesn't
> have an issue with using the org.apache.* namespace/similar plugin name 
> (because
> in the end it benefits their community), then allow them to obviate 3.1 and 
> 3.2. I'd be happy
> to write up the patch to the FAQ/guidelines if there is lazy consensus with 
> this option. I'd
> also be happy to hold a formal VOTE on the Apache OODT lists should this 
> option be
> OK'ed by community@.
>
>
> Cheers,
> Chris
>
> [1] http://community.apache.org/apache-extras/faq.html
>
> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> Chris Mattmann, Ph.D.
> Senior Computer Scientist
> NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA
> Office: 171-266B, Mailstop: 171-246
> Email: chris.a.mattm...@nasa.gov
> WWW:   http://sunset.usc.edu/~mattmann/
> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> Adjunct Assistant Professor, Computer Science Department
> University of Southern California, Los Angeles, CA 90089 USA
> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: community-unsubscr...@apache.org
> For additional commands, e-mail: community-h...@apache.org
>

Reply via email to