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