Hi all! I also talked to Sanne, who said they might blog about it in the next few days. I understand that it will be compelling for the Apache Legal team to grasp the details and know that the process is ongoing and not as simple as it sounds.
On Wed, Jan 8, 2025 at 10:20 AM Alex Porcelli <[email protected]> wrote: > Thank you Kris for the update, and Francisco for the detailed information. > > I'll reach out to IPMC and share the updated information available, > and make sure that we are following this progress closely. > > Hopefully we won't need to make any drastic changes in the short term, > as Sanne timeline seems reasonable. > > On Wed, Jan 8, 2025 at 10:03 AM Kris Verlaenen <[email protected]> wrote: > > > > I reached out to Sanne, the hibernate lead, and he replied that they are > > optimistic to finish the relicensing within two months, but can't > guarantee > > that timeframe won't slip. We should add some time for that version being > > merged into Quarkus (they have some branches for this already but still > > could take some time) and it being available in a Quarkus LTS version. > > > > I think there's a preference to try and continue to leverage JPA in the > > data index (to avoid having to write similar code ourselves). And to see > > if we can still support hibernate as a potential implementation. It seems > > that we should be able to do that in the mid-term future (due to the > > relicensing). Do we need a different short-term strategy or is it an > > option to wait a little longer? > > > > Thx, > > Kris > > > > On Wed, Jan 8, 2025 at 11:13 AM Francisco Javier Tirado Sarti < > > [email protected]> wrote: > > > > > Hi Alex, > > > > > > Reverting back to JDBC, which I actually suggested in the past > > > <https://github.com/apache/incubator-kie-kogito-apps/issues/2009> > (note my > > > unfounded optimism about the licensing issue when closing the proposal > > > ;)), is not a good technical idea for data-index and data-audit. In > fact, > > > the data-index use case (which is the one I'm more familiar with), > which > > > consists of a lot of random updates over a relatively small relational > > > model, is one where JPA cache and automatic generation of SQL update > > > statements really excels. Doing the same using JDBC, if we want to > achieve > > > the same performance, will be a really challenging exercise, because we > > > will need to replicate the Hibernate logic to execute just the sql > > > statements that are really needed because of that random change in the > > > model. This is pretty tricky and is a work that is currently done > > > automatically by JPA. > > > Also, since the SQL statements slightly diverge between DBs (note that > in > > > runtimes, where the relational model is trivial, just a big table, and > not > > > queries are performed, this is not an issue, but it certainly will be > for > > > data-index, where the relational model is not trivial and queries are > > > random) , we will actually need to redesign the whole stack of classes > to > > > ensure we can easily change statements between different dbs. Current > class > > > hierarchy does not easily allow that. For example, to use custom > functions > > > to enable querying Process.variables (which is a jsonb column in > postgres > > > and hence it can be queries using custom postgresql operators) I had > to use > > > a Quarkus trick (annotating one bean with @DefaultBean in common > module and > > > override it in postgres module). This smells fishy and if we are > planning > > > to control SQL per db (which, again, we need if we do not use JPA), we > will > > > need a different class hierarchy. > > > In practice, it means to redevelop almost 30% of the data-index code > and > > > execute all the performance testing again. > > > Therefore, unless we are 100% certain that Hibernate is not going to be > > > ASLv2 compatible in one year, I will wait. > > > > > > > > > On Wed, Jan 8, 2025 at 1:00 AM Alex Porcelli <[email protected]> > wrote: > > > > > > > As Jason has pointed out, the IPMC has already stated their position > > > > regarding LGPL, and the rules are clear. I wanted to share my > thoughts > > > > on the possible paths forward: > > > > > > > > - Use OpenJPA: While this would address the licensing issue, it > > > > introduces uncertainty around Quarkus deployment because Hibernate is > > > > the only officially supported JPA provider in Quarkus. > > > > > > > > - Continue with Hibernate: Even though Hibernate might eventually > > > > become ASLv2-compatible, it could be a long time before that version > > > > is integrated into Quarkus and is considered production-ready. > > > > > > > > Given these points, another option might be reverting to plain JDBC. > > > > Although this involves some extra initial work, it should be fully > > > > supported by both Quarkus and SpringBoot, which could remove a > > > > significant blocker with IPMC and help us move toward graduation. > > > > > > > > - > > > > Alex > > > > > > > > On Tue, Jan 7, 2025 at 12:10 PM Jason Porter <[email protected] > > > > > > wrote: > > > > > > > > > > Until they actually change the license over to ASLv2, I seriously > doubt > > > > they’ll let us continue to ship with it. > > > > > > > > > > If we’re not using any of the hibernate specific APIs, I see very > > > little > > > > reason for us not to use OpenJPA for the dependencies, then allow > users > > > to > > > > decide which JPA implementation they want to use. I’m sure we’ll > need to > > > do > > > > a fair amount of testing though to make sure this doesn’t break > things. > > > > > > > > > > -- > > > > > Jason Porter > > > > > Software Engineer > > > > > He/Him/His > > > > > > > > > > IBM > > > > > > > > > > > > > > > From: Francisco Javier Tirado Sarti <[email protected]> > > > > > Date: Tuesday, January 7, 2025 at 04:55 > > > > > To: [email protected] <[email protected]> > > > > > Subject: [EXTERNAL] [DISCUSS] Hibernate usage > > > > > Hi all, > > > > > I feel the discussion we are having here > > > > > https://github.com/apache/incubator-kie-issues/issues/1685 , > actually > > > > > belongs to that list. > > > > > > > > > > On summary, we narrow the issue to two choices: > > > > > > > > > > 1) Replace Hibernate with OpenJPA, as was done, kind of > prematurely in > > > my > > > > > opinion (because this should be a broad KIE choice, not per > > > subcomponent > > > > > one) , in Drools repo. > > > > > 2) Raise a legal issue to Apache so we can distribute Hibernate > (based > > > on > > > > > the fact that eventually the Hibernate license will be Apache > > > compliant) > > > > > > > > > > I'm fine with 1), but I feel we should also vote on that one. > > > > > > > > > > Kind regards and happy new year. > > > > > > > > --------------------------------------------------------------------- > > > > To unsubscribe, e-mail: [email protected] > > > > For additional commands, e-mail: [email protected] > > > > > > > > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
