Package Exclusion

Introduction

This page describes some proposed updates to the INCOMPATIBLE_LICENSE and COMMERCIAL* package exclusion mechanisms within Poky for the Yocto Project version 1.1. See also License Infrastructure Interest Group for some overlapping work (particularly for the first part of the proposed implementation below).

Aims

• Make error messages clear when user/dependencies have asked for something to be built that can't be due to restrictions
• Ensure that exclusion system is reliable

Proposed implementation

1. Ensure all documentation of LICENSE field value syntax is clear, concise and up-to-date (wiki and manual) [Beth/ScottR ?]
2. Go through and audit all recipes LICENSE field values to ensure that they all conform to the specifications. This includes making sure that | (package may be used under one of a selection of licences) and & (recipe has mixed licences that apply to the code base, so conditions of all must be observed) are used correctly. [Beth]
3. bitbake/core changes:
   • LICENSE field checking must fully parse the field and understand the difference between | and &, and must not e.g. mark Qt as being GPLv3 only.
   • All error messages should be clear about which version of a package is being excluded not just the name (different versions may have different licences)
   • Make the LICENSE validity checking more strict (given recipes have been audited and rules are clear after above)
   • Don't exclude any recipes at parse time - simply record all excluded recipes and their runtime provides in a deny list which also includes flags indicating the reason for deny-listing
   • Ensure all excluded licences in INCOMPATIBLE_LICENSE are valid (e.g. catch GPL3 as apposed to GPLv3) - if not, error out
   • Check when calculating dependencies if anything is scheduled to be built that is on the deny-list - if any are, gather all of them up and then stop and list them in an error message along with reason and depchain for each one
   • Check when constructing the rootfs if anything in the runtime provides denylist is going to be included - if so, error out

Some further possible extensions:

• Possibly apply similar logic to COMPATIBLE_MACHINE?
• Replace COMMERCIAL* with some more generic exclusion mechanism that allows the reason to be defined as part of the exclusion list?
• As a helper for non-en_US users, fail on parse if user defines any of the *LICENSE* variables as *LICENCE*? (we definitely don't want the build to continue and just ignore this as the user might not realise what has happened)