Hi all: We carefully analyzed the dependency package berkeleydb-je. I think what @Justin Mclean <jus...@classsoftware.com> said is correct: it has no standard license file, no open source code channel, and cannot be downloaded from the central repository. All off all , It does have a problem.
I will restore the WIP label until it is replaced with the new scheme. Thanks all! Goson zhang <gosonzh...@apache.org> 于2021年2月11日周四 下午9:07写道： > Hi all: > > I made the following adjustments according to your suggestions: > > 1. Sorted out and supplemented the LICENSE of each binary dependency > package. > > 2. Delete tubemq-manager and tubemq-web modules related content: > In the process of combing, it is found that tubemq-manager contains a > dependency package of the GNU GPL V2 LICENSE. This version deletes the > module, and then merges it into the official version after finishing the > relevant checks for dependency packages. > Since more than 60 files of tubemq-web module are not authorized by > LICENSE, they will be merged into the mainline version after finishing the > LICENSE information checks of the code and dependent packages. > > 3. Solved the problem of compiling: > When compiling with the mvn compile command, the pom dependency of > tubemq-docker needs to obtain the dependency package of tubemq from the > warehouse instead of locally, so a compilation error occurs; this part > should be a pom problem, and solve the problem when the next version is > released(does not affect the main line). > > 4. LICENSE problem of bdb: > Through everyone's discussion and confirmation, the 7.3.7 version of > berkeleydb-je is authorized under Apache V2 LICENSE, which is explained in > detail in the LICENSE file of TubeMQ; subsequent project evolution will > consider gradually removing this component. > > 5. Modify the contents of the CHANGES.md file and add this modification > item. > > Please see if there are any other problems. If OK, we will launch a new > round of version release. > > Thanks! > > > Goson zhang <gosonzh...@apache.org> 于2021年2月11日周四 下午2:55写道： > >> Ok, thanks Daniel! >> >> >> >> Daniel Widdis <wid...@gmail.com> 于2021年2月11日周四 下午2:10写道： >> >>> To continue to provide clarity: >>> >>> The current version (7.5.11) still has AL2.0 licensing; I just >>> downloaded it to confirm. Any version from 7.3.7 and newer (at this point >>> in time) is an acceptable dependency. >>> >>> If Oracle chooses to change the license again for future releases that >>> could pose a problem, but personally I don't think that's likely. >>> >>> >>> On 2/10/21, 9:58 PM, "Goson zhang" <gosonzh...@apache.org> wrote: >>> >>> 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 >>> >>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org >>> For additional commands, e-mail: general-h...@incubator.apache.org >>> >>>
