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
>>
>>
