Open Source, Licensing, and the Linux Ecosystem

1. Open source is defined by rights, not price

Open-source licenses grant rights to inspect, use, modify, and redistribute source code under stated conditions. Software can be open source and sold commercially. Conversely, software can be free of charge while remaining proprietary.

2. Common license families

License compatibility depends on the exact license versions, linking or combination model, modifications, and how software is conveyed. Do not infer obligations from the family name alone.

3. Linux systems contain many licenses

The Linux kernel is distributed under GPL-2.0-only, with important project-specific interpretation and exception details documented by the kernel project. User space is a mixture: GNU tools commonly use GPL or LGPL licenses, while OpenSSH, systemd, container runtimes, libraries, language tools, and vendor agents use other terms.

flowchart TB
  A["Application or service"] --> D["Direct dependencies"]
  D --> T["Transitive dependencies"]
  A --> B["Base image and operating-system packages"]
  B --> K["Host kernel interfaces"]
  D --> L["Licenses, notices, and source obligations"]
  T --> L
  B --> L
  L --> R["Release review and evidence"]

4. Upstream, downstream, communities, and vendors

Healthy operations depend on this flow in both directions: downstreams consume upstream work, and responsible teams report fixes and evidence back to the projects they rely on.

5. Practical obligations in a DevOps pipeline

• Preserve required copyright notices and license texts.
• Track modifications to covered components where required.
• Provide corresponding source or a valid offer when applicable.
• Observe attribution, NOTICE-file, patent, and trademark terms.
• Review redistribution rules for container images, installers, appliances, and downloadable artifacts.
• Keep third-party component records reproducible for each released version.

6. SBOM, provenance, and license evidence

A software bill of materials records component identities and versions. License metadata adds declared and detected licenses. Build provenance connects those components to a specific build. Together, they support review, vulnerability response, customer evidence, and repeatable releases.

7. Inspect license information on Linux

Package metadata and installed documentation are useful starting points, although they do not replace a complete product-level review.

# Search common installed documentation locations
find /usr/share/doc -maxdepth 2 \
  \( -iname 'copyright' -o -iname 'license*' -o -iname 'copying*' \) \
  2>/dev/null | head -n 20

# Debian-family examples
if command -v dpkg-query >/dev/null 2>&1; then
  dpkg-query -W -f='${Package}\t${Version}\n' bash coreutils
  sed -n '1,80p' /usr/share/doc/bash/copyright 2>/dev/null || true
fi

# RPM-family examples
if command -v rpm >/dev/null 2>&1; then
  rpm -q --qf '%{NAME}\t%{VERSION}-%{RELEASE}\t%{LICENSE}\n' bash coreutils
fi

# Kernel source license identifier when headers/source are available
find /usr/src -maxdepth 3 -name COPYING -print 2>/dev/null | head

8. Hands-on lab: create a small package license inventory

lab="$HOME/devops-academy/linux/chapter01/lesson04"
mkdir -p "$lab"
cd "$lab"

{
  printf 'component\tversion\tdeclared-license-or-evidence\n'

  if command -v dpkg-query >/dev/null 2>&1; then
    for pkg in bash coreutils grep sed; do
      version=$(dpkg-query -W -f='${Version}' "$pkg" 2>/dev/null || printf 'not-installed')
      evidence="/usr/share/doc/$pkg/copyright"
      printf '%s\t%s\t%s\n' "$pkg" "$version" "$evidence"
    done
  elif command -v rpm >/dev/null 2>&1; then
    for pkg in bash coreutils grep sed; do
      rpm -q --qf '%{NAME}\t%{VERSION}-%{RELEASE}\t%{LICENSE}\n' "$pkg" 2>/dev/null || true
    done
  else
    printf 'No dpkg or rpm database detected.\n'
  fi
} > license-inventory.tsv

column -t -s $'\t' license-inventory.tsv 2>/dev/null || cat license-inventory.tsv

9. Common licensing mistakes

10. Knowledge check

11. Summary

Linux systems are supply chains of independently licensed components. Open source concerns granted rights and conditions, not simply price or visible code. DevOps teams should preserve component identity, license evidence, notices, source obligations, and build provenance as part of governed delivery.

12. Further reading

• Open Source Initiative — Open Source Definition and approved licenses.
• SPDX specification and license list — standardized component and license identifiers.
• Linux kernel licensing rules and the kernel COPYING file.
• GNU license documentation — GPL, LGPL, and related guidance.
• Apache License 2.0, MIT License, BSD licenses, and Mozilla Public License 2.0 official texts.