Finite State Logo

Type: SoftwareComponentRelationshipType

Enumeration of the different types of relationships between software components, based on SPDX. This relationship is a directed relationship, but doesn't have to explicitly express both sides of the relationship. For example, having a CONTAINS relationship between two components implies that the dest is also CONTAINED_BY the source.

See the SPDX specification for more definitions: https://spdx.github.io/spdx-spec/v2.3/relationships-between-SPDX-elements/ *** Note: We omit DESCRIBES, DESCRIBED_BY, and AMENDS as they are SPDX document-specific. ***

ENUMERATION VALUES

  • ANCESTOR_OF: Is to be used when sourceComponent-A is an ancestor (same lineage but pre-dates) destComponent-B. Example: A SOURCE file makefile.mk is a version of the original ancestor SOURCE file makefile2.mk
  • BUILD_DEPENDENCY_OF: Is to be used when sourceComponent-A is a build dependency of destComponent-B. Example: A is in the compile scope of B in a Maven project.
  • BUILD_TOOL_OF: Is to be used when sourceComponent-A is used to build destComponent-B. Example: A SOURCE file makefile.mk is used to build an APPLICATION zlib.
  • CONTAINED_BY: Is to be used when sourceComponent-A is contained by destComponent-B. Example: A SOURCE file foo.c is contained by ARCHIVE file bar.tgz
  • CONTAINS: Is to be used when sourceComponent-A contains destComponent-B. Example: An ARCHIVE file bar.tgz contains a SOURCE file foo.c.
  • COPY_OF: Is to be used when sourceComponent-A is an exact copy of destComponent-B. Example: A BINARY file alib.a is an exact copy of BINARY file a2lib.a.
  • DATA_FILE_OF: Is to be used when sourceComponent-A is a data file used in destComponent-B. Example: An IMAGE file kitty.jpg is a data file of an APPLICATION hellokitty.
  • DEPENDENCY_MANIFEST_OF: Is to be used when sourceComponent-A is a manifest file that lists a set of dependencies for destComponent-B. Example: A file package.json is the dependency manifest of a package foo. Note that only one manifest should be used to define the same dependency graph.
  • DEPENDENCY_OF: Is to be used when sourceComponent-A is dependency of destComponent-B. Example: A is explicitly stated as a dependency of B in a machine-readable file. Use when a package manager does not define scopes.
  • DEPENDS_ON: Is to be used when sourceComponent-A depends on destComponent-B. Example: Package A depends on the presence of package B in order to build and run
  • DESCENDANT_OF: Is to be used when sourceComponent-A is a descendant of (same lineage but postdates) destComponent-B. Example: A SOURCE file makefile2.mk is a descendant of the original SOURCE file makefile.mk
  • DEV_DEPENDENCY_OF: Is to be used when sourceComponent-A is a development dependency of destComponent-B. Example: A is in the devDependencies scope of B in a Maven project.
  • DEV_TOOL_OF: Is to be used when sourceComponent-A is used as a development tool for destComponent-B. Example: Any tool used for development such as a code debugger.
  • DISTRIBUTION_ARTIFACT: Is to be used when distributing sourceComponent-A requires that destComponent-B also be distributed. Example: A BINARY file foo.o requires that the ARCHIVE file bar-sources.tgz be made available on distribution.
  • DOCUMENTATION_OF: Is to be used when sourceComponent-A provides documentation of destComponent-B. Example: A DOCUMENTATION file readme.txt documents the APPLICATION zlib.
  • DYNAMIC_LINK: Is to be used when sourceComponent-A dynamically links to destComponent-B. Example: An APPLICATION file myapp dynamically links to BINARY file zlib.so.
  • EXAMPLE_OF: Is to be used when sourceComponent-A is an example of destComponent-B. Example: The file or snippet that illustrates how to use an application or library.
  • EXPANDED_FROM_ARCHIVE: Is to be used when sourceComponent-A is expanded from the archive destComponent-B. Example: A SOURCE file foo.c, has been expanded from the archive ARCHIVE file xyz.tgz.
  • FILE_ADDED: Is to be used when sourceComponent-A is a file that was added to destComponent-B. Example: A SOURCE file foo.c has been added to package ARCHIVE bar.tgz.
  • FILE_DELETED: Is to be used when sourceComponent-A is a file that was deleted from destComponent-B. Example: A SOURCE file foo.diff has been deleted from package ARCHIVE bar.tgz.
  • FILE_MODIFIED: Is to be used when sourceComponent-A is a file that was modified from destComponent-B. Example: A SOURCE file foo.c has been modified from SOURCE file foo.orig.c.
  • GENERATED_FROM: Is to be used when sourceComponent-A was generated from destComponent-B. Example: A BINARY file a.out has been generated from a SOURCE file makefile.mk. A BINARY file foolib.a is generated from a SOURCE file bar.c.
  • GENERATES: Is to be used when sourceComponent-A generates destComponent-B. Example: A SOURCE file makefile.mk generates a BINARY file a.out
  • HAS_PREREQUISITE: Is to be used when sourceComponent-A has as a prerequisite destComponent-B. Example: An APPLICATION foo.exe has prerequisite or dependency on bar.dll
  • METAFILE_OF: Is to be used when sourceComponent-A is a metafile of destComponent-B. Example: A SOURCE file pom.xml is a metafile of the APPLICATION Apache Xerces.
  • OPTIONAL_COMPONENT_OF: Is to be used when sourceComponent-A is an optional component of destComponent-B. Example: A SOURCE file fool.c (which is in the contributors directory) may or may not be included in the build of APPLICATION atthebar.
  • OPTIONAL_DEPENDENCY_OF: Is to be used when sourceComponent-A is an optional dependency of destComponent-B. Example: Use when building the code will proceed even if a dependency cannot be found, fails to install, or is only installed on a specific platform. For example, A is in the optionalDependencies scope of npm project B.
  • OTHER: Is to be used for a relationship which has not been defined in the formal SPDX specification.
  • PACKAGE_OF: Is to be used when sourceComponent-A is used as a package as part of destComponent-B. Example: A Linux distribution contains an APPLICATION package gawk as part of the distribution MyLinuxDistro.
  • PATCH_APPLIED: Is to be used when sourceComponent-A is a patch file that has been applied to destComponent-B. Example: A SOURCE file foo.diff is a patch file that has been applied to SOURCE file foo-patched.c.
  • PATCH_FOR: Is to be used when sourceComponent-A is a patch file for (to be applied to) destComponent-B. Example: A SOURCE file foo.diff is a patch file for SOURCE file foo.c.
  • PREREQUISITE_FOR: Is to be used when sourceComponent-A is a prerequisite for destComponent-B. Example: A library bar.dll is a prerequisite or dependency for APPLICATION foo.exe
  • PROVIDED_DEPENDENCY_OF: Is to be used when sourceComponent-A is a to be provided dependency of destComponent-B. Example: A is in the provided scope of B in a Maven project, indicating that the project expects it to be provided, for instance, by the container or JDK.
  • REQUIREMENT_DESCRIPTION_FOR: Is to be used when sourceComponent-A describes, illustrates, or specifies a requirement statement for destComponent-B. Example: A PDF document that describes a list of disallowed licences to inherit in certain build-subtrees.
  • RUNTIME_DEPENDENCY_OF: Is to be used when sourceComponent-A is a dependency required for the execution of destComponent-B. Example: A is in the runtime scope of B in a Maven project.
  • SPECIFICATION_FOR: Is to be used when sourceComponent-A describes, illustrates, or defines a design specification for destComponent-B. Example: A UML diagram illustrating a directed requirement graph for a discernible set of software components in a software package.
  • STATIC_LINK: Is to be used when sourceComponent-A statically links to destComponent-B. Example: An APPLICATION file myapp statically links to BINARY zlib.a.
  • TEST_CASE_OF: Is to be used when sourceComponent-A is a test case used in testing destComponent-B. Example: A SOURCE file testMyCode.java is a unit test file used to test an APPLICATION MyPackage.
  • TEST_DEPENDENCY_OF: Is to be used when sourceComponent-A is a test dependency of destComponent-B. Example: A is in the test scope of B in a Maven project.
  • TEST_OF: Is to be used when sourceComponent-A is used for testing destComponent-B. Example: Generic relationship for cases where it's clear that something is used for testing but unclear whether it's TEST_CASE_OF or TEST_TOOL_OF.
  • TEST_TOOL_OF: Is to be used when sourceComponent-A is used as a test tool for destComponent-B. Example: Any tool used to test the code such as ESlint.
  • VARIANT_OF: Is to be used when sourceComponent-A is a variant of (same lineage but not clear which came first) destComponent-B. Example: A SOURCE file makefile2.mk is a variant of SOURCE file makefile.mk if they differ by some edit, but there is no way to tell which came first (no reliable date information).

This page was generated: 2024-11-06