Can you be clear on what you mean by "has no standard license file" and "no open source code channel"?
I started at this download page [1]. On that page near the top is a link to "more details" on licensing, which points to [2]. The link there for "Open source license for Berkeley DB Java Edition" points to [3] which is the Apache License, 2.0. >From [1], I downloaded the file Berkeley DB Java Edition je-7.5.11.zip and extracted it. It contains a LICENSE file exactly matching the license shown in [3], the Apache License, 2.0. The extracted zip file also contains a complete copy of the source code. You are correct that it is not published on Maven, but is that a requirement for a dependency? The only "obstacle" to downloading is that one has to create a (free) Oracle account to download it. Is this a disqualifying factor? I am unclear on why this is not permitted as a dependency for an Apache project. [1] - https://www.oracle.com/database/technologies/related/berkeleydb-downloads.html [2] - https://www.oracle.com/database/technologies/related/berkeleydb/berkeleydb-licensing.html [3] - https://www.oracle.com/downloads/licenses/berkeleydb-jeoslicense.html On Thu, Feb 18, 2021 at 3:31 AM Goson zhang <gosonzh...@apache.org> wrote: > 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 > >>> > >>> > -- Dan Widdis