Integration of a top notch typesystem for models with highspeed reflection into the very foundations of quarkus

[tryptamic]

We are a team of 3 to 4 people that want to get in touch with the quarkus core team in order to inform about our invention regarding a normalized typsystem for models that effectively addresses the requirements of distributed computing. After a long period of proprietary development of this technology we finally went open source under the LGPLv3 license. The long proprietary phase prevented visibility and comunity impact. This should now change and we approach quarkus to make impact.

We could imagine that the quarkus technology could profit a lot from integrating the technology into its foundations to combine quarkus' fast bootstrapping approach with top notch data and service processing based on this new typesystem approach. For the sake of a great future, let's get in touch.

The following PDF documents currently best address the question of relevance for quarkus:

• Introduction to the GenericModel Invention (PDF)
• Relevance for Distributed Computing (PDF)

Our github organization is hiconic-os

[maxandersen]

duplicate of #38492

[Sanne]

Please note that I don't think the LGPLv3 license would be compatible with Quarkus - any chance you could evaluate a different license?

[tryptamic]

I am not a license expert but LGPLv3 is free to use for any purpose including commercial. It is different from GPL which has these special limitations. Do you have any concrete aspect that this license is blocking? Thank you.

[Sanne]

I'm not a lawyer and this is not advice, (don't consider me an expert) but see this:

• https://www.apache.org/licenses/GPL-compatibility.html

To be fair I don't even personally agree with the interpretation of the ASF, but that's their position and that's going to be enough to make many users (and potential users) concerned about it.

Additionally, LGPLv3 is not compatible with libraries under LGPLv2, which means no software can mix the two libraries - unfortunately for the choice of LGPLv3, there are many popular libraries licensed under LGPLv2 so that's bound to be a problem.

Personally I quite like the spirit of LGPLv3, but it's a problem in practice as many will consider it unacceptable.

[tryptamic]

Are you really sure you talk about LGPL? You referenced a document about GPL but we use the LESSER GPL also refered to as LGPL. The LGPL license incrementally builds on the GPL license by removing/changing rules. If you really think that the LESSER GPL is what you addressed I will deeper look into that. Also note that due to its icremental nature the LGPL license comes with both license texts which confuses GitHub to let it look as if these two licenses would be both active. So linking libraries with different licenses to LGPLv3 should not be a problem.

[Sanne]

What I personally think of this is not really important... what is important is that many users will have such concerns as there is no clarity and/or they will have no precedent to look at. Sometimes even a lawyer will not be able to give you a definite answer on such details - sometimes they will but the lawyer of a different company might have a different opinion, or simply prefer to err on the safe side.

For many of our projects the license choice was ASL2 because it's well knownm, it's widely used, and everyone can easily be reassured that it won't be a problem in their company / their project.

[tryptamic]

Thank you very much for all of your input. I started a discussion in our group to shift the license model and the group seems open to do that. We are investigating the possibility and the required steps to do that properly. I keep you posted on this. Our intent is to remove obstacles as they are discovered and adapt where possible and required in order to make the existing value visible.