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

Reply via email to