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 > > > > > > > > > > > > > > >
