What guidance, main topics and best practices should be followed to write an open source software publication policy?

Short answer

An open source software (OSS) publication policy — also called an “outbound open source policy” — defines who can release code, under what conditions, following which approval steps, and with which legal and technical safeguards. All three sectors (corporate, public sector, academic) share the same structural backbone — scope, licence selection, IP/copyright clearance, security checks, repository hygiene, and governance — but the drivers, default licences, approval chains, and reuse obligations differ substantially between them.

Detailed explanation

Why you need a publication policy at all

Copyright law assigns ownership of software to the employer by default (see for example Article 69b of the German Copyright Act, and its equivalents across EU member states). This means that publishing code without a policy is either legally void or exposes the organisation to uncontrolled IP transfer, contract breaches, or export-control violations. A policy provides the authorisation chain and due-diligence record that allows developers to contribute or release code safely, while protecting both the employee and the organisation.

Beyond legal protection, a publication policy signals organisational maturity: it is the mechanism that moves an organisation from ad-hoc open source activity to deliberate, measurable engagement. The TODO Group’s outbound open source guide, which reflects practice across Intel, Google, Microsoft, Meta, Red Hat, and many others, describes this as progressing from “consumption” through “participation” and “contribution” to “leadership” — the publication policy is the artefact that enables the step from passive use to active contribution and release.

Core topics every publication policy must address

Regardless of sector, a publication policy should cover the following domains, roughly in the order a release decision would follow:

1. Scope and objectives

State what the policy covers (contributions to existing upstream projects, greenfield project releases, or both), what organisational units and legal entities are in scope, and what the overarching motivation is (developer productivity, strategic influence, talent, digital sovereignty, research dissemination, etc.). Without a clear scope, the policy is applied inconsistently.

2. Approval process and governance

Define who can authorise a release. The TODO Group’s guide recommends placing decision authority with the unit that financed the development, involving other units as stakeholders only when code or IP was co-developed or co-funded. It distinguishes a “lean” procedure for routine contributions from a full approval chain for new project releases that involves Legal, IP/Patent review, and Export Control and Customs (ECC). For frequent upstream contributors, lighter-weight models (small-contributions model, major-to-major release model, full trust model) should be defined so that process overhead does not create an incentive for private forking.

3. Intellectual property and copyright clearance

Before any release, the policy must require a check that: (a) all code was developed under the authorisation of the publishing entity; (b) no third-party IP (vendor code, contractor code, code from other projects) is included without proper rights; and (c) copyright notices are correctly attributed. The REUSE specification (maintained by the Free Software Foundation Europe, FSFE) provides a machine-readable, SPDX-based standard for declaring per-file copyright and licence information, and has been adopted by the Linux Kernel, KDE, Nextcloud, SAP, the German Aerospace Center and many others. REUSE Specification 3.3 and tool v5.0.0 were released in November 2024 and are the current standard. Use of the REUSE tool in a CI/CD pipeline makes compliance verifiable automatically.

4. Licence selection

The policy must specify which OSS licences may be used for outbound releases, and provide a decision framework for choosing between them, covering: (a) the project’s adoption goal (permissive licences such as Apache-2.0 or MIT for broad uptake, copyleft licences such as GPL-3.0 or EUPL-1.2 for contributor reciprocity); (b) ecosystem conventions (Apache License for Apache Foundation projects, LGPL for libraries, GPL for Linux kernel work); (c) business model compatibility (copyleft may conflict with embedding in proprietary products). The policy should maintain an approved licence list and a list of licences requiring additional review. SPDX identifiers should be used throughout for machine-readability.

5. Security review

Before any public release, the policy must require: scanning for credentials, API keys, access tokens, and internal-only references in the codebase; a dependency vulnerability scan (SCA); and an assessment of whether the code includes encryption or other export-controlled functionality that may require notification under applicable export regulations (e.g. the EU Dual Use Regulation or, for US-nexus projects, the EAR). Most modern code-hosting platforms (GitHub, GitLab) provide secret-scanning as a built-in feature and it should be enabled for all public repositories. The OpenSSF Best Practices Badge (formerly CII Best Practices Badge) provides a structured checklist for project security hygiene and is widely cited as a quality benchmark.

