PEP 770: Move 'Selecting a single SBOM standard' to rejected ideas (#4228)

Author: sethmlarson

peps/pep-0770.rst

@@ -409,6 +409,24 @@ is not constrained to select a single SBOM standard by its consumers and thus
 can allow tools creating SBOM documents for inclusion in Python packages to
 choose which SBOM standard works best for their use-case.
 
+Rejected Ideas
+==============
+
+Selecting a single SBOM standard
+--------------------------------
+
+There is no universally accepted SBOM standard and this area is still
+rapidly evolving (for example, SPDX released a new major version of their
+standard in April 2024). To avoid locking the Python ecosystem into a specific
+standard ahead of when a clear winner emerges this PEP treats SBOM documents
+as opaque and only makes recommendations to promote compatibility with
+downstream consumers of SBOM document data.
+
+None of the decisions in this PEP restrict a future PEP to select
+a single SBOM standard. Tools that use SBOM data today already need to support
+multiple formats to handle this situation, so a future standard that updates to
+require only one standard would have no effect on downstream SBOM tools.
+
 Open Issues
 ===========
 
@@ -417,13 +435,6 @@ Conditional project source SBOM files
 
 How can a project specify an SBOM file that is conditional? Under what circumstances would an SBOM document be conditional?
 
-Selecting a single SBOM standard
---------------------------------
-
-Should this PEP select a single SBOM standard instead of supporting any
-SBOM standard? Selecting a single standard would potentially limit the
-evolution of SBOM standards which is an active area of development.
-
 References
 ==========