On Mon, Aug 1, 2016 at 9:37 AM John D. Ament <johndam...@apache.org> wrote:
> I'm -1 until the website issues are resolved.
>
> - Make sure its clear that any existing releases are not apache endorsed.
> - Make sure the website points to resources contained within the ASF, e.g.
> fluo-dev is a bit of an oddity same for zetten.
>
fluo-dev and zetten are supplemental community projects that build on fluo,
to make it easier to use and test. These are the kind of community
extensions we want to encourage around Apache projects, I would think. We
can probably do a better job highlighting these community efforts as
external to ASF, but it'd be a shame if we weren't allowed to link to
them... as they are useful third party efforts which benefit the Apache
Fluo project's community.
> - Make sure that io.fluo is either replaced, or has a ticket to be replaced
> within your pom files. Its still not clear to me why your parent declares
> dependencies on previously released artifacts and why those can't be
> bundled within the release.
>
>
It's not a previously released version of anything which now exists in ASF.
It's just a jar containing some checkstyle and formatter rules we'd like to
use. These rules are non-specific to Fluo, but which happened to be
released under the io.fluo groupId in Maven. Moving these rules over to the
ASF to perform a release of them under the Apache brand would add no value.
The artifactId doesn't even contain "fluo"... just the groupId, which
indicates the entity of its origins, and it's simply a fact that it came
from the "fluo.io" domain ("io.fluo" groupId). I'm not sure it would be
appropriate to transition it to ASF and release it under the Apache brand
simply to conceal this fact.
The question of trademarks and groupIds has come up before (
https://lists.apache.org/thread.html/24c6270458faf64da351027cde5c74e935d6b5760b511b4e2f0c6b98@1388455319@%3Cprivate.accumulo.apache.org%3E),
but in those circumstances, the conflict was much more direct (reuse of the
"org.apache.*" groupId in maven artifacts). I would think that the
"io.fluo" groupId would clearly indicate this is a separate organization,
clearly distinct from Apache. If the simple reuse of the word "fluo" is
enough to trigger a branding issue, then I would imagine things like
"maven-checkstyle-plugin" reusing the word "checkstyle" while it depends on
a 3rd party "checkstyle" artifact would be similarly concerning, as would
all of the 3rd party "X-maven-plugin" artifacts out there which reuse the
brand "maven", even though they aren't ASF projects. Further, there's lots
of third party websites which have ASF project names in their domain name,
twitter handles, etc... and these don't usually raise branding concerns so
long as they aren't misrepresenting themselves as part of, or endorsed by,
the ASF.
> John
>
>
