Maybe I am showing my age here but Open has never been about access to source code (which from my experience is rarely open in terms of accessibility & extensibility) or for that matter FREE which is how it is equated today by most newer comers.
For software to be Open means (in the classical sense) it has been explicitly designed to be extended & reused in different contexts and environments via integration (extensions) and plugins. It can also mean it offers the ability to have multiple implementations which again is supported today by OpenCore via service provider plugin points. Whilst it is pretty easy to make software open sourced you will find it is an incredibly hard task to make it Open.
During the summer I spent 6 weeks in the valley trying to get backing from major players around a standardization of OpenCore with the current API elements (not package naming) serving as the basis for such a standard that would go beyond Java itself. I have also met up with various cloud computing vendors trying to get greater awareness of the need for cost information to be exchanged at service entry points which we refer to metering points. Questions and answers regarding license are brought up in the tech talk I gave at Google HQ during this time. Note that licensing is not just about free in terms of financial liability. You won't believe how hard this actually is especially as many are less open than what is projected in the media and community. I would like to see our metering (Probes) & Metrics API's make it into all runtimes including Java which is why I have discussed our technology with all major JVM vendors. Hopefully they will do the right thing and move on this before other platforms do.
OpenCore is open (accessible) in many ways including the wealth of information we have published on its data formats and API usage - all public without any community login. I doubt you will find as much information in any comparable open source project.
Parts of the license that ships with the distribution relate to a commercial licensing of OpenCore or its derivative products - JXInsight and Metrica.
Both the metering & metrics runtimes will measure & collect information for up to 30-45 mins which should be suffice for most developer needs. I rarely find anyone will to wait longer for the results of a benchmark unless its in a test or pre-production environment.
The goal here is for OpenCore's API (or its standardized version) to be implemented in part by platforms and runtimes or other third parties, to be extended by runtimes in terms of registration of meters, to be used solely by management agents and tools for metering & metric collection, to be used by customers to demarcate activities (probes) and possibly register higher level business metrics and meters (kpi's). I think if we could end the constant re-invent a new stop watch class or straw man performance management solution we would have increased the productivity of many teams around the world.
I am not interesting in taking what is today and making that the defacto standard just because we made it free for someone like yourself. The goal here is to increase awareness of our vision, CARS (cost/consumption aware runtimes & services), and to possibly refine it with contribution from customers, management vendors and platform vendors. I personally would like to see the whole execution stack all the way down to the networking layer being metered enabled with each layer defining standard activities (probes), meters (execution context consumption counters) and metrics (typically derived from metering).
I believe in innovation & competition which is why OpenCore is versatile, extensible, highly configurable, and carefully designs in terms of interface contracts to support diverse implementations underneath.
