incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher <ctubb...@apache.org>
Subject Re: [VOTE] Fluo Parent POM 1-incubating (rc2)
Date Mon, 01 Aug 2016 23:36:56 GMT
I also wish to point out that the FluoProposal (
http://wiki.apache.org/incubator/FluoProposal) explicitly included an
intent/wish/request to continue using the Fluo logo (which includes the
name) on Fluo's historical sites. That proposal was accepted by the IPMC
(albeit without an explicit judgment on that issue). While the proposal did
not explicitly mention the domain name concerns, it did mention the
continued existence of "historical sites" after acceptance, sites whose
names could reasonably be expected to contain the Fluo name. I think this
is important in determining to what extent it should be considered fair and
reasonable to use the word "Fluo" on "fluo.io".

At no point in the proposal or vote discussions for Fluo was it mentioned
that we'd have to remove or transfer control of the fluo.io domain, in
order to be compliant with ASF trademark policies upon acceptance into
Incubator, even though it was clear at the time that 1) the domain existed
and 2) hosted projects which would transfer to the ASF and projects which
would not.

Taking this into account, and in conjunction with our intent to fix both
websites to reduce confusion, I hope that we can find a resolution which
does not require a name change, but can leave both fluo.apache.org and
fluo.io coexisting.

I think our immediate, actionable plan should be to:

1. Remove redirect from fluo.io to fluo.apache.org
2. Place content on fluo.io which:
  2.a) links to Apache Fluo
  2.b) states that Fluo is a trademark of Apache
  2.c) clarifies that Fluo.io is not affiliated or endorsed by the ASF
  2.d) is primarily focused on the community tools it hosts, and not Apache
Fluo
3. Ensure content on fluo.apache.org is updated to:
  3.a) remove pre-apache release or clearly document them.
  3.b) remove any implication that Fluo depends on any software at fluo.io
  3.c) ensure no dependency on external documentation at fluo.io
4. Standardize on a different publicly available checkstyle and formatter
ruleset than the io.fluo:resources ones (maybe?)

If we're going to expend this effort, it would be nice to get some
assurances that this will be sufficient to resolve branding concerns, or if
there are additional steps short of changing the domain names, which we can
take to resolve these issues.

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