|
|
| (6 intermediate revisions by 2 users not shown) |
| Line 1: |
Line 1: |
| == Introduction ==
| | This document has been deprecated - the droids you are looking for are at: [ https://wiki.yoctoproject.org/wiki/Working_Draft_of_Compliance_Prop ] |
| The YOCTO PROJECT adheres to the guidelines set up by the Linux Foundation (add link here). The YOCTO PROJECT compliance program has been established to support and strengthen the YOCTO PROJECT strategic initiatives and promote by use of its branding.
| |
| *To encourage the development of and collaboration on the use of a common set of tools, standards and practices to reduce fragmentation in the embedded market.
| |
| *To ensure as much as possible that the tooling for these developments is architecturally independent.
| |
| *To provide benefits to membership in the YOCTOPROJECT.
| |
|
| |
|
| In other words, the compliance program provides the necessary level of standardizations to allow OSVs, ODMs, Tools and Application developers to deliver implementations which contribute to and support the goals of the project.
| | (This redirect is due to Dave Stewart's jet-lagged blunder. Apologies to Sean Hudson) |
| | |
| Compliance as defined by the YOCTO PROJECT governs the use of the project name, Logo and marks in association with products, marketing materials, and announcements. Use of the YOCTO PROJECT name, logo and marks is governed by the YOCTO PROJECT brand guidelines. (Add document link here – document and guidelines are in development)
| |
| | |
| As with Linux, COMPLIANCE AFFECTS THE COMMERCIAL USE OF THE RESULTING DISTRIBUTIONS CREATED BY THE YOCTO PROJECT. PERSONAL USE CASES ARE NOT COVERED.
| |
|
| |
| == Compliance levels, Compliance Recommendations and Terminology ==
| |
| The Yocto Project compliance program defines several steps of compliance to support OSVs, ODMs, Project Contributors, and Application Developers.
| |
| | |
| === Yocto Project Aligned ===
| |
| | |
| This covers use cases by those unlikely to be actively developing the project itself, companies which are supportive of the goals, but not influential in the governance of the project from a business or technology point of view. To use this term in connection with any commercial product or project or marketing materials you need to:
| |
| *Be working towards and supporting the aims and objectives of the Yocto Project. These include decreasing the fragmentation of embedded ecosystem and focus around a common shared set of tools, formats and best practices. We want to avoid multiple groups of people repeating the same work and have one set of great tools rather than multiple tools with drawbacks.
| |
| *Be promoting the OpenEmbedded Architecture, layer model and BSP format over other systems
| |
| *Be making visible contributions in the Open Embedded and component projects of the Yocto Project, or using a pre-defined recipe to build your own distribution
| |
| *Aim for compatibility and interoperability between different metadata layers.
| |
| *Be an open source project, charity organization or small business or consultancy. Larger companies (80+ employees) should be members of the project.
| |
| | |
| === Yocto Project Powered ===
| |
| | |
| Suggested new term: Registered
| |
| | |
| This is for companies who are deeply involved in the project, contributing and guiding. To use this term in connection with any product or project or in marketing materials you need to: | |
| *Be able to satisfy all the criteria for "Yocto Project Aligned" (except company size/type)
| |
| *Be an open source project, charity organization or a member of the Yocto Project
| |
| *Be making visible contributions in the Open Embedded and component projects of the Yocto Project, or using a pre-defined recipe to build their own distribution
| |
| *Be able to answer 'Yes' to all the required criteria in the compliancy checklist.
| |
| *Document the required criteria in the test documentation? Information to be supplied by the technology team.
| |
| *Have considered the recommendations and documented those recommendations in the test documentation regarding what was actually tested.
| |
| | |
| == Yocto Project Powered Compliancy Checklist ==
| |
| * Does the project have clearly identifiable components that correspond to BitBake and OpenEmbedded-Core if these are present? (Y/N)
| |
| * Have all patches applied to BitBake and OpenEmbedded-Core components been discussed with the open source community? (Y/N)
| |
| * Do all layers build against OE-Core? (Y/N)
| |
| * Does any hardware support follow the format defined in the Yocto Project Board Support Package (BSP) Developers Guide? (Y/N)
| |
| * Are hardware support, configuration (distribution) policy and recipe metadata clearly separated into different layers which can be used separately? (Y/N)
| |
| * Are the combinations of layers which were tested clearly documented? (Y/N)
| |
| | |
| == Yocto Project Powered Compliance Recommendations ==
| |
| It is recommended that users meet the following, but this is not required to be Yocto Project Powered, it is just a recommendation:
| |
| * (O) Are Linux kernels either based around LTSI kernel versions or more recent that the last LTSI release? (Y/N)
| |
| * (O) Does all code basically work with the standard tool chain from OE-Core (it may be un-optimized) where the architecture is one supported by OE-Core as standard? (Y/N)
| |
| | |
| == Yocto Project Brand Documentation ==
| |
| Clearly document how the brands can be used (palette etc) as well as when they can be used in conjunction with the above. (in progress)
| |
|
| |
| == Registration Process ==
| |
| *A registration area will be available on the Yocto Project WIKI where companies interested in publically using the YOCTO PROJECT brand or wording associating a product or intent with the YOCTO PROJECT must register the following information:
| |
| :#Company
| |
| :#Product Name
| |
| :#How the YOCTO PROJECT logo or text association is being used.
| |
| :#Timeframe
| |
| *Those found not in compliance will be WHAT?
| |
