The code in question, specifically the YARD runtime, has a development history dating back to June 2022, which predates the migration of the codebase to the Apache Software Foundation. During that migration, other parts of the same effort, such as the YARD tooling, were brought into the KIE Tools repository, which is already under the ASF. This suggests the YARD runtime was part of the broader initiative and was overlooked during the move.
By recognizing and incorporating it now, we establish consistency in the codebase and eliminate ambiguity regarding ownership. Treating this code as ASF property aligns it with related components that are already within the foundation, helping us reduce risk, not increase it. Leaving it outside ASF, despite its connection to existing ASF-hosted code, could raise concerns about unclear ownership, especially as development continues and the code gains visibility. This is where potential legal concerns could arise, particularly regarding trademarks or misperceptions about what is or is not part of ASF. For context, the PMC plays a crucial role in monitoring and safeguarding the use of trademarks and ensuring the integrity of ASF projects. These responsibilities are outlined in more detail here: - https://www.apache.org/foundation/marks/responsibility.html - https://www.apache.org/foundation/marks/ I think my suggestion aligns with that spirit: to ensure proper attribution by treating the code as a missing piece of the original migration. - Alex On Fri, Jul 4, 2025 at 9:57 AM Gabriele Cardosi <gabriele.card...@gmail.com> wrote: > > HI Alex, thanks for your explanation. > Could you please help me understand better what you mean with: > "This helps prevent potential legal concerns related to > ownership, trademarks, and similar issues." > > The reason I'm asking is because, reading your explanation, my conclusion > would be exactly the other way around, so the above is the actual > discrimination. > > Thanks > > Best regards > > Gabriele > > > Il giorno ven 4 lug 2025 alle ore 15:42 Alex Porcelli <a...@porcelli.me> ha > scritto: > > > Thank you, Gabriele, for engaging and helping to evaluate the overall > > situation. > > > > Based on the repository history, with commits dating back to June > > 2022, this piece of code was likely overlooked during the migration to > > Apache. This seems plausible, given that other components, such as the > > YARD tooling, have already been moved into the KIE Tools repository. > > The available evidence suggests this code is effectively part of what > > should now be considered Apache Software Foundation property. > > > > Regarding the future of this component, we can reassess its value and > > determine whether to evolve it or remove it. However, for now, I > > recommend we treat it as an overlooked part of the original codebase > > migration. This helps prevent potential legal concerns related to > > ownership, trademarks, and similar issues. > > > > - > > Alex > > > > On Fri, Jul 4, 2025 at 9:28 AM Gabriele Cardosi > > <gabriele.card...@gmail.com> wrote: > > > > > > Hi Tony, many thanks for your answers, make sense! > > > > > > The only thing probably I've not been very clear about is the "driver" or > > > business value, or whatever. > > > > > > I understand that currently the implementation is targeting scorecard, > > but > > > my question was about the "need" of this other implementation, since, > > IINW, > > > we already have a couple of them, or more, around (I may be wrong on > > that, > > > of course). > > > > > > Am I clear ? Does this make sense ? > > > > > > And, my personal POV, I would prefer to not include something that, > > > eventually, would need to be removed, since, as we all know, removing > > stuff > > > is much harder than introducing them, for different reasons.... > > > > > > > > > > > > Il giorno ven 4 lug 2025 alle ore 15:19 Toni Rikkola <rikk...@apache.org > > > > > > ha scritto: > > > > > > > Thank you for interest. Like I said this is a separate module that is > > easy > > > > to pick out if needed later. > > > > > > > > 1. > > > > Yes this is another way for defining and grouping rules. > > > > > > > > 2. > > > > org.kie.j2cl is actually something I need to remove. It comes from our > > > > j2cl dependencies that are mainly used by tooling. It will be replaced > > with > > > > pure Java approach. This is was used so that the model-to-YAML-to-model > > > > functionality could be the same and reused in the J2CL client side. > > > > > > > > 3. > > > > Right now the driver is scorecards, but this can also be used for data > > > > aggregation. In the simple cases it could be merging one or more > > YAML/JSON > > > > files to a new file using rule logic. > > > > > > > > This is right now on alpha stage and for that reason experimental. This > > > > does mean that in case it is not useful in future use the bar to > > remove it > > > > should be low. > > > > > > > > Toni > > > > > > > > On 2025/07/04 12:47:47 Gabriele Cardosi wrote: > > > > > Hi Tony, > > > > > this seems an interesting feature, indeed. > > > > > Anyway, as I mentioned in the past for other similar improvements, I > > > > think > > > > > the main concern should be the evaluation of pros/cons, since we are > > > > > already struggling to maintain the codebase as it is and this new > > > > > implementation, inevitably, would increase the surface. > > > > > First of all I'm looking at the code here [1], and I take for granted > > > > that > > > > > all that code would be incorporated inside the drools repository: > > please > > > > > correct me if I'm wrong. > > > > > 1. IIUC, this is first of all another way to define rules to be > > invoked > > > > by > > > > > the rule engine: is that true, or the execution is delegated to a > > > > > completely different engine ? > > > > > 2. I see dependencies like -> org.kie.j2cl.tools; I have no idea > > what's > > > > > inside, but the name suggest something on the tool/ui side (j2cl, > > tools) > > > > > and, if that is true, such kind of dependencies should not get in the > > > > > "backend" side > > > > > 3. What is the concrete driver for this initiative? I mean, what use > > > > > case/issue currently exists that would be solved by that > > implementation ? > > > > > > > > > > Beside minor technical issues or doubts, the main problem from my > > POV is > > > > in > > > > > the overall approach we have to our codebase after the Apache > > migration. > > > > > For different reasons, we have to be extremely careful about the > > > > stability > > > > > and maintenance of our projects, and indeed we should start removing > > > > > dead/unused/unmaintained code for our sake. > > > > > So, I think we should have a sort of "experimental" or similar branch > > > > > (unfortunately, "incubator" name has already been taken), so that on > > one > > > > > side we may promote innovation, as this proposal seems to point to, > > but > > > > on > > > > > the other side without increasing the burden of maintain the code > > with > > > > > something that is not necessary. > > > > > > > > > > > > > > > I want to enforce the point that I have nothing against the idea by > > > > itself, > > > > > but I'm only concerned about our overall context. > > > > > > > > > > Many thanks > > > > > > > > > > Best > > > > > > > > > > Gabriele > > > > > > > > > > ---- > > > > > 1 https://github.com/kubesmarts/yard > > > > > > > > > > Il giorno ven 4 lug 2025 alle ore 14:19 Toni Rikkola < > > rikk...@apache.org > > > > > > > > > > ha scritto: > > > > > > > > > > > Hello, > > > > > > > > > > > > Summary: > > > > > > > > > > > > When we moved to KIE, YARD was still in experimental mode. We did > > move > > > > > > the editors and validation tooling (in kie-tools ATM), but runtime > > was > > > > > > left behind. I previously proposed adding YARD in, but it was seen > > as a > > > > > > risk for the up coming releases. > > > > > > > > > > > > Assignee: Me, Toni Rikkola > > > > > > > > > > > > Target Release: ASAP > > > > > > > > > > > > Scope: > > > > > > > > > > > > This will go into the incubator-kie-drools repository as a > > separated > > > > > > unit. No dependencies to any other part of KIE will be added. > > > > > > > > > > > > Description: > > > > > > > > > > > > YARD. Yet Another Rule Definition is best explained in the > > README.MD > > > > > > with pictures. It is a work in progress project where the current > > main > > > > > > driver is the decision table feature. > > > > > > > > > > > > https://github.com/kubesmarts/yard > > > > > > > > > > > > Testing: Unit tests. Human validation is not relevant at this point > > > > > > since the project is in Alpha stage. > > > > > > > > > > > > Dependencies: Drools > > > > > > > > > > > > > > > > > > Thank you > > > > > > > > > > > > Toni Rikkola > > > > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > > > > To unsubscribe, e-mail: dev-unsubscr...@kie.apache.org > > > > > > For additional commands, e-mail: dev-h...@kie.apache.org > > > > > > > > > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > > To unsubscribe, e-mail: dev-unsubscr...@kie.apache.org > > > > For additional commands, e-mail: dev-h...@kie.apache.org > > > > > > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: dev-unsubscr...@kie.apache.org > > For additional commands, e-mail: dev-h...@kie.apache.org > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@kie.apache.org For additional commands, e-mail: dev-h...@kie.apache.org
