1.. SPDX-License-Identifier: CC-BY-SA-2.0-UK 2 3***************************************** 4The Yocto Project Development Environment 5***************************************** 6 7This chapter takes a look at the Yocto Project development environment. 8The chapter provides Yocto Project Development environment concepts that 9help you understand how work is accomplished in an open source 10environment, which is very different as compared to work accomplished in 11a closed, proprietary environment. 12 13Specifically, this chapter addresses open source philosophy, source 14repositories, workflows, Git, and licensing. 15 16Open Source Philosophy 17====================== 18 19Open source philosophy is characterized by software development directed 20by peer production and collaboration through an active community of 21developers. Contrast this to the more standard centralized development 22models used by commercial software companies where a finite set of 23developers produces a product for sale using a defined set of procedures 24that ultimately result in an end product whose architecture and source 25material are closed to the public. 26 27Open source projects conceptually have differing concurrent agendas, 28approaches, and production. These facets of the development process can 29come from anyone in the public (community) who has a stake in the 30software project. The open source environment contains new copyright, 31licensing, domain, and consumer issues that differ from the more 32traditional development environment. In an open source environment, the 33end product, source material, and documentation are all available to the 34public at no cost. 35 36A benchmark example of an open source project is the Linux kernel, which 37was initially conceived and created by Finnish computer science student 38Linus Torvalds in 1991. Conversely, a good example of a non-open source 39project is the Windows family of operating systems developed by 40Microsoft Corporation. 41 42Wikipedia has a good :wikipedia:`historical description of the Open Source 43Philosophy <Open_source>`. You can also find helpful information on how 44to participate in the Linux Community 45`here <https://www.kernel.org/doc/html/latest/process/index.html>`__. 46 47The Development Host 48==================== 49 50A development host or :term:`Build Host` is key to 51using the Yocto Project. Because the goal of the Yocto Project is to 52develop images or applications that run on embedded hardware, 53development of those images and applications generally takes place on a 54system not intended to run the software --- the development host. 55 56You need to set up a development host in order to use it with the Yocto 57Project. Most find that it is best to have a native Linux machine 58function as the development host. However, it is possible to use a 59system that does not run Linux as its operating system as your 60development host. When you have a Mac or Windows-based system, you can 61set it up as the development host by using 62`CROPS <https://github.com/crops/poky-container>`__, which leverages 63`Docker Containers <https://www.docker.com/>`__. Once you take the steps 64to set up a CROPS machine, you effectively have access to a shell 65environment that is similar to what you see when using a Linux-based 66development host. For the steps needed to set up a system using CROPS, 67see the 68":ref:`dev-manual/start:setting up to use cross platforms (crops)`" 69section in 70the Yocto Project Development Tasks Manual. 71 72If your development host is going to be a system that runs a Linux 73distribution, you must still take steps to prepare the system 74for use with the Yocto Project. You need to be sure that the Linux 75distribution on the system is one that supports the Yocto Project. You 76also need to be sure that the correct set of host packages are installed 77that allow development using the Yocto Project. For the steps needed to 78set up a development host that runs Linux, see the 79":ref:`dev-manual/start:setting up a native linux host`" 80section in the Yocto Project Development Tasks Manual. 81 82Once your development host is set up to use the Yocto Project, there 83are several ways of working in the Yocto Project environment: 84 85- *Command Lines, BitBake, and Shells:* Traditional development in the 86 Yocto Project involves using the :term:`OpenEmbedded Build System`, 87 which uses 88 BitBake, in a command-line environment from a shell on your 89 development host. You can accomplish this from a host that is a 90 native Linux machine or from a host that has been set up with CROPS. 91 Either way, you create, modify, and build images and applications all 92 within a shell-based environment using components and tools available 93 through your Linux distribution and the Yocto Project. 94 95 For a general flow of the build procedures, see the 96 ":ref:`dev-manual/building:building a simple image`" 97 section in the Yocto Project Development Tasks Manual. 98 99- *Board Support Package (BSP) Development:* Development of BSPs 100 involves using the Yocto Project to create and test layers that allow 101 easy development of images and applications targeted for specific 102 hardware. To development BSPs, you need to take some additional steps 103 beyond what was described in setting up a development host. 104 105 The :doc:`/bsp-guide/index` provides BSP-related development 106 information. For specifics on development host preparation, see the 107 ":ref:`bsp-guide/bsp:preparing your build host to work with bsp layers`" 108 section in the Yocto Project Board Support Package (BSP) Developer's 109 Guide. 110 111- *Kernel Development:* If you are going to be developing kernels using 112 the Yocto Project you likely will be using ``devtool``. A workflow 113 using ``devtool`` makes kernel development quicker by reducing 114 iteration cycle times. 115 116 The :doc:`/kernel-dev/index` provides kernel-related 117 development information. For specifics on development host 118 preparation, see the 119 ":ref:`kernel-dev/common:preparing the build host to work on the kernel`" 120 section in the Yocto Project Linux Kernel Development Manual. 121 122- *Using Toaster:* The other Yocto Project development method that 123 involves an interface that effectively puts the Yocto Project into 124 the background is Toaster. Toaster provides an interface to the 125 OpenEmbedded build system. The interface enables you to configure and 126 run your builds. Information about builds is collected and stored in 127 a database. You can use Toaster to configure and start builds on 128 multiple remote build servers. 129 130 For steps that show you how to set up your development host to use 131 Toaster and on how to use Toaster in general, see the 132 :doc:`/toaster-manual/index`. 133 134Yocto Project Source Repositories 135================================= 136 137The Yocto Project team maintains complete source repositories for all 138Yocto Project files at :yocto_git:`/`. This web-based source 139code browser is organized into categories by function such as IDE 140Plugins, Matchbox, Poky, Yocto Linux Kernel, and so forth. From the 141interface, you can click on any particular item in the "Name" column and 142see the URL at the bottom of the page that you need to clone a Git 143repository for that particular item. Having a local Git repository of 144the :term:`Source Directory`, which 145is usually named "poky", allows you to make changes, contribute to the 146history, and ultimately enhance the Yocto Project's tools, Board Support 147Packages, and so forth. 148 149For any supported release of Yocto Project, you can also go to the 150:yocto_home:`Yocto Project Website <>` and select the "DOWNLOADS" 151item from the "SOFTWARE" menu and get a released tarball of the ``poky`` 152repository, any supported BSP tarball, or Yocto Project tools. Unpacking 153these tarballs gives you a snapshot of the released files. 154 155.. note:: 156 157 - The recommended method for setting up the Yocto Project 158 :term:`Source Directory` and the files 159 for supported BSPs (e.g., ``meta-intel``) is to use 160 :ref:`overview-manual/development-environment:git` 161 to create a local copy of the upstream repositories. 162 163 - Be sure to always work in matching branches for both the selected 164 BSP repository and the Source Directory (i.e. ``poky``) 165 repository. For example, if you have checked out the "&DISTRO_NAME_NO_CAP;" 166 branch of ``poky`` and you are going to use ``meta-intel``, be 167 sure to checkout the "&DISTRO_NAME_NO_CAP;" branch of ``meta-intel``. 168 169In summary, here is where you can get the project files needed for 170development: 171 172- :yocto_git:`Source Repositories: <>` This area contains Poky, Yocto 173 documentation, metadata layers, and Linux kernel. You can create local 174 copies of Git repositories for each of these areas. 175 176 .. image:: figures/source-repos.png 177 :width: 100% 178 179 For steps on how to view and access these upstream Git repositories, 180 see the ":ref:`dev-manual/start:accessing source repositories`" 181 Section in the Yocto Project Development Tasks Manual. 182 183- :yocto_dl:`Yocto release archives: </releases/yocto>` This is where you can 184 download tarballs corresponding to each Yocto Project release. Downloading 185 and extracting these files does not produce a local copy of a Git repository 186 but rather a snapshot corresponding to a particular release. 187 188- :yocto_home:`DOWNLOADS page </software-overview/downloads/>`: 189 The :yocto_home:`Yocto Project website <>` includes a "DOWNLOADS" page accessible 190 through the "SOFTWARE" menu that allows you to download any Yocto 191 Project release, tool, and Board Support Package (BSP) in tarball 192 form. The hyperlinks point to the tarballs under 193 :yocto_dl:`/releases/yocto/`. 194 195 .. image:: figures/yp-download.png 196 :width: 100% 197 198 For steps on how to use the "DOWNLOADS" page, see the 199 ":ref:`dev-manual/start:using the downloads page`" 200 section in the Yocto Project Development Tasks Manual. 201 202Git Workflows and the Yocto Project 203=================================== 204 205Developing using the Yocto Project likely requires the use of 206:ref:`overview-manual/development-environment:git`. 207Git is a free, open source distributed version control 208system used as part of many collaborative design environments. This 209section provides workflow concepts using the Yocto Project and Git. In 210particular, the information covers basic practices that describe roles 211and actions in a collaborative development environment. 212 213.. note:: 214 215 If you are familiar with this type of development environment, you 216 might not want to read this section. 217 218The Yocto Project files are maintained using Git in "branches" whose Git 219histories track every change and whose structures provide branches for 220all diverging functionality. Although there is no need to use Git, many 221open source projects do so. 222 223For the Yocto Project, a key individual called the "maintainer" is 224responsible for the integrity of the development branch of a given Git 225repository. The development branch is the "upstream" repository from which 226final or most recent builds of a project occur. The maintainer is 227responsible for accepting changes from other developers and for 228organizing the underlying branch structure to reflect release strategies 229and so forth. 230 231.. note:: 232 233 For information on finding out who is responsible for (maintains) a 234 particular area of code in the Yocto Project, see the 235 ":ref:`dev-manual/changes:submitting a change to the yocto project`" 236 section of the Yocto Project Development Tasks Manual. 237 238The Yocto Project ``poky`` Git repository also has an upstream 239contribution Git repository named ``poky-contrib``. You can see all the 240branches in this repository using the web interface of the 241:yocto_git:`Source Repositories <>` organized within the "Poky Support" 242area. These branches hold changes (commits) to the project that have 243been submitted or committed by the Yocto Project development team and by 244community members who contribute to the project. The maintainer 245determines if the changes are qualified to be moved from the "contrib" 246branches into the "master" branch of the Git repository. 247 248Developers (including contributing community members) create and 249maintain cloned repositories of upstream branches. The cloned 250repositories are local to their development platforms and are used to 251develop changes. When a developer is satisfied with a particular feature 252or change, they "push" the change to the appropriate "contrib" 253repository. 254 255Developers are responsible for keeping their local repository up-to-date 256with whatever upstream branch they are working against. They are also 257responsible for straightening out any conflicts that might arise within 258files that are being worked on simultaneously by more than one person. 259All this work is done locally on the development host before anything is 260pushed to a "contrib" area and examined at the maintainer's level. 261 262There is a somewhat formal method by which developers commit changes and 263push them into the "contrib" area and subsequently request that the 264maintainer include them into an upstream branch. This process is called 265"submitting a patch" or "submitting a change." For information on 266submitting patches and changes, see the 267":ref:`dev-manual/changes:submitting a change to the yocto project`" 268section in the Yocto Project Development Tasks Manual. 269 270In summary, there is a single point of entry for changes into the 271development branch of the Git repository, which is controlled by the 272project's maintainer. A set of developers independently 273develop, test, and submit changes to "contrib" areas for the maintainer 274to examine. The maintainer then chooses which changes are going to 275become a permanent part of the project. 276 277.. image:: svg/git-workflow.* 278 :width: 100% 279 280While each development environment is unique, there are some best 281practices or methods that help development run smoothly. The following 282list describes some of these practices. For more information about Git 283workflows, see the workflow topics in the `Git Community 284Book <https://book.git-scm.com>`__. 285 286- *Make Small Changes:* It is best to keep the changes you commit small 287 as compared to bundling many disparate changes into a single commit. 288 This practice not only keeps things manageable but also allows the 289 maintainer to more easily include or refuse changes. 290 291- *Make Complete Changes:* It is also good practice to leave the 292 repository in a state that allows you to still successfully build 293 your project. In other words, do not commit half of a feature, then 294 add the other half as a separate, later commit. Each commit should 295 take you from one buildable project state to another buildable state. 296 297- *Use Branches Liberally:* It is very easy to create, use, and delete 298 local branches in your working Git repository on the development 299 host. You can name these branches anything you like. It is helpful to 300 give them names associated with the particular feature or change on 301 which you are working. Once you are done with a feature or change and 302 have merged it into your local development branch, simply discard the 303 temporary branch. 304 305- *Merge Changes:* The ``git merge`` command allows you to take the 306 changes from one branch and fold them into another branch. This 307 process is especially helpful when more than a single developer might 308 be working on different parts of the same feature. Merging changes 309 also automatically identifies any collisions or "conflicts" that 310 might happen as a result of the same lines of code being altered by 311 two different developers. 312 313- *Manage Branches:* Because branches are easy to use, you should use a 314 system where branches indicate varying levels of code readiness. For 315 example, you can have a "work" branch to develop in, a "test" branch 316 where the code or change is tested, a "stage" branch where changes 317 are ready to be committed, and so forth. As your project develops, 318 you can merge code across the branches to reflect ever-increasing 319 stable states of the development. 320 321- *Use Push and Pull:* The push-pull workflow is based on the concept 322 of developers "pushing" local commits to a remote repository, which 323 is usually a contribution repository. This workflow is also based on 324 developers "pulling" known states of the project down into their 325 local development repositories. The workflow easily allows you to 326 pull changes submitted by other developers from the upstream 327 repository into your work area ensuring that you have the most recent 328 software on which to develop. The Yocto Project has two scripts named 329 ``create-pull-request`` and ``send-pull-request`` that ship with the 330 release to facilitate this workflow. You can find these scripts in 331 the ``scripts`` folder of the 332 :term:`Source Directory`. For information 333 on how to use these scripts, see the 334 ":ref:`dev-manual/changes:using scripts to push a change upstream and request a pull`" 335 section in the Yocto Project Development Tasks Manual. 336 337- *Patch Workflow:* This workflow allows you to notify the maintainer 338 through an email that you have a change (or patch) you would like 339 considered for the development branch of the Git repository. To send 340 this type of change, you format the patch and then send the email 341 using the Git commands ``git format-patch`` and ``git send-email``. 342 For information on how to use these scripts, see the 343 ":ref:`dev-manual/changes:submitting a change to the yocto project`" 344 section in the Yocto Project Development Tasks Manual. 345 346Git 347=== 348 349The Yocto Project makes extensive use of Git, which is a free, open 350source distributed version control system. Git supports distributed 351development, non-linear development, and can handle large projects. It 352is best that you have some fundamental understanding of how Git tracks 353projects and how to work with Git if you are going to use the Yocto 354Project for development. This section provides a quick overview of how 355Git works and provides you with a summary of some essential Git 356commands. 357 358.. note:: 359 360 - For more information on Git, see 361 https://git-scm.com/documentation. 362 363 - If you need to download Git, it is recommended that you add Git to 364 your system through your distribution's "software store" (e.g. for 365 Ubuntu, use the Ubuntu Software feature). For the Git download 366 page, see https://git-scm.com/download. 367 368 - For information beyond the introductory nature in this section, 369 see the ":ref:`dev-manual/start:locating yocto project source files`" 370 section in the Yocto Project Development Tasks Manual. 371 372Repositories, Tags, and Branches 373-------------------------------- 374 375As mentioned briefly in the previous section and also in the 376":ref:`overview-manual/development-environment:git workflows and the yocto project`" 377section, the Yocto Project maintains source repositories at :yocto_git:`/`. 378If you look at this web-interface of the repositories, each item is a separate 379Git repository. 380 381Git repositories use branching techniques that track content change (not 382files) within a project (e.g. a new feature or updated documentation). 383Creating a tree-like structure based on project divergence allows for 384excellent historical information over the life of a project. This 385methodology also allows for an environment from which you can do lots of 386local experimentation on projects as you develop changes or new 387features. 388 389A Git repository represents all development efforts for a given project. 390For example, the Git repository ``poky`` contains all changes and 391developments for that repository over the course of its entire life. 392That means that all changes that make up all releases are captured. The 393repository maintains a complete history of changes. 394 395You can create a local copy of any repository by "cloning" it with the 396``git clone`` command. When you clone a Git repository, you end up with 397an identical copy of the repository on your development system. Once you 398have a local copy of a repository, you can take steps to develop 399locally. For examples on how to clone Git repositories, see the 400":ref:`dev-manual/start:locating yocto project source files`" 401section in the Yocto Project Development Tasks Manual. 402 403It is important to understand that Git tracks content change and not 404files. Git uses "branches" to organize different development efforts. 405For example, the ``poky`` repository has several branches that include 406the current "&DISTRO_NAME_NO_CAP;" branch, the "master" branch, and many 407branches for past Yocto Project releases. You can see all the branches 408by going to :yocto_git:`/poky/` and clicking on the 409``[...]`` link beneath the "Branch" heading. 410 411Each of these branches represents a specific area of development. The 412"master" branch represents the current or most recent development. All 413other branches represent offshoots of the "master" branch. 414 415When you create a local copy of a Git repository, the copy has the same 416set of branches as the original. This means you can use Git to create a 417local working area (also called a branch) that tracks a specific 418development branch from the upstream source Git repository. In other 419words, you can define your local Git environment to work on any 420development branch in the repository. To help illustrate, consider the 421following example Git commands:: 422 423 $ cd ~ 424 $ git clone git://git.yoctoproject.org/poky -b &DISTRO_NAME_NO_CAP; 425 426In the previous example 427after moving to the home directory, the ``git clone`` command creates a 428local copy of the upstream ``poky`` Git repository and checks out a 429local branch named "&DISTRO_NAME_NO_CAP;", which tracks the upstream 430"origin/&DISTRO_NAME_NO_CAP;" branch. Changes you make while in this 431branch would ultimately affect the upstream "&DISTRO_NAME_NO_CAP;" branch 432of the ``poky`` repository. 433 434It is important to understand that when you create and checkout a local 435working branch based on a branch name, your local environment matches 436the "tip" of that particular development branch at the time you created 437your local branch, which could be different from the files in the 438"master" branch of the upstream repository. In other words, creating and 439checking out a local branch based on the "&DISTRO_NAME_NO_CAP;" branch 440name is not the same as checking out the "master" branch in the 441repository. Keep reading to see how you create a local snapshot of a 442Yocto Project Release. 443 444Git uses "tags" to mark specific changes in a repository branch 445structure. Typically, a tag is used to mark a special point such as the 446final change (or commit) before a project is released. You can see the 447tags used with the ``poky`` Git repository by going to :yocto_git:`/poky/` 448and clicking on the ``[...]`` link beneath the "Tag" heading. 449 450Some key tags for the ``poky`` repository are ``jethro-14.0.3``, 451``morty-16.0.1``, ``pyro-17.0.0``, and 452``&DISTRO_NAME_NO_CAP;-&DISTRO;``. These tags represent Yocto Project 453releases. 454 455When you create a local copy of the Git repository, you also have access 456to all the tags in the upstream repository. Similar to branches, you can 457create and checkout a local working Git branch based on a tag name. When 458you do this, you get a snapshot of the Git repository that reflects the 459state of the files when the change was made associated with that tag. 460The most common use is to checkout a working branch that matches a 461specific Yocto Project release. Here is an example:: 462 463 $ cd ~ 464 $ git clone git://git.yoctoproject.org/poky 465 $ cd poky 466 $ git fetch --tags 467 $ git checkout tags/rocko-18.0.0 -b my_rocko-18.0.0 468 469In this example, the name 470of the top-level directory of your local Yocto Project repository is 471``poky``. After moving to the ``poky`` directory, the ``git fetch`` 472command makes all the upstream tags available locally in your 473repository. Finally, the ``git checkout`` command creates and checks out 474a branch named "my-rocko-18.0.0" that is based on the upstream branch 475whose "HEAD" matches the commit in the repository associated with the 476"rocko-18.0.0" tag. The files in your repository now exactly match that 477particular Yocto Project release as it is tagged in the upstream Git 478repository. It is important to understand that when you create and 479checkout a local working branch based on a tag, your environment matches 480a specific point in time and not the entire development branch (i.e. 481from the "tip" of the branch backwards). 482 483Basic Commands 484-------------- 485 486Git has an extensive set of commands that lets you manage changes and 487perform collaboration over the life of a project. Conveniently though, 488you can manage with a small set of basic operations and workflows once 489you understand the basic philosophy behind Git. You do not have to be an 490expert in Git to be functional. A good place to look for instruction on 491a minimal set of Git commands is 492`here <https://git-scm.com/documentation>`__. 493 494The following list of Git commands briefly describes some basic Git 495operations as a way to get started. As with any set of commands, this 496list (in most cases) simply shows the base command and omits the many 497arguments it supports. See the Git documentation for complete 498descriptions and strategies on how to use these commands: 499 500- *git init:* Initializes an empty Git repository. You cannot use 501 Git commands unless you have a ``.git`` repository. 502 503- *git clone:* Creates a local clone of a Git repository that is on 504 equal footing with a fellow developer's Git repository or an upstream 505 repository. 506 507- *git add:* Locally stages updated file contents to the index that 508 Git uses to track changes. You must stage all files that have changed 509 before you can commit them. 510 511- *git commit:* Creates a local "commit" that documents the changes 512 you made. Only changes that have been staged can be committed. 513 Commits are used for historical purposes, for determining if a 514 maintainer of a project will allow the change, and for ultimately 515 pushing the change from your local Git repository into the project's 516 upstream repository. 517 518- *git status:* Reports any modified files that possibly need to be 519 staged and gives you a status of where you stand regarding local 520 commits as compared to the upstream repository. 521 522- *git checkout branch-name:* Changes your local working branch and 523 in this form assumes the local branch already exists. This command is 524 analogous to "cd". 525 526- *git checkout -b working-branch upstream-branch:* Creates and 527 checks out a working branch on your local machine. The local branch 528 tracks the upstream branch. You can use your local branch to isolate 529 your work. It is a good idea to use local branches when adding 530 specific features or changes. Using isolated branches facilitates 531 easy removal of changes if they do not work out. 532 533- *git branch:* Displays the existing local branches associated 534 with your local repository. The branch that you have currently 535 checked out is noted with an asterisk character. 536 537- *git branch -D branch-name:* Deletes an existing local branch. 538 You need to be in a local branch other than the one you are deleting 539 in order to delete branch-name. 540 541- *git pull \-\-rebase*: Retrieves information from an upstream Git 542 repository and places it in your local Git repository. You use this 543 command to make sure you are synchronized with the repository from 544 which you are basing changes (e.g. the "&DISTRO_NAME_NO_CAP;" 545 branch). The ``--rebase`` option ensures that any local commits you 546 have in your branch are preserved at the top of your local branch. 547 548- *git push repo-name local-branch:upstream-branch:* Sends 549 all your committed local changes to the upstream Git repository that 550 your local repository is tracking (e.g. a contribution repository). 551 The maintainer of the project draws from these repositories to merge 552 changes (commits) into the appropriate branch of project's upstream 553 repository. 554 555- *git merge:* Combines or adds changes from one local branch of 556 your repository with another branch. When you create a local Git 557 repository, the default branch may be named "main". A typical 558 workflow is to create a temporary branch that is based off "main" 559 that you would use for isolated work. You would make your changes in 560 that isolated branch, stage and commit them locally, switch to the 561 "main" branch, and then use the ``git merge`` command to apply the 562 changes from your isolated branch into the currently checked out 563 branch (e.g. "main"). After the merge is complete and if you are 564 done with working in that isolated branch, you can safely delete the 565 isolated branch. 566 567- *git cherry-pick commits:* Choose and apply specific commits from 568 one branch into another branch. There are times when you might not be 569 able to merge all the changes in one branch with another but need to 570 pick out certain ones. 571 572- *gitk:* Provides a GUI view of the branches and changes in your 573 local Git repository. This command is a good way to graphically see 574 where things have diverged in your local repository. 575 576 .. note:: 577 578 You need to install the 579 gitk 580 package on your development system to use this command. 581 582- *git log:* Reports a history of your commits to the repository. 583 This report lists all commits regardless of whether you have pushed 584 them upstream or not. 585 586- *git diff:* Displays line-by-line differences between a local 587 working file and the same file as understood by Git. This command is 588 useful to see what you have changed in any given file. 589 590Licensing 591========= 592 593Because open source projects are open to the public, they have different 594licensing structures in place. License evolution for both Open Source 595and Free Software has an interesting history. If you are interested in 596this history, you can find basic information here: 597 598- :wikipedia:`Open source license history <Open-source_license>` 599 600- :wikipedia:`Free software license history <Free_software_license>` 601 602In general, the Yocto Project is broadly licensed under the 603Massachusetts Institute of Technology (MIT) License. MIT licensing 604permits the reuse of software within proprietary software as long as the 605license is distributed with that software. Patches to the Yocto Project 606follow the upstream licensing scheme. You can find information on the 607MIT license :wikipedia:`here <MIT_License>`. 608 609When you build an image using the Yocto Project, the build process uses 610a known list of licenses to ensure compliance. You can find this list in 611the :term:`Source Directory` at ``meta/files/common-licenses``. Once the 612build completes, the list of all licenses found and used during that build 613are kept in the :term:`Build Directory` at ``tmp/deploy/licenses``. 614 615If a module requires a license that is not in the base list, the build 616process generates a warning during the build. These tools make it easier 617for a developer to be certain of the licenses with which their shipped 618products must comply. However, even with these tools it is still up to 619the developer to resolve potential licensing issues. 620 621The base list of licenses used by the build process is a combination of 622the Software Package Data Exchange (SPDX) list and the Open Source 623Initiative (OSI) projects. `SPDX Group <https://spdx.org>`__ is a working 624group of the Linux Foundation that maintains a specification for a 625standard format for communicating the components, licenses, and 626copyrights associated with a software package. 627`OSI <https://opensource.org>`__ is a corporation dedicated to the Open 628Source Definition and the effort for reviewing and approving licenses 629that conform to the Open Source Definition (OSD). 630 631You can find a list of the combined SPDX and OSI licenses that the Yocto 632Project uses in the ``meta/files/common-licenses`` directory in your 633:term:`Source Directory`. 634 635For information that can help you maintain compliance with various open 636source licensing during the lifecycle of a product created using the 637Yocto Project, see the 638":ref:`dev-manual/licenses:maintaining open source license compliance during your product's lifecycle`" 639section in the Yocto Project Development Tasks Manual. 640