Open Source Governance & Licensing

Can public-domain code be used commercially? Four checks using the SAX notice

Can Public Domain Code Be Directly Commercialized? Verifying Four Points with the SAX Declaration Example

When a component is labeled as Public Domain (public domain), it can be an important reference for rights review. However, this cannot alone guarantee that the entire software package is risk-free in any global use case. The public domain description indicates the legal status of the work but does not provide a blanket license covering all content and rights.

What does the SAX declaration establish?

The SPDX includes the SAX-PD text, which contains David Megginson's May 11, 1998 declaration for SAX 1.0 and a subsequent declaration for SAX 2.0. The text expresses intent to place the content in the public domain and allow commercial and non-commercial use.

Companies need to verify that the deliverables are indeed the version and files specified by the declaration, and whether they contain other implementations, subsequent contributions, or third-party dependencies. Just because a name includes 'SAX' does not mean all releases under this name apply to the same declaration.

Why it does not waive every right worldwide

Different jurisdictions have different rules regarding right abandonment, protection periods, and non-assignable rights. Creative Commons therefore includes a fallback license in CC0 when rights abandonment is invalid, clearly stating that patents, trademarks, and other third-party rights will not automatically be cleared. The CC0 mechanism cannot prove that any other public domain declaration has the same effect.

This does not mean that public domain code cannot be used, but conclusions should be based on specific data to avoid treating all reviews with a single label.

Four evidence sets for customer review

  1. Specific Object: Component name, version, download source, file list, and hash, explaining which files are included in the final product.
  2. Original Declaration: Project accompanying text, headers, and traceable sources; retain the date of acquisition to explain the relationship between declarations and actual documents.
  3. Mixed Content: List dependencies, subsequent modifications, and third-party code, verify each license individually without extending top-level labels to all content.
  4. Scope of Use: Explain the distribution regions for products, delivery methods, and whether patents, trademarks, or other rights require additional confirmation.

For example, a reasonable response to explaining SAX entries should show the relationship between 'specific version—declaration—file range—actual use', rather than just replying with 'Public Domain without restrictions'. When data is missing, first fill in the source or contact the rights holder; if components are changed, recheck their dependencies and licenses.

Software Composition Analysis (SCA) can assist in identifying files, components, and license clues. Ultimately, conclusions still need to be reviewed against the actual delivery package and applicable jurisdictions.

Back to insights