> From: Bruce Richardson [mailto:bruce.richard...@intel.com] > Sent: Friday, 17 November 2023 10.52 > > On Fri, Nov 17, 2023 at 09:27:02AM +0100, Morten Brørup wrote: > > > From: Jerin Jacob [mailto:jerinjac...@gmail.com] > > > Sent: Friday, 17 November 2023 05.34 > > > > > > On Thu, Sep 28, 2023 at 11:10 AM <jer...@marvell.com> wrote: > > > > > > > > From: Jerin Jacob <jer...@marvell.com> > > > > > > > > Define qualification criteria for external library > > > > based on a techboard meeting minutes [1] and past > > > > learnings from mailing list discussion. > > > > > > > > [1] > > > > http://mails.dpdk.org/archives/dev/2019-June/135847.html > > > > > > > > Signed-off-by: Jerin Jacob <jer...@marvell.com> > > > > > > Ping for review and/or merge. > > > > > > > > > > --- > > > > v2: > > > > - Added "Meson build integration" and "Code readability" > sections. > > > > > > > > doc/guides/contributing/index.rst | 1 + > > > > .../contributing/library_dependency.rst | 23 > > > +++++++++++++++++++ > > > > 2 files changed, 24 insertions(+) > > > > create mode 100644 > doc/guides/contributing/library_dependency.rst > > > > > > > > diff --git a/doc/guides/contributing/index.rst > > > b/doc/guides/contributing/index.rst > > > > index dcb9b1fbf0..e5a8c2b0a3 100644 > > > > --- a/doc/guides/contributing/index.rst > > > > +++ b/doc/guides/contributing/index.rst > > > > @@ -15,6 +15,7 @@ Contributor's Guidelines > > > > documentation > > > > unit_test > > > > new_library > > > > + library_dependency > > > > patches > > > > vulnerability > > > > stable > > > > diff --git a/doc/guides/contributing/library_dependency.rst > > > b/doc/guides/contributing/library_dependency.rst > > > > new file mode 100644 > > > > index 0000000000..687a3b6cef > > > > --- /dev/null > > > > +++ b/doc/guides/contributing/library_dependency.rst > > > > @@ -0,0 +1,23 @@ > > > > +.. SPDX-License-Identifier: BSD-3-Clause > > > > + Copyright(c) 2023 Marvell. > > > > + > > > > +Library dependency > > > > +================== > > > > + > > > > +This document defines the qualification criteria for external > > > libraries that may be > > > > +used as dependencies in DPDK drivers or libraries. > > > > + > > > > +- **Free availability**: The library must be freely available to > > > build in either source or binary > > > > + form, with a preference for source form. > > > > Suggest adding: > > > > - **Free use and distribution license**: The library must be freely > available to use and distribute without any attached conditions. > > > > We must require a BSD-like license, to ensure that DPDK as a whole > (including 3rd party libraries) remains BSD licensed, and can be used > in commercial (closed source) applications. > > > I think the situation is a bit more complex. Firstly, we need to ensure > that there are no license incompatibilities. Beyond that though, the > importance of the library will depend on how strict we are going to be > about open-source licensing etc.
My point about the license was not related to source code availability, it was related to conditions for use and distribution of the library. The license needs to allow unrestricted and unconditional use and distribution, like the BSD license does. In principle, this requirement only applies to binary form; we don't need to be able to distribute the source code of external libraries, regardless if it is open source or NDA-protected "view only" source code or other restricted access source code (e.g. Microsoft's Shared Source Initiative). > > For example, for a particular driver - nic, crypto, whatever - we have > in > the past allowed linking against non-opensource libraries in order to > build > that component. That (thankfully) has not caused us any serious issues > to > date, and I don't think we should change things by completely > disallowing > it in future. > > On the other hand, a library that becomes key for building more than > just a > driver or rarely used library, e.g. one that adds key functionality to > EAL, > would be held to a much higher standard. In that case we likely would > look > for an open-source, appropriately licensed, version. I agree that the required degree of open source principles should vary with DPDK's dependency of the library. We can be more lenient with hardware PMDs, where end users ultimately can choose another hardware vendor if a dependent library is unacceptable for the end user. There is no doubt we should keep allowing opaque binary BLOBs for hardware, such as on-board firmware and FPGA images.
