fluo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher <ctubb...@apache.org>
Subject Re: [DISCUSS] Trademark discussions and plan
Date Tue, 02 Aug 2016 22:40:25 GMT
On Tue, Aug 2, 2016 at 6:22 PM Josh Elser <josh.elser@gmail.com> wrote:

>
>
> Keith Turner wrote:
> >>> 5. Open a discussion ontrademarks@apache.org  to determine whether the
> >>> >>  GitHub organization "fluo-io" should be renamed, and what would
be
> an
> >>> >>  acceptable name for a GitHub organization containing fluo-related
> 3rd
> >>> >>  party
> >>> >>  projects. Also determine whether it is acceptable to use the
> trademark for
> >>> >>  fluo-related extensions repository names (eg. "fluo-stress" and
> >>> >>  "fluo-quickstart").
> >> >
> >> >
> >> >  My feeling is that with proper distinction that "fluo-io" is not
> affiliated
> >> >  with "Apache Fluo (incubating)" and the ASF but are related software
> >> >  projects would be fine. Admittedly, I'm not sure the reasoning behind
> >> >  wanting to keep them separate (was there a reason these were not
> included in
> >> >  the original donation?) and bringing them under the ASF umbrella
> would make
> >> >  sense to me.
> >
> > Some of the reasons we didn't contribute these projects are the
> following.
> >
> >   * Uncertain about future of these projects.
> >   * No plans to release any of them
> >   * Zetten uses Ansible which is GPL
> >
> > Maybe for the examples we could create a new fluo-examples repo in
> Apache land?
> >
>
> Ah, ok, Zetten might be difficult (at least take concern). However,
> you're not bundling Ansible, right? I'm not sure if this is a gray area
> if you're just creating scripts that use Ansible (which is GPL). I'm not
> 100% if this is within the ability to do.
>
>
Regardless of whether it's okay (pretty sure it's not, though, unless there
are alternatives which can also satisfy the dependency which are not GPL),
the lack of certainty about the future of that supplemental effort is not
something we'd want to place upon the shoulders of an Apache PMC. It's not
something we're prepared to support as part of an Apache project.



> Do you know, Billie?
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message