Hi tison,
Thanks a lot for following up with VP Brand and sharing the detailed reply
— great news that fluss-extensions / fluss-contrib can be used by a
third-party organization!
My understanding of the key requirements:
1. The organization must be clearly identified as an unofficial
collection — not only in the name, but also with obvious text at both the
organization level and in each repository (e.g., near the start of the
README):
- "This is a set of unofficial extensions / add-ons for Apache Fluss"
- "These extensions / add-ons are neither provided by nor endorsed by
the Apache Fluss project"
- Trademark attribution for Apache Fluss, Apache, and the logo
2. If any extension is not ALv2 licensed, that should be clearly noted
as well.
3. For individual project names, forms like "Fluss-ABC" are not allowed;
"ABC plugin for Fluss" is the preferred style. If we want a
project-specific convention (e.g., "Fluss <something> Extension", similar
to Maven), the PMC can introduce one — after review by trademarks@.
4. Since fluss-extensions turns out to be acceptable, the alternative
names we reserved earlier (lakestreams, otter-stream, lake-stream) are no
longer needed. And a small win: we already reserved fluss-extensions just
in case.
Thanks again to tison for driving this, and to Mark for the thorough
guidance!
Best,
Yang
tison <[email protected]> 于2026年8月3日周一 19:48写道：
> After a discussion with VP Brand at [1] we agreed that either
> `fluss-extensions` or `fluss-contrib` can be used by a third-party
> organization, provided that it is clearly identified as an unofficial
> collection.
>
> [1] https://lists.apache.org/thread/2yocq8ofo714yfcb55jxyd8ofld0x57c
>
> The full reply is as follows:
>
> > User contributed extensions and add-ons is an important part of the OSS
> community and one that I would expect ASF projects to want to encourage.
> >
> > Generally, the name of an organisation or a repository using an ASF
> project name is not a concern providing that it is clear that what is being
> provided is not being provided by the ASF and is not endorsed by the ASF.
> The use of "contrib" is well-known within the OSS community and is a good
> way of indicating that. Assuming no other issues, a Github organisation
> name of, for example, "tomact-contrib" would be acceptable.
> >
> > The requirement for it to be clear that what is being provided is not
> being provided by the ASF and is not endorsed by the ASF goes beyond the
> organisation and repository name. At both organisation level and repository
> level I would expect to see obvious text (e.g. near the start of the README
> or equivalent) along the lines of:
> > - this is a set of unofficial extensions / add-ons for Apache ABC
> > - these extensions / add-ons are neither provided by nor endorsed by the
> Apache ABC project
> > - Apache Tomcat, Tomcat, Apache, and the Apache Tomcat logo are either
> registered trademarks or trademarks of the Apache Software Foundation.
> >
> > If some extensions / add-ons are not ALv2 licensed then I'd expect to see
> that clearly noted as well.
> >
> > Where things can start to get difficult is project names. The policy [1]
> > is clear that names like:
> > - Tomcat-Redis clustering
> > - Tomcat-OAuth authenticator are not allowed.
> >
> > Projects are able to relax that policy in specific circumstances. For
> example, Maven allows all Maven plugins to be named Maven ABC Plugin. Such
> exemptions must be:
> > - clearly defined
> > - limited in scope
> > - use a form of naming that is clear the product is an add-on / extension
> >
> > A general exemption of "You can call your add-on Tomcat ABC" would not be
> allowed. This is because widespread permitted usage of that form of name
> undermines the ASF's ability protect not just the Tomcat mark but all ASF
> marks and there are lots of usages (e.g. "BigCo Tomcat") we absolutely do
> not want to allow because of the harm it causes to the project community
> when BigCo makes it look like Tomcat is their product rather than ours.
> >
> > Taking the examples above, I would rather they were named
> > - Clustering plugin for Tomcat and Redis
> > - Authentication plugin for OAuth with Tomcat or similar.
> >
> > If a project has an active contribution community (like Maven Plugins) or
> wants to try and encourage one then the project can introduce a similar
> naming convention for extensions / add-ons for their project. I would
> strongly advise the project to get any proposed naming convention reviewed
> by trademarks@ before introducing it.
> >
> > Taking the Tomcat example, the PMC could opt for "Tomcat <something>
> Extension" or similar.
> >
> > In terms of existing unofficial contrib organisations and projects, I
> suspect many of them will be using products names that are not consistent
> with ASF policy nor any project level policy for naming add-ons /
> extensions. I would recommend the following approach:
> > - Decide if the project wants to create a project specific permitted form
> for naming add-ons / extensions. If yes, get that put in place first.
> > - Work through the plugins starting with the most widely used / actively
> maintained ones first and the least used / unmaintained ones last.
> > - Ask them to plan to migrate to the correct naming convention but give
> them plenty of time. To be clear it is *only* the product name that needs
> to change. Repository names, file names etc. can almost certainly stay the
> same.
> > - There is a point where a plugin is unmaintained or rarely used that it
> isn't worth pursuing a name change. That is fine and is a decision the PMC
> is usually best placed to make. trademarks@ can provide advice if
> required.
> >
> > There is a balance to strike here. We want to encourage the community to
> flourish. Building extensions, plugins and add-ons is part of that and we
> don't want to make things difficult for those folks that have created such
> products. At the same time, we do need to protect out trademarks because if
> we don't it becomes much harder / impossible to stop misuse of our
> trademarks that cause the project real harm.
> >
> > Happy to provide more specific advice on a case by case basis if
> required.
> >
> > Mark
> >
> > [1] https://www.apache.org/foundation/marks/#products
>
> You can read this reply by replace "Tomcat" with "Fluss". If there is any
> further questions, any PMC member can email to [email protected] for
> explaination, you can have [email protected] so the reply would be
> visible for all PMC memebrs.
>
> [email protected] is a private list so I can't simply keep
> [email protected] and [email protected] both in cc.
>
> Best,
> tison.
>
>
> Yang Wang <[email protected]> 于2026年7月23日周四 17:52写道：
>
> > Hi tison,
> >
> > Thanks for digging into this — I went through the marks FAQ and the
> > services naming policy as well. The FAQ covers product and service
> naming,
> > and the services policy (v0.4) lays out a permission process for
> > third-party uses that could confuse consumers. But neither one really
> > speaks to the GitHub-org-for-ecosystem-projects scenario directly — it
> sits
> > somewhere between those two categories, and I genuinely don't see
> explicit
> > guidance for it.
> >
> > So this is indeed a gray area. I did find some precedents showing this
> has
> > been done, but I agree with you — that's not the same as formal, proper
> > authorization. I'll put both the discussion and the VOTE on hold for now,
> > and we can confirm how to move forward once you've talked with VP Brand
> and
> > there's some formal policy or written guidance.
> >
> > Thanks,
> > Yang
> >
> > tison <[email protected]> 于2026年7月23日周四 15:41写道：
> >
> > > > That said, I don't think the qualified-name approach itself is the
> > issue.
> > > > flink-extended [1] is an existing, community-sanctioned precedent: it
> > >
> > > The fact that another TLP does something doesn't mean it's the proper
> way
> > > to do. There is also datafusion-contrib [1] that may have similar
> naming
> > > issue.
> > >
> > > [1] https://github.com/datafusion-contrib
> > >
> > > You can consider the alternatives I suggested above. I'll discuss these
> > > cases with VP Brand to see if we can produce some policies or
> > > explanations to guide this kind of usage.
> > >
> > > Best,
> > > tison.
> > >
> > >
> > > Yang Wang <[email protected]> 于2026年7月23日周四 08:55写道：
> > >
> > > > Hi tison,
> > > >
> > > > Thanks for flagging the trademark angle — the caution is well taken,
> > and
> > > I
> > > > agree a bare "fluss" org name wouldn't work.
> > > >
> > > > That said, I don't think the qualified-name approach itself is the
> > issue.
> > > > flink-extended [1] is an existing, community-sanctioned precedent: it
> > > > describes itself as "a neutral place to host the code of ecosystem
> > > projects
> > > > that extend the capability of the Apache Flink," doing essentially
> what
> > > > we're proposing. So a qualified name like "fluss-extended" seems
> > already
> > > > proven to be legitimate and within community norms — with PMC
> approval
> > > > being the key piece.
> > > >
> > > > So my reading is that the main thing we need here is the PMC's
> buy-in,
> > > > rather than rethinking the model itself. Of course, happy to hear if
> > > others
> > > > see it differently.
> > > >
> > > > Thanks,
> > > > Yang
> > > >
> > > > [1] https://github.com/flink-extended
> > > >
> > > > tison <[email protected]> 于2026年7月20日周一 16:37写道：
> > > >
> > > > > I remember that third-party contrib organizations shall not use the
> > > same
> > > > > name of "fluss", which is a documented trademark policy in [1]
> > > > >
> > > > > [1] https://www.apache.org/foundation/marks/guide
> > > > >
> > > > > This is why SkyWalking's contrib org is called SkyAPM [2] and why
> the
> > > > > ResillenceDB shuts down their previous orgs [3].
> > > > >
> > > > > [2] https://github.com/SkyAPM
> > > > > [3]
> https://lists.apache.org/thread/gdx2rz2byfxtr0ftqy1tcmvl47gphcro
> > > > >
> > > > > So, for the situation we are here, I suggest:
> > > > >
> > > > > 1. We may directly create new repos for contrib code. This would
> > handle
> > > > the
> > > > > IP clearance issue beforehand as well.
> > > > > 2. Or, if there is a reason we must not hold the code within the
> ASF,
> > > > use a
> > > > > distinguished name for the org.
> > > > >
> > > > > Best,
> > > > > tison.
> > > > >
> > > > >
> > > > > Muhammet Orazov via dev <[email protected]> 于2026年7月20日周一
> > 16:01写道：
> > > > >
> > > > > > Hello Yang,
> > > > > >
> > > > > > Thanks taking of this!
> > > > > >
> > > > > > All looks fine from my side, +1.
> > > > > >
> > > > > > We'd like to start with Fluss K8s operator on this organization,
> > but
> > > > > > definitely donate back to ASF on later stages.
> > > > > >
> > > > > > Best,
> > > > > > Muhammet Orazov
> > > > > >
> > > > >
> > > >
> > >
> >
>
