Documentation/index.md: Add coreboot's blob policy

Every now and then we have discussions about blobs and how and if they
should be introduced or handled. This patch adds a clear statement on
the project's view on this topic to avoid unclear situations in the
future.

Change-Id: I20bc0b345c129ecd59aa1190647d89f6d4e07d46
Signed-off-by: Werner Zeh <werner.zeh@siemens.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/82086
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de>

1 files changed, 39 insertions, 0 deletions

diff --git a/Documentation/index.md b/Documentation/index.md
index d205151292..7ba88f30ef 100644
--- a/Documentation/index.md
+++ b/Documentation/index.md
@@ -139,6 +139,45 @@ Every now and then, coreboot is present in one way or another at
 [conferences](community/conferences.md). If you're around, come and
 say hello!
 
+## Blob policy in the coreboot project
+
+The goal of the coreboot project is to provide a FOSS firmware solution across
+multiple CPU architectures, such as ARM, x86, and RISC-V. While fully open
+source implementations for these architectures are encouraged and preferred,
+we understand that a fully open implementation whereby every firmware component
+is available as source code for modern platforms is not always feasible.
+Different reasons inhibit the availability of fully open implementations,
+including limited development resources, 3rd party license constraints of
+IP blocks, or a legacy mindset of the silicon vendors.
+
+It is important for the coreboot project to have support for modern CPU
+platforms in order to provide a viable alternative for proprietary firmware
+implementations. We do not have direct control over how hardware vendors design
+their products, however we can provide an attractive alternative to the
+expensive and complicated proprietary firmware model that exists today.
+For modern platforms, we are largely dependent on the silicon
+vendor to provide additional information on how to properly initialize the
+hardware, as the required datasheets are often only available with an NDA.
+Therefore, one possible way to have coreboot support for the latest platforms
+is binary code (aka, a blob) provided by the silicon vendor. While we do
+discourage this solution, it can be a door opener for coreboot’s support of a
+given platform and thus keep coreboot functional on modern platforms. It is
+clearly not the goal of the project to accept every blob a silicon vendor wishes
+to use without question. On the contrary, each new blob needs to be examined
+critically by the community, evaluating the need, risk, and alternative options.
+
+Wherever possible, introducing new blobs should be avoided. That said, there
+can be situations where a piece of code provided as a blob will enable the rest
+of the fully open source firmware stack on a brand new platform. If blocking
+this blob would lead to no support at all for the platform in question in
+coreboot, this situation needs to be examined carefully. While these kinds
+of discussion will be coordinated closely with the community (e.g. on the
+mailing list or dedicated meetings), ultimately it is up to the leadership to
+decide if there is no agreement between the community and the vendor pushing for
+the new blob. This decision will be communicated on the mailing list.
+Please see additionally
+[coreboot binary policy](https://github.com/coreboot/blobs/blob/master/README.md).
+
 ## Getting the source code
 
 coreboot is primarily developed in the