blob: e2003f213a63bb69c5babc3522b6932b08dcda21 [file] [log] [blame]
Trusted Firmware binary repository
==================================
.. section-numbering::
:suffix: .
.. contents::
This repository hosts redistributable binary components that are needed with
certain platform ports of trustedfirmware.org projects. All contributions to
this repository must follow the rules and process laid out below as well as
individual contribution guidelines of the respective project. License terms for
individual binaries are described in the accompanying ``release-notes.rst``.
Scope
-----
This repository is intended for cases where it's not possible to fully
open-source a trustedfirmware.org project platform port. Binary components
should be as minimal as possible, augmenting the more significant, open-source
part of the platform port. Binary components that contain all meaningful
functionality of a platform port and are merely linked into a boilerplate shell
of open-source code will not be accepted.
The trustedfirmware.org Technical Steering Committee or Governing Board will
decide whether to host binary components in this repository on a case by case
basis. Applications for inclusion can be sent to tsc@lists.trustedfirmware.org.
Binary components must always be associated with a specific platform port. No
generic code (i.e. any code outside the ``plat/<vendor>`` directory) may depend
on a binary component.
License
-------
All binary components must be accompanied by a distribution license. The license
should:
#. be irrevocable
#. be royalty-free
#. grant usage rights for both copyright and patents covering the binary
#. allow unlimited redistribution under the same terms
#. not restrict the ability to publish test results from the platform port
To simplify legal review and avoid potential concerns, we recommend that the
license should be as short and simple as possible. Special terms should be
limited to what is absolutely necessary. The `Permissive Binary License`_
adapted from the Arm Mbed project is a good example of a license that fulfills
these requirements, and contributors are welcome to reuse it for their binaries.
Reusing an already accepted license may greatly speed up and simplify the
acceptance process for a new binary.
When a binary is including third-party code (including open-source code) that is
covered by separate license terms, all those licenses must be compatible with
the distribution license.
Notices
-------
All license and copyright notices covering the binary (including for linked
third-party components) must be listed or linked to in the release notes. For
licenses that are included in the `SPDX license list`_, please link to the
appropriate SPDX license page rather than uploading a copy of the license to the
binary repository.
Release Notes
-------------
All binary components must be clearly versioned and accompanied by a release
notes document that lists the following (updated for each version):
#. version
#. release date
#. distribution license
#. full list of license and copyright notices for (all parts of) the binary
(can be put into a separate file and linked from release notes if desired)
#. supported silicon
#. changes since the last version
#. errata, known issues
#. commit hash of the open-source trustedfirmware.org project it was tested with
See the `example release notes`_ for suggestions on how to format these notes.
Support
-------
As interfaces in open-source trustedfirmware.org projects change and get
deprecated, it may not be possible to keep a platform port functional without
updating the binary components it depends on. Contributors of binary components
are expected to maintain them together with their platform ports and release
updates as necessary. A binary component that no longer works with current
builds of the open-source project and is not being kept up to date may be
removed. Likewise, new binary component updates need to be tested with the
latest version of the open-source platform port (and the latter needs to be
updated if necessary) before they can be accepted.
Directory Structure
-------------------
This repository contains binaries, license files and release notes. Release
notes must always be placed in the same directory as the binary file(s) they
apply to and should be called ``release-notes.rst``. Directories should be
scoped by vendor and platform if necessary (e.g. a binary pertaining to a single
platform should be placed under ``vendorname/platformname`` whereas a binary
that can support multiple SoCs of a vendor can be placed directly under
``vendorname``). Vendor-specific licenses should be placed in the ``licenses/``
subdirectory of a vendor directory and referenced from the ``release-notes.rst``
files of the binaries they apply to.
Example layout::
- readme.rst
- licenses/
- permissive-binary-license.txt
- vendorA/
- licenses/
- vendor-specific-license.txt
- commonBinaryX/
- fileA.bin
- fileB.hex
- release-notes.rst
- platformA1/
- fileC.bin
- release-notes.rst
- platformA2
- binaryY/
- fileD.bin
- release-notes.rst
- binaryZ/
- fileE.elf
- fileF.bin
- release-notes.rst
.. _Permissive Binary License: licenses/permissive-binary-license.txt
.. _SPDX license list: https://spdx.org/licenses/
.. _example release notes: example-release-notes.rst