<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On 17 Aug 2022, at 11:15, Henning Westerholt <<a href="mailto:hw@gilawa.com" class="">hw@gilawa.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class="">Hello Olle,<br class=""><br class="">yes, it should be finalized in a shorter period and not going into multiple release cycles.<br class="">If we have done it, it should be also probably added to the contribution guidelines e.g., for new modules.<br class=""></div></div></blockquote>Right<br class=""><blockquote type="cite" class=""><div class=""><div class=""><br class="">Not sure what kind of tools you are referring to. For the addition to the source code, this could be probably done with some scripting and sed or similar tools.<br class=""></div></div></blockquote>Tools that generate an overview of the product. I’ll read on here. But tagging source is a starting point.<br class=""><blockquote type="cite" class=""><div class=""><div class=""><br class="">I looked again to the SPDX standard. This is actually quite extensive and there are many fields that could be added.<br class="">Example: <a href="https://github.com/spdx/spdx-spec/blob/development/v2.2.2/examples/SPDXTagExample-v2.2.spdx" class="">https://github.com/spdx/spdx-spec/blob/development/v2.2.2/examples/SPDXTagExample-v2.2.spdx</a><br class=""></div></div></blockquote>I think that’s the generated product, the SBOM, not what you add to the source code. The tag from the source is</div><div>here:</div><div><span style="caret-color: rgb(36, 41, 47); color: rgb(36, 41, 47); font-family: ui-monospace, SFMono-Regular, "SF Mono", Menlo, Consolas, "Liberation Mono", monospace; font-size: 12px; white-space: pre; background-color: rgb(255, 255, 255);" class="">LicenseInfoInFile: GPL-2.0-only</span></div><div><font color="#24292f" face="ui-monospace, SFMono-Regular, SF Mono, Menlo, Consolas, Liberation Mono, monospace" class=""><span style="caret-color: rgb(36, 41, 47); font-size: 12px; white-space: pre; background-color: rgb(255, 255, 255);" class=""><br class=""></span></font></div><div><font color="#24292f" face="ui-monospace, SFMono-Regular, SF Mono, Menlo, Consolas, Liberation Mono, monospace" class=""><span style="caret-color: rgb(36, 41, 47); font-size: 12px; white-space: pre; background-color: rgb(255, 255, 255);" class="">(row 49 in that document)<br class=""></span></font><blockquote type="cite" class=""><div class=""><div class=""><br class="">Additionally, it can be added as tags (as above), XML, JSON etc.. <br class="">This has grown quite a lot since I have last investigated it.<br class=""><br class="">You were not proposing to add multiple tags to the source code files, right? If yes, this should be discussed in a larger round, maybe in some online developer meeting or similar.<br class="">It would be difficult to maintain, if we compare e.g., to the Doxygen topic which was done for many modules, but not all parts of the code.<br class=""></div></div></blockquote>No, I was just proposing to add a single tag alongside the license text.</div><div><br class=""></div><div>There are tools for scanning files and creating base info for debian packages, if I understand it right. At some point, I suspect it will happen.</div><div><br class=""></div><div>We have an issue there with files under different licenses, but a combined license for the running software, but that is another issue to handle when that problem comes up.</div><div><br class=""></div><div>/O<br class=""><br class=""><blockquote type="cite" class=""><div class=""><div class="">Cheers,<br class=""><br class="">Henning<br class=""><br class="">-- <br class="">Henning Westerholt – <a href="https://skalatan.de/blog/" class="">https://skalatan.de/blog/</a><br class="">Kamailio services – <a href="https://gilawa.com" class="">https://gilawa.com</a><br class=""><br class="">-----Original Message-----<br class="">From: Olle E. Johansson <<a href="mailto:oej@edvina.net" class="">oej@edvina.net</a>> <br class="">Sent: Tuesday, August 16, 2022 3:44 PM<br class="">To: Henning Westerholt <<a href="mailto:hw@gilawa.com" class="">hw@gilawa.com</a>><br class="">Cc: Kamailio (SER) - Development Mailing List <<a href="mailto:sr-dev@lists.kamailio.org" class="">sr-dev@lists.kamailio.org</a>><br class="">Subject: Re: [sr-dev] SPDX identifiers in source code<br class=""><br class=""><br class=""><br class=""><blockquote type="cite" class="">On 16 Aug 2022, at 14:53, Henning Westerholt <<a href="mailto:hw@gilawa.com" class="">hw@gilawa.com</a>> wrote:<br class=""><br class="">Hello,<br class=""><br class="">I have nothing against it, just it should be done for the whole project (i.e., all files) in the repository if somebody decides to do it.<br class="">Otherwise, we will end up with partial information, which might be misleading to some people rely on the identifier.<br class=""></blockquote>Absolutely. It will affect all files but we don’t have to mark them all overnight, but can do it in a period between releases.<br class=""><blockquote type="cite" class=""><br class="">I know a bit about the SPDX standard, it sounds reasonable for me and its only one line added per file, so not much overhead.<br class=""></blockquote>Great. Are you aware of any good tools that parse and produce some interesting output?<br class=""><br class="">Thank you for the feedback.<br class="">/O<br class=""><blockquote type="cite" class=""><br class="">Cheers,<br class=""><br class="">Henning<br class=""><br class="">-----Original Message-----<br class="">From: sr-dev <<a href="mailto:sr-dev-bounces@lists.kamailio.org" class="">sr-dev-bounces@lists.kamailio.org</a>> On Behalf Of Olle E. Johansson<br class="">Sent: Tuesday, August 16, 2022 10:43 AM<br class="">To: Kamailio (SER) - Development Mailing List <<a href="mailto:sr-dev@lists.kamailio.org" class="">sr-dev@lists.kamailio.org</a>><br class="">Subject: [sr-dev] SPDX identifiers in source code<br class=""><br class="">Hi!<br class=""><br class="">SBOM - Software Bill of Materials - often comes up in discussions in my projects. There’s a new working group in the IETF working on it and several other standardization bodies.<br class=""><br class="">A starting point is identification of the license in each source code file with a parseable SPDX identifier. <br class=""><br class="">- Is anyone against adding that to our source code?<br class="">- Would it be beneficial for packaging in any way?<br class=""><br class="">I think at some point in the future, a SBOM list in <pick format> will be included in packages, in order to be able to produce a SBOM for the container or the machine.<br class=""><br class="">As we have multiple licenses in the source code it’s important to mark every file correctly.<br class=""><br class="">I can start experimenting with http_client, then work myself around, if the dev community doesn’t scream and argue that it’s a bad thing (TM).<br class=""><br class="">Read more here<br class="">- SPDX - a linux foundation project ans ISO standard - <a href="https://spdx.dev" class="">https://spdx.dev</a><br class="">- Tags in source code - <a href="https://spdx.dev/ids/" class="">https://spdx.dev/ids/</a><br class=""><br class="">Cheers,<br class="">/O<br class="">_______________________________________________<br class="">Kamailio (SER) - Development Mailing List <a href="mailto:sr-dev@lists.kamailio.org" class="">sr-dev@lists.kamailio.org</a> <a href="https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev" class="">https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev</a><br class=""></blockquote><br class=""></div></div></blockquote></div><br class=""></body></html>