THE SPDX WIKI IS NO LONGER ACTIVE. ALL CONTENT HAS BEEN MOVED TO https://github.com/spdx

Technical Team/Use Cases/2.0/Build System Yocto

From SPDX Wiki
Jump to: navigation, search


Title:  Yocto

Background: 

Yocto is a build system which typically provides a file system/kernel image which can be downloaded onto a device and executed. When Yocto builds a package the package source can come from various sources such as: source code control system like GIT or a tarball. Entities providng a Yocto build for their hardware may also be providing pacthes for the package.

Yocto uses recipes to build packages. These recipes do contain a License field. The current short names do not match SPDX short names and likely will not. It was rather difficult to get alignment on the current ones used. There is talk on the Yocto project about converting the Yocto short names into SPDX ones. 

Also see <a href="http://www.yoctoproject.org/docs/1.0/yocto-quick-start/yocto-project-qs.html">http://www.yoctoproject.org/docs/1.0/yocto-quick-start/yocto-project-qs.html</a> 

Primary Actor:

Yocto User: Executes a build

Package Maintainer: These are upstream projects that have projects that Yocto consumes. This upstream project could be a company that provides a package as well. A Package Maintainer could be viewed as a secondary actor in this use case as their package may be consumed by a Yocto build even though they as packages maintainers have no vested interest in Yocto.

Yocto Project: Provides the Yocto build system

Build System Provider: They provide a particular build system, for example for their product. They may also provide patches to Packages that the recipes pull.

Goal in Context:  To generate a kernel/file system image for a hardware device or simulator using Yocto and to have SPDX documents that describe the licensing for all copyrightable artifacts,

Stakeholders and Interests: 

Yocto User:

       A. To receive accurate and clear information of licensing for all copyrightable

            elements used in the build and for the build system.

       B. To be able to comply easily with licenses for all copyrightable elements used in

            the build and the build system.


2. Package Maintainer:

       A. To communicate the license information for their package.

       B. To have their licenses respected.

 

3. Yocto Project:

       A. To communicate the license information for their build system and the licensing of each package.

       B. To have their licenses respected

 

4. Build System Provider:

      A. To communicate the licensing information for the build they are providing.

      B. To comply with all the licenses used in the build the system they are providing.

 

Preconditions: 

     1. A yocoto build is created.

     2. Packages used in the Yocoto build have SPDX documents describing the copyrigthable elements of the package.

 

Main Success Scenario: A user executing a Yocto based build gets SPDX documents that describe the licensing for all copyrightable elements that were used to create the build and are the result of a build.

Failed End Condition: Inaccurate or incomplete licensing information is provided for all packages used in the build and/or for the Yocto build system.

Trigger:

A Yocto user executes a build.