6. Contributor agreement model (inbound to your project)

When your organisation publishes a project and accepts external contributions, the policy must define whether contributions are accepted under an “inbound=outbound” model (same licence as the project), a Developer Certificate of Origin (DCO), or a Contributor License Agreement (CLA). DCO is lighter-weight (a per-commit signed-off attestation, no contract to sign or maintain) and lower-barrier for contributors. CLA provides the project with additional rights (e.g. relicensing), but requires legal review and significantly increases administrative overhead for contributors, especially from large organisations. The policy should provide rationale for the chosen approach and, if CLA is selected, should document the process for managing corporate CLAs across affiliates.

7. Repository hygiene and community health files

Every published repository should contain a minimum set of “health files”: README.md (project description, install/use instructions), LICENSE (full licence text), CONTRIBUTING.md (how to contribute), CODE-OF-CONDUCT.md, GOVERNANCE.md, SECURITY.md (vulnerability disclosure process), and SUPPORT.md. Repository linters (such as the TODO Group’s repolinter) can enforce these automatically in CI/CD. The policy should specify required files, naming conventions, and badge requirements (REUSE compliant, OpenSSF badge). For public sector projects in Europe, publiccode.yml — a machine-readable metadata standard for public-sector software — should also be required.

8. Project lifecycle and maintenance commitment

Releasing code without a sustainability plan is a common pitfall. The policy must require a documented commitment to the project lifecycle: planning/concept → active development → maintenance → end-of-life. It should define what “end-of-life” means for a published project and what communication is required toward the user community when a project is archived or abandoned. The TODO Group guide models this as four phases: Planning, Active, Mature/Maintenance, Obsolete/End-of-Life.

9. Community management and governance

For projects intended to attract external contributors, the policy should require: a Code of Conduct (the Contributor Covenant is the de facto standard), a defined governance model (benevolent dictator, committee, foundation governance), and a named community manager. For projects seeking broader neutrality and cross-organisation co-development, the policy should address whether to donate the project to an open source foundation (Eclipse Foundation, Linux Foundation, Apache Software Foundation, etc.) and at what lifecycle stage that makes sense.

10. Training and awareness

The policy must be accompanied by training so that developers understand copyright basics, licence obligations, the organisation’s rules, open source community norms, and how to handle conflicts between open source and employer interests. The TODO Group lists specific training topics including “working in public”, “dealing with conflicts of interest”, and “where to get internal support.”

11. Metrics and follow-up

The policy should specify what will be measured: number of releases, contributor growth, upstream merge rate, CHAOSS community health metrics, etc. The Goal-Question-Metric (GQM) approach used by the CHAOSS community is the practical standard. Metrics are used to justify continued investment and to monitor community health.

Differences by sector

Corporate

The primary drivers are competitive strategy, talent, developer productivity, upstream influence, and legal risk management. The approval chain is the critical variable: a policy must balance protection of business IP with enough process lightness that developers do not simply bypass it. The TODO Group’s guide explicitly warns that CLA overhead is often “an insurmountable barrier, especially for large corporations” and that excessive process drives private forks.

Key corporate-specific considerations:

  • Moonlighting / spare-time contributions need a separate policy track, since code developed outside working hours on unrelated projects may belong to the developer, not the employer (jurisdiction-dependent).
  • Export control is usually a real constraint; the policy must include an ECC check step.
  • Business model interaction (copyleft vs. permissive) is a strategic decision requiring Legal and Business sign-off.
  • Brand and trademark policy for the released project should be defined (who owns the name, what use requires permission).
  • Multiple legal entities (subsidiaries, affiliates) complicate CLA maintenance; corporate CLAs must cover all affiliates and be maintained over time.

Public sector

The primary drivers are digital sovereignty, interoperability, public money / public code accountability, and reuse across administrations. European policy is increasingly explicit: the EU Open Source Strategy 2020–2023 (reiterated in the 2026 EU Tech Sovereignty Package) establishes “share” and “contribute” as two of the six guiding principles for Commission software. The European Commission’s December 2021 Decision on Open Source Licensing sets EUPL-1.2 as the default licence for Commission software releases. The Interoperable Europe Act (Article 8.4) requires all public sector open-source solution portals to allow the use of the EUPL.

