Root.io

Root's Commitment to Open Source License Compliance and Software Transparency

At Root.io (“Root”), we understand the foundational role open-source software (OSS) plays in modern technology. We take our compliance responsibilities seriously, ensuring that all modifications, enhancements, and distributions of OSS remain fully compliant with licensing requirements. Our approach is designed to balance security, transparency, and usability for our customers.

Root operates under three primary compliance scenarios:

  1. Automated Security Patching with Backported Fixes (Paid Access)
  2. Facilitating Upgrades Using Unmodified Upstream Updates (Paid Access)
  3. Publishing Modified Container Images for Public Use (Free Access)

Each scenario requires specific steps to ensure compliance with OSS licensing, including source code availability, proper attribution, trademark considerations, and clear build instructions.

1. Automated Security Patching with Backported Fixes

How It Works

  • Root provides an automated patching service through our SaaS platform that applies backported security fixes directly to customer-owned container images.
  • Customers retain full control over their container images, while Root enhances security through targeted patching.
  • Root does not host or distribute customer container images—the Root service integrates with their existing environments.

Compliance Strategy

Source Code Availability

  • GPL-2.0: Root provides the patched source code upon request.
  • GPL-3.0: Root automatically makes patched source code available to any recipient.
  • MPL-2.0 / EPL-2.0: Source code for modified components is made available.
  • MIT, Apache, BSD: No distribution requirements, but Root maintains transparency.

Mode of Distribution

  • All applicable source code is hosted in a public GitHub repository and retained for at least three years.
  • Customers can request source code via the SaaS UI or customer support, with fulfillment within 10 business days.

Ensuring Transparency

  • The SaaS UI includes a compliance section that details licensing obligations and provides GitHub links.
  • Licensing notices are included in customer agreements and onboarding materials.
  • The Root compliance webpage provides an overview of our open-source policies.

Copyright & Trademark Considerations

  • Original copyright notices are preserved in patched components.
  • Root does not brand modified components as official upstream software to avoid trademark conflicts.
  • An attribution statement is included in all compliance documentation.

Build Instructions

To ensure transparency, Root provides:

  • Dockerfiles explaining how patches are applied.
  • Patch files documenting code modifications.
  • Step-by-step instructions for customers to recreate patched images if needed.
  • These materials are hosted in Root’s public GitHub repository.

2. Facilitating Upgrades Using Unmodified Upstream Updates

How It Works

  • Root enables customers to automatically upgrade container images by pulling the latest versions from official upstream repositories.
  • Root does not modify or redistribute upstream images; our service facilitates seamless, secure upgrades.

Compliance Strategy

Source Code Availability

  • Since Root does not modify these packages, no additional source code obligations apply.
  • Customers remain subject to the original upstream licensing terms.

Mode of Distribution

  • Root does not distribute images, so there is no additional compliance burden.
  • Customers are referred to the official upstream source repositories for licensing and source code access.

Ensuring Transparency

  • The SaaS UI includes a disclaimer stating that Root does not modify upstream packages.
  • Customers receive clear documentation linking to official upstream repositories.
  • The Root compliance webpage outlines our role in upstream software management.

3. Publishing Modified Container Images for Public Use

How It Works

  • Root publicly distributes modified container images that contain security patches and optimizations.
  • These images are hosted in public repositories such as Docker Hub and made available for community use.

Compliance Strategy

Source Code Availability

  • GPL-2.0: Source code is available upon request.
  • GPL-3.0: Root provides the full source code alongside the container image.
  • MPL-2.0 / EPL-2.0: Modified source components are publicly accessible.
  • MIT, Apache, BSD: No source distribution requirements, but Root provides full transparency.

Mode of Distribution

  • Bundled Source Code (If Required): For GPL-3.0, the modified source code is included within the container image.
  • On-Demand Access: A public compliance page provides access to source code for at least three years.
  • Public Repository Compliance: Each container repository (e.g., Docker Hub) includes a README with compliance details.

Ensuring Transparency

  • Inside the container image:
    • /licenses/ directory contains relevant OSS license texts.
    • /src/ directory includes source code for modified components.
  • On the public repository (e.g., Docker Hub README):
    • The README provides licensing information and links to source code.
  • On Root’s compliance page:
    • A dedicated page lists all publicly available images and corresponding source code.

Copyright & Trademark Considerations

  • All original copyright notices are retained inside modified images.
  • Trademark disclaimers are included to clarify that Root’s modifications are independent of the original software provider.
  • Example Disclaimer:
    • “This image is based on [original project] but is not endorsed by or affiliated with them.”

Build Instructions

To ensure full transparency, Root provides:

  • Dockerfiles outlining the build process.
  • Patch files documenting applied modifications.
  • Detailed instructions for reproducing the modified image.
  • All materials are publicly accessible in Root’s compliance GitHub repository.

Broader Compliance Commitments

  • Long-Term Transparency: Root retains compliance records and source code for at least three years.
  • Accessibility: Compliance documentation is available in the public compliance page and SaaS UI.
  • Best Practices: Root strongly recommends including Dockerfiles for all modified images, even when not legally required.

Conclusion

Root is committed to open-source integrity and compliance, ensuring that our patching and image distribution practices fully respect licensing requirements. By maintaining clear documentation, proper attribution, and source code availability, we help our customers and the broader community use open-source software with confidence.

For more details, visit our Terms & Conditions page or explore our GitHub Repository for access to source code and build instructions.

3/24/25 Revision