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

Reply via email to