Christopher wrote:
On Tue, Aug 2, 2016 at 3:37 PM Josh Elser<[email protected]> wrote:
Christopher wrote:
Okay, so we've been having a long discussion regarding trademarks as the
project transitions from fluo.io to fluo.apache.org on the incubator
list (
https://lists.apache.org/thread.html/69a0c4befd56240ac642c4912e7497ea53720920a459e923f5cf7e91@%3Cgeneral.incubator.apache.org%3E
).
Several issues arose, and Keith, Mike and I have been discussing what we
think is the best plan forward.
What we think is best:
1. Create a branch in the incubator-fluo repo for the resources, and do
an
Apache release of the checkstyle/formatter rules in that resources jar.
+1
2. Update the parent POM to use that resources jar instead of the
previously released io.fluo one.
Is there are reason these resource jars were not included with the
parent pom release?
Not a very good reason. The main reason is that the released artifact
already existed and was suitable. There's also a chicken-egg issue that
makes things a bit annoying doing new releases of the resources object...
because it can't depend on the parent POM. It's also versioned separately.
But mostly, there was no immediate need for a new one any time soon when
the current one works fine.
So would you think a new repo is appropriate for this? Would you want to
just use the same Git repo that the parent pom exists in (put two
separate maven projects inside)?
As far as tech goes, I don't think this is super critical, but the
feelings aspect of it might require more immediate action.
5. Open a discussion on [email protected] 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.
As discussed on the thread, some of the projects are not appropriate for
ASF, and were not part of the original donation. I agree with your
assessment (and I also made the argument) that "fluo-io" can be properly
distinguished from "Apache Fluo" and the ASF, with some effort. That would
be the position we'd bring to trademarks@. But also, if we give up the
domain "fluo.io", either by donation to ASF or by letting it lapse, it will
not longer make sense for the GitHub org to be called "fluo-io", and it
might make more sense to rename it to something like "fluo-tools".
Regardless, if it has "fluo" in the name, we'll want to get it cleared as
an approved use of the trademark.
Yeah, I'm not sure what to recommend for maintaining such an org. Let's
make sure to tread very carefully. Because the maintainers/creators of
these tools that were not brought to Apache are the PPMC now, this has
the potential to be misconstrued.
Would it be out of line for me to suggest that for the projects
currently at github.com/fluo-io:
* Specifically decree those with no interest to maintain as such
* Make a plan to bring others into the Apache umbrella
I know this is a bit totalitarian, but I'm not sure how to avoid further
drama over an organization of fluo-related software projects, maintained
by a subset of the PPMC.
Regardless, VP of trademarks has a much heavier weight of opinion than I
do. A healthy discussion sounds great.
6. Complete the PODLINGNAMESEARCH, so all this effort to protect the
"Fluo"
trademark isn't done in vain.
+1 this isn't that hard to do either. Feel free to ask for help/guidance.
Please help. :)
But seriously, we did create the JIRA issue, but have not yet contributed
to documenting the fact-finding there yet.
https://issues.apache.org/jira/browse/PODLINGNAMESEARCH-109
:) ok. Let's break this one out. I think we should get the other items
here done and then we can come back to the namesearch after (it's good
to get it done early, but not as important as the other branding concerns).
I'll go ahead and get started on item 1, because I think that should be
relatively easy to do.