Key public sector-specific considerations:

  • Default licence: EUPL-1.2 is the recommended default across EU public sector entities. It is a copyleft licence compatible with the GPL, LGPL, and several others, produced in all EU official languages, and designed to be legally valid across EU jurisdictions.
  • publiccode.yml: All public sector projects should include this machine-readable metadata file (mandatory for Italian public administrations since 2020, increasingly expected across the EU) to enable discoverability in European software catalogues.
  • Procurement rules: In many EU member states, code developed by public contractors must be explicitly addressed in contract language to ensure the public body retains the right to release it as OSS. The policy must include guidance for procurement teams.
  • Default-to-open principle: Several national policies (France’s Mission Bothorel report, Italian guidelines on software acquisition and reuse, German Open Source Strategy) establish that publicly funded software should be open by default, with exceptions rather than the reverse.
  • Cross-administration reuse: The policy should align with national or European software catalogues (OSOR/Joinup, code.gouv.fr, Developers Italia) to maximise discoverability and reuse. publiccode.yml and REUSE compliance are both conditions for listing on many of these catalogues.
  • Security baselines: The 2026 EU Open Source Strategy sets a commitment to “common security baselines for Commission repositories: monitoring, vulnerabilities, licence compliance, and dependency risk.” Institutional publication policies should adopt equivalent baselines.

Academic

The primary drivers are open science mandates, research reproducibility, FAIR principles for research software (Findable, Accessible, Interoperable, Reusable), funder requirements, and career credit for software contributions. The tension with the Technology Transfer Office (TTO) is structural: TTOs are often oriented toward patents and commercialisation by default, so the publication policy must explicitly establish when openness is the correct outcome without requiring full TTO sign-off.

Key academic-specific considerations:

  • Funder mandates: Horizon Europe, the French National Open Science Plan, UK Research and Innovation (UKRI), and the NIH 2024 Public Access Policy all require or strongly encourage open publication of research software and data. The policy should align with the funder requirements that apply to the institution’s grant portfolio.
  • FAIR for Research Software (FAIR4RS): Research software should meet FAIR principles, which in practice means including an OSI-approved licence, publishing to a recognised repository (GitHub, GitLab, Zenodo), and providing persistent identifiers (DOI via Zenodo or institutional repository, SWHID via Software Heritage). Johns Hopkins OSPO, Georgia Tech OSPO, and others have published practical guidance on this.
  • IP and funding-source complexity: Software may involve multiple funders, collaborators from partner institutions, and contractors; the policy must address each scenario and clarify who holds the right to release. Trinity College Dublin’s OSPO implements the College’s IPR policy by advising on whether and how research software can be released given contractual and funding requirements, maintaining a broadly open default wherever feasible.
  • Citation and credit: Research software should be citable. The policy should require a CITATION.cff file (using the Citation File Format) or a Zenodo record. ORCiD identifiers for all contributors should be included. Some academic OSPOs now explicitly state that software contributions should count toward tenure and promotion criteria.
  • Spin-out interface: For projects with commercial potential, the policy must define the boundary between open release and commercial exploitation (e.g. dual-licensing, foundation donation, spin-out), and make the TTO a collaborator in that decision rather than a gatekeeper to all releases.

Common pitfalls

  • Treating the publication policy as a compliance checklist rather than an enabling tool — excessive approval steps push developers toward informal workarounds or private forks.
  • Writing a policy without defining who is responsible for reviewing and updating it (typical cadence: annual review, triggered by major regulatory or licence landscape changes).
  • Launching a project without a maintenance commitment or lifecycle plan, leaving users exposed when the organisation loses interest.
  • Forgetting transitive dependencies: the code you publish may incorporate third-party components under different licences; the policy must require a full SBOM (Software Bill of Materials) check, not just a check of first-party code.
  • In the public sector, failing to address procurement contracts — if the vendor retains the IP, the public body cannot release the code regardless of policy intent.
  • In academia, requiring TTO sign-off for all releases regardless of whether commercial potential exists, creating a bottleneck that discourages openness.
  • Neglecting to integrate security and credential scanning into the CI/CD pipeline — manual checks are inconsistently applied.

See also