Yes, restricting the use of its version number in the project is still a relatively passive solution: if we want to upgrade the version, but the corresponding version authorization is adjusted, our project still has restrictions.
The biggest dependency of replacing this component lies in the active/standby switching function: currently we are not considering expanding its scope of use, and we are analyzing the new active/standby switching scheme, and want to temporarily maintain the existing method before completing this task, until the real-time active/standby switching is provided. I plan to explain this problem in detail in the supplementary binary dependency package LICENSE, until the solution is adjusted to completely solve it. See if this is OK? Justin Mclean <jus...@classsoftware.com> 于2021年2月11日周四 下午1:46写道： > Hi, > > > 1. Can we meet the requirements of this open source agreement by > > restricting the version of this component to 7.X.Y? > > For Berkeley DB JE (Java Edition), this component itself is TubeMQ to > store > > metadata and switch between active and standby. It is not very deep, but > it > > need to take some time to adjust. > > Possibly if 7.X.Y is clearly Apache licensed, however as time goes on you > may need to move to a newer version (due to security concerns) and what > will be become an issue. > > > 2. Or have to switch to other components? > > If so, for this release, do I restore the "WIP" label to complete the > > version release first? > > Then adjust the implementation plan later, and finally remove this > > component in the final version. > > That would be a valid path forward. > > Thanks, > Justin
