THE SPDX WIKI IS NO LONGER ACTIVE. ALL CONTENT HAS BEEN MOVED TO https://github.com/spdx
Difference between revisions of "Technical Team/Use Cases/2.0/Build System Yocto"
Line 1: | Line 1: | ||
− | <p class="MsoNormal"><strong>THis is still a draft and not quite finiliazed but its close.</strong></p><p class="MsoNormal"><strong>Title:</strong> Yocto</p><p class="MsoNormal"><strong>Background:</strong> | + | <p class="MsoNormal"><strong>THis is still a draft and not quite finiliazed but its close.</strong></p><p class="MsoNormal"><strong>Title:</strong> Yocto</p><p class="MsoNormal"><strong>Background:</strong> </p><p class="MsoNormal">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.</p><p class="MsoNormal">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. </p><p class="MsoNormal">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> </p><p class="MsoNormal"><strong>Primary Actor:</strong></p><p class="MsoNormal">Yocto User: Executs a build</p><p class="MsoNormal">Package Maintainer: These are upstream projects thatr have projects that Yocto consumes. This upstream project could be a company that provides a package as well.</p><p class="MsoNormal">Yocto Project: Provides the Yocto build system</p><p class="MsoNormal">Yocto 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.</p><p class="MsoNormal"><strong>Goal in Context:</strong> 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 copyrigthable artifacts,</p><p class="MsoNormal"><strong>Stakeholders and Interests:</strong> </p><p class="MsoNormal">Yocto User: Genetrates a buuod getting an image for their hardware. They want SPDX documents for each package/coyrightable element.</p><p class="MsoNormal"><br />Package Maintainer: To provide license information using SPDX</p><p class="MsoNormal"><br />Yocto Project: To provide SPDX documents that describe the licensing of the artifacts provided by the build system.</p><p class="MsoNormal"><br />Build System Provider: They provide a particular build system for thier hardware, for example for their product. They may also provide patches to Packages that the recipes pull.</p><p class="MsoNormal"><strong>Providers of artifacts: </strong></p><p class="MsoNormal"><strong>Consumers of artifacts:</strong></p><ol type="1"><li class="MsoNormal">To receive accurate and clear information of licensing of artifacts</li><li class="MsoNormal">To be able to comply easily with licenses for artifacts</li><li class="MsoNormal">To be able to subset, extend, or aggregate artifacts and pass on clear authoritative verifiable license for the resulting new copyrightable artifacts.</li></ol><p class="MsoNormal"><strong>Preconditions:</strong> </p><p class="MsoNormal"><strong>Main Success Scenario:</strong> Someone executing a Yocto based build gets SPDX documents that decsribe the licensing for all copyrightable elements that were used to create the build and are the result of a build.</p><p class="MsoNormal"><strong>Failed End Condition:</strong> SPDX documents for copyrigthable elements are missing.ow easy will be tis to detect as these builds can be rather large?</p><p class="MsoNormal"><strong>Trigger:</strong></p><p class="MsoNormal">A Yocto user executes a build.</p> |
Revision as of 13:19, 5 June 2012
THis is still a draft and not quite finiliazed but its close.
Title: Yocto
Background:
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: Executs a build
Package Maintainer: These are upstream projects thatr have projects that Yocto consumes. This upstream project could be a company that provides a package as well.
Yocto Project: Provides the Yocto build system
Yocto 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 copyrigthable artifacts,
Stakeholders and Interests:
Yocto User: Genetrates a buuod getting an image for their hardware. They want SPDX documents for each package/coyrightable element.
Package Maintainer: To provide license information using SPDX
Yocto Project: To provide SPDX documents that describe the licensing of the artifacts provided by the build system.
Build System Provider: They provide a particular build system for thier hardware, for example for their product. They may also provide patches to Packages that the recipes pull.
Providers of artifacts:
Consumers of artifacts:
- To receive accurate and clear information of licensing of artifacts
- To be able to comply easily with licenses for artifacts
- To be able to subset, extend, or aggregate artifacts and pass on clear authoritative verifiable license for the resulting new copyrightable artifacts.
Preconditions:
Main Success Scenario: Someone executing a Yocto based build gets SPDX documents that decsribe the licensing for all copyrightable elements that were used to create the build and are the result of a build.
Failed End Condition: SPDX documents for copyrigthable elements are missing.ow easy will be tis to detect as these builds can be rather large?
Trigger:
A Yocto user executes a build.