 Hello So this talk is an introduction to the tools available in build route for compliance with the open source licensing I'm Luca Ceresoli. I love open source and or my daily job I design embedded Linux system at AMM sport line for motor sport applications So first thing let's have a super quick introduction to build route Build route is an embedded Linux build system. So you want to design an embedded device running Linux on it you have to put together lots of packages for it to work and so this is a complex task and There are tools to help you which are the build systems build route is one of them. It takes a lot of packages from from the sources it extract them patches to fix problems Compile them cross-compile them and the output product is images that are able to be run on the embedded device So in the end what happens is the end user would receive Those open source packages in a binary form Another thing it produces is host tools meaning tools that are not really meant to run on the device But they are natively compiled for the host Such as for example image creation utilities Let's have a quick look at how build route works. It is based on two main pillars. One is the make Program to actually run the build but before that you configure it using the kconfig configuration system from the Linux kernel. So You can do the usual things like make help build route has a list of default configurations for well-known boards. So let's load one configuration When it is loaded you're ready to build but first we can do make menu config and Modify something we have a lot of parameters to tweak. Let's just have a look at one We can add packages to be on the target on the root file system So we can add an audio and video application We can add a test as a test in the help we can see it depends on some other libraries So it will pull in other dependencies in our build Let's save an exit and then we can run the build by simply typing make so it will start fetching the sources Extracting and building everything. So while it builds we can go on with an introduction to open source licensing Open source doesn't mean you grab something from the internet. You use it your your K You have rights and obligations with open source So Most of the open source software falls into two main categories Those with the permissive license and those with the copy left license Permissive license including the BSD Licenses MIT x11 Allow you to use red modify and redistribute the source code. It may redistribute the program And they require you to provide the license text to your users So in this way that the original author is acknowledged You can provide it either in the print and manual or in the program output or in the display or somewhere But you have to provide it The other family is the copy left family The GPL Licenses are the most famous representative in this category You have pretty much the same rights to use modify and redistribute. You also have to provide the license text But additionally you have to provide the source code for the software if you modified it You have to provide the modified version. So you have an extra application which makes those two family very different Of course, this is an oversimplifications There are many more details There are different variations and different versions of each license and there are licenses that are incompatible with each other So you have to take care of not using two incompatible packages in the same program and When looking for a program you wonder what license it has Beware sometimes the websites have incorrect or incomplete information The only authoritative place for the license text is the source code So have a look in the source code if you want to be absolutely sure even your build system might be wrong So in that case you're welcome to send a patch and fix the information in the build system So in the practical In a practical scenario, what do you have to do to be compliant? First you have to as I said to provide the license text for all of the packages that acquire it In any form that is suitable, but you also should store the source code archives for all the packages You don't have to provide them beforehand differently from the license text, but you have to provide a written offer to Release the source code to anybody who asked so it's a good idea to have saved them beforehand When you're sure you have them By the GNU GPL awarding you have to also include the scripts used to control compilation and installation Which is the make files to make list or configure a C whatever, but if you're using a build system, it is also Something that controls the compilation. So this is a bit debated, but According to at least the official interpretation of the build developers the build system is included in the scripts You should provide Okay, so What does build route offer you to help in this bit complex task? It offers some tools in addition to building the images and host tools build route Also can generate so-called legal info This include the license text and the source code that Have to be released in some form to the end user and also some additional information and material And so we can have a look with a simple demo Actually, it's very simple. You just have to run the command make legal info and so let's have a look the builders finished So we have our images here already and we can do make legal Info and now we'll do it collect all of the material from all the packages You don't need to have Completed a build to run it you can run it anyway just to investigate What licenses would I use if I I use that package? So the result is in output legal info Can you read? Can you read the text? Okay So first so we have read me file which tells you this is what I have saved for you With a brief description it might have warnings to say I was unable to save these and that Then you have well that the build route The build route configuration which has been used to to run the build so of course it affects the final result So it is something you might want to release for helping in reducing the build Then you have Something may be more interesting the manifest file. It is a CSV file that Basically lists all of the packages with name version license and license files And also the source archive name and the the website where it has been downloaded from Finally, it lost those of these the recursive dependencies. So for for example for the package a test which we enable manually We can see it depends on al salim which is released under these licenses And it also depends on leave ev which has these other licenses So we can easily check that if for example our application depends on a ton of libraries with dependencies And we can see if there are incompatible license here There is a similar file saved that called host manifest which is pretty much the same but for host packages So it has exactly the same structure then you can look at the Licenses directory which has a subdirectory for each package with the license files containing license text Which is what you should provide to the user and also the sources Also here a subdirectory for each package with the tarball and any patches that have been applied to the package With the series file. So you have pretty much Close to all the material that you need here And so it makes it easy for you to do the rest you you should post process that to to be compliant But all the material has been collected here Okay That's it and now This is how it works Will do does no magic to understand what package what license a package is the sense under It will not be quite feasible, but it It uses a simple mechanism where the the package Maintainer or or the person who writes the package has to insert this info Let's take the VLC package as an example here are two variables VLC license so this is the the name of the licenses and In this case, there are two licenses in for different parts of the software or It is dual dual License and then VLC license files So the name of the files that contain that text and that should be copied into the output directory There are also hashes for these files so that should the Version the the license change in a future version of the package the package will not build anymore And so you will notice and maybe it's really a license change and you have to update the above fields You probably have your own proprietary application on top of open source libraries in your embedded device and in this case you You can handle it by adding license equals proprietary or my company proprietary license whatever and you probably want to set redistribute equal no meaning the Source code will not be saved into the output directory So you do not risk to release your proprietary software accidentally Okay Finally keep in mind that If you use the override source tier or local site method of build root the source code will not be saved those two features are useful when developing your software and They're it's okay if you use them, but I would suggest not to use them when releasing But release with traditional methods because you run the risk to not save some important material that you have to release Okay Finally, well, there is a very special case where some packages have a source variable that points to a Tarball which does not contain the source code, but the but a binary and This is only applies with External pre-built to chains actually so it's a very special corner case But in that case there is an additional variable actual source that can point to a different Tarball Which is released at time by to chain author where all the source code is you probably don't need that but you should be aware Okay, so as you have seen build root has a tool to help you in license compliance It does not do everything for example. It cannot block you from using packages with an undesired license or It cannot block you if you use it incompatible licenses But it provides basically the raw the raw data that you can quite easily use to you can maybe first process that to To check for any issues in your licensing The tool is pretty simple to use so there is really no reason to not use it Okay, there are a few links here if you want additional details on this feature the manual Has all the details so you you can click on those links Everything is well documented in manual Also, I suggest having a view at the video for this talk by Paul Barker It is about license compliance with the October but actually most of the talk is build system agnostic And so it's a more detailed version of what I have said about open source licensing in general Okay, that's all We have full almost two minutes any question Sorry, I either it was very clear or everybody was sleeping. I'm sure it was very clear Thank you The languages No, you mean if you have some Yeah, the question is is there any limitation about the programming languages used? No, if you have a package using I don't know raster Whatever language that is supported by build route no problem licensing is not really about The technical aspects of programming languages, so it's quite orthogonal. Okay. Once again. Thank you. Thank you