| Message ID | 20260126190141.2410546-4-laurent.pinchart@ideasonboard.com |
|---|---|
| State | New |
| Headers | show |
| Series |
|
| Related | show |
Hi Laurent, On Mon, 26 Jan 2026 at 19:01, Laurent Pinchart <laurent.pinchart@ideasonboard.com> wrote: > > libcamera has a policy on usage of 3rd party components that has never > been documented. Detail it in the architecture documentation page, with > an explicit description of the licensing requirements. > > Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> > --- > Documentation/libcamera_architecture.rst | 41 +++++++++++++++++------- > 1 file changed, 30 insertions(+), 11 deletions(-) > > diff --git a/Documentation/libcamera_architecture.rst b/Documentation/libcamera_architecture.rst > index 73888e499128..417ecf02c5f3 100644 > --- a/Documentation/libcamera_architecture.rst > +++ b/Documentation/libcamera_architecture.rst > @@ -112,18 +112,19 @@ Image Processing Algorithms > and control hardware image processing based on the parameters supplied by > upper layers, closing the control loop of the ISP. > > - IPAs are loaded as external plugins named IPA Modules. IPA Modules can be part > - of the libcamera code base or provided externally by camera vendors as > - open-source or closed-source components. > + IPAs are loaded as external plugins named IPA Modules. IPA Modules can be > + part of the libcamera code base or provided externally by camera vendors. > + In-tree IPA modules are covered by the same license as the rest of libcamera, > + external IPA modules can be open-source or closed-source. > > - Open source IPA Modules built with libcamera are run in the same process space > - as libcamera. External IPA Modules are run in a separate sandboxed process. In > - either case, they can only interact with libcamera through the API provided by > - the Pipeline Handler. They have a restricted view of the system, with no direct > - access to kernel camera devices, no access to networking APIs, and limited > - access to file systems. All their accesses to image and metadata are mediated > - by dmabuf instances explicitly passed by the Pipeline Handler to the IPA > - Module. > + IPA Modules built with libcamera are run in the same process space as the > + library. External IPA Modules are run in a separate sandboxed process. In > + either case, they can only interact with libcamera through the API provided > + by the Pipeline Handler. They have a restricted view of the system, with no > + direct access to kernel camera devices, no access to networking APIs, and > + limited access to file systems. All their accesses to image and metadata are > + mediated by dmabuf instances explicitly passed by the Pipeline Handler to the > + IPA Module. > > IPA Modules are only required for platforms and devices with an ISP controlled > by the host CPU. Camera sensors which have an integrated ISP are not > @@ -141,3 +142,21 @@ Helpers and Support Classes > self-contained support classes, even if such code is present only once in the > code base, in order to keep the source code clean and easy to read. This > should be the case for instance for plugin management. > + > +Dependencies > +------------ > + > +As a system component, libcamera tries to minimize its dependency on > +third-party libraries. New dependencies are evaluated on a case-by-case basis, > +to balance the value they bring with the impact on distributions. Dependencies > +for optional features must be conditioned by a meson feature option, as usage > +of dependencies based only on auto-detection hinders reproducible builds and > +dependency management for distributions. All dependencies must be compatible > +with the libcamera license. Does this mean that such features must not be gated by the "auto" type of meson option. Currently the RPi NN AWB uses an auto option, but we can easily change to a boolean. > > + > +Dependencies may not be used to load closed-source components from pipeline > +handlers or in-tree IPA modules. This includes GPU shaders or neural network > +models. Usage of closed-source components is permitted in external IPA Modules > +only. Pipeline handlers and in-tree IPA Modules are allowed to use neural > +networks provided that both the model and its training data are available under > +an open-source license compatible with libcamera. How do we advertise where models/training data live? Is putting it in the commit message sufficient? Regards, Naush > -- > Regards, > > Laurent Pinchart >
2026. 01. 27. 10:30 keltezéssel, Naushir Patuck írta: > Hi Laurent, > > On Mon, 26 Jan 2026 at 19:01, Laurent Pinchart > <laurent.pinchart@ideasonboard.com> wrote: >> >> libcamera has a policy on usage of 3rd party components that has never >> been documented. Detail it in the architecture documentation page, with >> an explicit description of the licensing requirements. >> >> Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> >> --- >> Documentation/libcamera_architecture.rst | 41 +++++++++++++++++------- >> 1 file changed, 30 insertions(+), 11 deletions(-) >> >> diff --git a/Documentation/libcamera_architecture.rst b/Documentation/libcamera_architecture.rst >> index 73888e499128..417ecf02c5f3 100644 >> --- a/Documentation/libcamera_architecture.rst >> +++ b/Documentation/libcamera_architecture.rst >> @@ -112,18 +112,19 @@ Image Processing Algorithms >> and control hardware image processing based on the parameters supplied by >> upper layers, closing the control loop of the ISP. >> >> - IPAs are loaded as external plugins named IPA Modules. IPA Modules can be part >> - of the libcamera code base or provided externally by camera vendors as >> - open-source or closed-source components. >> + IPAs are loaded as external plugins named IPA Modules. IPA Modules can be >> + part of the libcamera code base or provided externally by camera vendors. >> + In-tree IPA modules are covered by the same license as the rest of libcamera, >> + external IPA modules can be open-source or closed-source. >> >> - Open source IPA Modules built with libcamera are run in the same process space >> - as libcamera. External IPA Modules are run in a separate sandboxed process. In >> - either case, they can only interact with libcamera through the API provided by >> - the Pipeline Handler. They have a restricted view of the system, with no direct >> - access to kernel camera devices, no access to networking APIs, and limited >> - access to file systems. All their accesses to image and metadata are mediated >> - by dmabuf instances explicitly passed by the Pipeline Handler to the IPA >> - Module. >> + IPA Modules built with libcamera are run in the same process space as the >> + library. External IPA Modules are run in a separate sandboxed process. In >> + either case, they can only interact with libcamera through the API provided >> + by the Pipeline Handler. They have a restricted view of the system, with no >> + direct access to kernel camera devices, no access to networking APIs, and >> + limited access to file systems. All their accesses to image and metadata are >> + mediated by dmabuf instances explicitly passed by the Pipeline Handler to the >> + IPA Module. >> >> IPA Modules are only required for platforms and devices with an ISP controlled >> by the host CPU. Camera sensors which have an integrated ISP are not >> @@ -141,3 +142,21 @@ Helpers and Support Classes >> self-contained support classes, even if such code is present only once in the >> code base, in order to keep the source code clean and easy to read. This >> should be the case for instance for plugin management. >> + >> +Dependencies >> +------------ >> + >> +As a system component, libcamera tries to minimize its dependency on >> +third-party libraries. New dependencies are evaluated on a case-by-case basis, >> +to balance the value they bring with the impact on distributions. Dependencies >> +for optional features must be conditioned by a meson feature option, as usage >> +of dependencies based only on auto-detection hinders reproducible builds and >> +dependency management for distributions. All dependencies must be compatible >> +with the libcamera license. > > Does this mean that such features must not be gated by the "auto" type > of meson option. Currently the RPi NN AWB uses an auto option, but we > can easily change to a boolean. I would think "feature" options with "auto" as default are fine. Distributions can set `auto_features=disabled` on the meson command line and then enable exactly what they wish. I believe the important part is that there is an option to control every optional feature, i.e. essentially no `dependency('xyz', required: false)` anywhere. > >> >> + >> +Dependencies may not be used to load closed-source components from pipeline >> +handlers or in-tree IPA modules. This includes GPU shaders or neural network >> +models. Usage of closed-source components is permitted in external IPA Modules >> +only. Pipeline handlers and in-tree IPA Modules are allowed to use neural >> +networks provided that both the model and its training data are available under >> +an open-source license compatible with libcamera. > > How do we advertise where models/training data live? Is putting it in > the commit message sufficient? > > Regards, > Naush > >> -- >> Regards, >> >> Laurent Pinchart >>
Hi Naush, On Tue, Jan 27, 2026 at 09:30:22AM +0000, Naushir Patuck wrote: > On Mon, 26 Jan 2026 at 19:01, Laurent Pinchart wrote: > > > > libcamera has a policy on usage of 3rd party components that has never > > been documented. Detail it in the architecture documentation page, with > > an explicit description of the licensing requirements. > > > > Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> > > --- > > Documentation/libcamera_architecture.rst | 41 +++++++++++++++++------- > > 1 file changed, 30 insertions(+), 11 deletions(-) > > > > diff --git a/Documentation/libcamera_architecture.rst b/Documentation/libcamera_architecture.rst > > index 73888e499128..417ecf02c5f3 100644 > > --- a/Documentation/libcamera_architecture.rst > > +++ b/Documentation/libcamera_architecture.rst > > @@ -112,18 +112,19 @@ Image Processing Algorithms > > and control hardware image processing based on the parameters supplied by > > upper layers, closing the control loop of the ISP. > > > > - IPAs are loaded as external plugins named IPA Modules. IPA Modules can be part > > - of the libcamera code base or provided externally by camera vendors as > > - open-source or closed-source components. > > + IPAs are loaded as external plugins named IPA Modules. IPA Modules can be > > + part of the libcamera code base or provided externally by camera vendors. > > + In-tree IPA modules are covered by the same license as the rest of libcamera, > > + external IPA modules can be open-source or closed-source. > > > > - Open source IPA Modules built with libcamera are run in the same process space > > - as libcamera. External IPA Modules are run in a separate sandboxed process. In > > - either case, they can only interact with libcamera through the API provided by > > - the Pipeline Handler. They have a restricted view of the system, with no direct > > - access to kernel camera devices, no access to networking APIs, and limited > > - access to file systems. All their accesses to image and metadata are mediated > > - by dmabuf instances explicitly passed by the Pipeline Handler to the IPA > > - Module. > > + IPA Modules built with libcamera are run in the same process space as the > > + library. External IPA Modules are run in a separate sandboxed process. In > > + either case, they can only interact with libcamera through the API provided > > + by the Pipeline Handler. They have a restricted view of the system, with no > > + direct access to kernel camera devices, no access to networking APIs, and > > + limited access to file systems. All their accesses to image and metadata are > > + mediated by dmabuf instances explicitly passed by the Pipeline Handler to the > > + IPA Module. > > > > IPA Modules are only required for platforms and devices with an ISP controlled > > by the host CPU. Camera sensors which have an integrated ISP are not > > @@ -141,3 +142,21 @@ Helpers and Support Classes > > self-contained support classes, even if such code is present only once in the > > code base, in order to keep the source code clean and easy to read. This > > should be the case for instance for plugin management. > > + > > +Dependencies > > +------------ > > + > > +As a system component, libcamera tries to minimize its dependency on > > +third-party libraries. New dependencies are evaluated on a case-by-case basis, > > +to balance the value they bring with the impact on distributions. Dependencies > > +for optional features must be conditioned by a meson feature option, as usage > > +of dependencies based only on auto-detection hinders reproducible builds and > > +dependency management for distributions. All dependencies must be compatible > > +with the libcamera license. > > Does this mean that such features must not be gated by the "auto" type > of meson option. Currently the RPi NN AWB uses an auto option, but we > can easily change to a boolean. You're doing it right. "auto" is the meson "feature" option. It supports forcefully enabling or disabling the feature, which is what we need for reproducible builds. I probably need to clarify the text, what I wanted to explain is that we can't have conditional dependencies that are condtioned only by autodetection, without an option. Would replacing "meson feature option" with "meson option" make it clearer ? > > > > + > > +Dependencies may not be used to load closed-source components from pipeline > > +handlers or in-tree IPA modules. This includes GPU shaders or neural network > > +models. Usage of closed-source components is permitted in external IPA Modules > > +only. Pipeline handlers and in-tree IPA Modules are allowed to use neural > > +networks provided that both the model and its training data are available under > > +an open-source license compatible with libcamera. > > How do we advertise where models/training data live? Is putting it in > the commit message sufficient? That's a very good question :-) I think a comment somewhere in the code would be better than the commit message, as the git history is harder to search. A documentation page would also be an option, if you would like to give more information to people about how to make use of this new feature.
Hi Laurent, On Tue, 27 Jan 2026 at 10:19, Laurent Pinchart <laurent.pinchart@ideasonboard.com> wrote: > > Hi Naush, > > On Tue, Jan 27, 2026 at 09:30:22AM +0000, Naushir Patuck wrote: > > On Mon, 26 Jan 2026 at 19:01, Laurent Pinchart wrote: > > > > > > libcamera has a policy on usage of 3rd party components that has never > > > been documented. Detail it in the architecture documentation page, with > > > an explicit description of the licensing requirements. > > > > > > Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> > > > --- > > > Documentation/libcamera_architecture.rst | 41 +++++++++++++++++------- > > > 1 file changed, 30 insertions(+), 11 deletions(-) > > > > > > diff --git a/Documentation/libcamera_architecture.rst b/Documentation/libcamera_architecture.rst > > > index 73888e499128..417ecf02c5f3 100644 > > > --- a/Documentation/libcamera_architecture.rst > > > +++ b/Documentation/libcamera_architecture.rst > > > @@ -112,18 +112,19 @@ Image Processing Algorithms > > > and control hardware image processing based on the parameters supplied by > > > upper layers, closing the control loop of the ISP. > > > > > > - IPAs are loaded as external plugins named IPA Modules. IPA Modules can be part > > > - of the libcamera code base or provided externally by camera vendors as > > > - open-source or closed-source components. > > > + IPAs are loaded as external plugins named IPA Modules. IPA Modules can be > > > + part of the libcamera code base or provided externally by camera vendors. > > > + In-tree IPA modules are covered by the same license as the rest of libcamera, > > > + external IPA modules can be open-source or closed-source. > > > > > > - Open source IPA Modules built with libcamera are run in the same process space > > > - as libcamera. External IPA Modules are run in a separate sandboxed process. In > > > - either case, they can only interact with libcamera through the API provided by > > > - the Pipeline Handler. They have a restricted view of the system, with no direct > > > - access to kernel camera devices, no access to networking APIs, and limited > > > - access to file systems. All their accesses to image and metadata are mediated > > > - by dmabuf instances explicitly passed by the Pipeline Handler to the IPA > > > - Module. > > > + IPA Modules built with libcamera are run in the same process space as the > > > + library. External IPA Modules are run in a separate sandboxed process. In > > > + either case, they can only interact with libcamera through the API provided > > > + by the Pipeline Handler. They have a restricted view of the system, with no > > > + direct access to kernel camera devices, no access to networking APIs, and > > > + limited access to file systems. All their accesses to image and metadata are > > > + mediated by dmabuf instances explicitly passed by the Pipeline Handler to the > > > + IPA Module. > > > > > > IPA Modules are only required for platforms and devices with an ISP controlled > > > by the host CPU. Camera sensors which have an integrated ISP are not > > > @@ -141,3 +142,21 @@ Helpers and Support Classes > > > self-contained support classes, even if such code is present only once in the > > > code base, in order to keep the source code clean and easy to read. This > > > should be the case for instance for plugin management. > > > + > > > +Dependencies > > > +------------ > > > + > > > +As a system component, libcamera tries to minimize its dependency on > > > +third-party libraries. New dependencies are evaluated on a case-by-case basis, > > > +to balance the value they bring with the impact on distributions. Dependencies > > > +for optional features must be conditioned by a meson feature option, as usage > > > +of dependencies based only on auto-detection hinders reproducible builds and > > > +dependency management for distributions. All dependencies must be compatible > > > +with the libcamera license. > > > > Does this mean that such features must not be gated by the "auto" type > > of meson option. Currently the RPi NN AWB uses an auto option, but we > > can easily change to a boolean. > > You're doing it right. "auto" is the meson "feature" option. It supports > forcefully enabling or disabling the feature, which is what we need for > reproducible builds. I probably need to clarify the text, what I wanted > to explain is that we can't have conditional dependencies that are > condtioned only by autodetection, without an option. > > Would replacing "meson feature option" with "meson option" make it > clearer ? I'd keep your existing wording, it's clear to me now. > > > > > > > + > > > +Dependencies may not be used to load closed-source components from pipeline > > > +handlers or in-tree IPA modules. This includes GPU shaders or neural network > > > +models. Usage of closed-source components is permitted in external IPA Modules > > > +only. Pipeline handlers and in-tree IPA Modules are allowed to use neural > > > +networks provided that both the model and its training data are available under > > > +an open-source license compatible with libcamera. > > > > How do we advertise where models/training data live? Is putting it in > > the commit message sufficient? > > That's a very good question :-) I think a comment somewhere in the code > would be better than the commit message, as the git history is harder to > search. A documentation page would also be an option, if you would like > to give more information to people about how to make use of this new > feature. A comment seems reasonable to me. We can add one in the NN AWB source file before merging. Naush > > -- > Regards, > > Laurent Pinchart
diff --git a/Documentation/libcamera_architecture.rst b/Documentation/libcamera_architecture.rst index 73888e499128..417ecf02c5f3 100644 --- a/Documentation/libcamera_architecture.rst +++ b/Documentation/libcamera_architecture.rst @@ -112,18 +112,19 @@ Image Processing Algorithms and control hardware image processing based on the parameters supplied by upper layers, closing the control loop of the ISP. - IPAs are loaded as external plugins named IPA Modules. IPA Modules can be part - of the libcamera code base or provided externally by camera vendors as - open-source or closed-source components. + IPAs are loaded as external plugins named IPA Modules. IPA Modules can be + part of the libcamera code base or provided externally by camera vendors. + In-tree IPA modules are covered by the same license as the rest of libcamera, + external IPA modules can be open-source or closed-source. - Open source IPA Modules built with libcamera are run in the same process space - as libcamera. External IPA Modules are run in a separate sandboxed process. In - either case, they can only interact with libcamera through the API provided by - the Pipeline Handler. They have a restricted view of the system, with no direct - access to kernel camera devices, no access to networking APIs, and limited - access to file systems. All their accesses to image and metadata are mediated - by dmabuf instances explicitly passed by the Pipeline Handler to the IPA - Module. + IPA Modules built with libcamera are run in the same process space as the + library. External IPA Modules are run in a separate sandboxed process. In + either case, they can only interact with libcamera through the API provided + by the Pipeline Handler. They have a restricted view of the system, with no + direct access to kernel camera devices, no access to networking APIs, and + limited access to file systems. All their accesses to image and metadata are + mediated by dmabuf instances explicitly passed by the Pipeline Handler to the + IPA Module. IPA Modules are only required for platforms and devices with an ISP controlled by the host CPU. Camera sensors which have an integrated ISP are not @@ -141,3 +142,21 @@ Helpers and Support Classes self-contained support classes, even if such code is present only once in the code base, in order to keep the source code clean and easy to read. This should be the case for instance for plugin management. + +Dependencies +------------ + +As a system component, libcamera tries to minimize its dependency on +third-party libraries. New dependencies are evaluated on a case-by-case basis, +to balance the value they bring with the impact on distributions. Dependencies +for optional features must be conditioned by a meson feature option, as usage +of dependencies based only on auto-detection hinders reproducible builds and +dependency management for distributions. All dependencies must be compatible +with the libcamera license. + +Dependencies may not be used to load closed-source components from pipeline +handlers or in-tree IPA modules. This includes GPU shaders or neural network +models. Usage of closed-source components is permitted in external IPA Modules +only. Pipeline handlers and in-tree IPA Modules are allowed to use neural +networks provided that both the model and its training data are available under +an open-source license compatible with libcamera.
libcamera has a policy on usage of 3rd party components that has never been documented. Detail it in the architecture documentation page, with an explicit description of the licensing requirements. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> --- Documentation/libcamera_architecture.rst | 41 +++++++++++++++++------- 1 file changed, 30 insertions(+), 11 deletions(-)