View Source

This work is licensed under CC BY-SA 4.0
<p>As the term “<a href="#Licence" title="Licence: Legal instrument granting permissions to use, modify, or distribute copyrighted or patented software. It sets obligations like attribution or source code provision for the licensee, without transferring ownership from the copyright holder. The US spelling and the verb in both UK and US English is license, which also appears in licence names and acronyms.">licence</a>” (and its US counterpart “license”) is extensively used in the below descriptions, it is not cross-referenced. Other frequently used terms include <a href="#Copyright" title="Copyright: Legal IP protection granting exclusive rights to reproduce, distribute, and modify a work. It covers the source code, not the underlying ideas or functionality. Most OSS licences are based on copyright, which is distinct from a creator's moral rights.">copyright</a>, <a href="#Source Code" title="Source Code: Human-readable form of software that is often compiled into binaries. It is the primary IP asset protected by copyright, and required for OSS status.">source code</a>, <a href="#Distribution" title="Distribution: Providing software to third parties, triggering licence compliance obligations such as providing source code or maintaining notice retention.">distribution</a>, <a href="#Compliance" title="Compliance: Adherence to licence, patent, and security requirements. Requires maintaining compatibility and compliance artefacts. It may include notice retention and source code provision. Often guided by standards like OpenChain. Reviews may trigger remediation.">compliance</a>, <a href="#Dependency" title="Dependency: External component, library, or source code used by software, including both direct and transitive dependencies. Each typically carries an in-licence, and should be recorded in the dependency inventory or SBOM.">dependency</a>, and <a href="#OSS" title="OSS – Open Source Software: Software under licences recognised by the OSI or FSF that grant rights to use, modify, and distribute source code. It is often referred to as FOSS (or FLOSS) to explicitly include free software principles. Usage of software and licences is guided by an organisation's IPR Policy, while an OSPO may promote adoption and manage strategy, contribution policies, and compliance.">OSS</a>.</p>

<dl>

<dt id="0BSD"><b>0BSD – Zero-Clause BSD</b></dt>
<dd><a href="#Public Domain" title="Public Domain: Works not protected by copyright, patent, or moral rights, due to expiration of IP protection or explicit waiver by the rights holder (e.g. via CC0 or Unlicense). In jurisdictions not recognising waivers, fallback permissive licences like 0BSD, Unlicense, or MIT-0 can be used.">Public domain</a>-equivalent <a href="#Permissive Licence" title="Permissive Licence: Licence allowing use, modification, and distribution with minimal obligations, such as preserving copyright and licence text, and without imposing the same licence on derivatives (e.g. MIT, BSD, Apache, ISC, Artistic, and PSFL). These generally allow sublicensing without requiring a CLA.">permissive licence</a> that does not require <a href="#Attribution" title="Attribution: Notice required by some licences (e.g. Apache, CC BY, and BSD) to preserve credit to original authors and contributors, reproduce the copyright statement, and indicate modifications.">attribution</a>, and is often preferred over <a href="#CC0" title="CC0 – Creative Commons Zero: Public-domain dedication waiving copyright and related rights. It includes a fallback permissive licence for jurisdictions where waivers of copyright or moral rights are not recognised, ensuring global usability of works.">CC0</a> for software due to specific legal wording regarding code.</dd>

<dt id="AGPL"><b>AGPL – GNU Affero General Public License</b></dt>
<dd><a href="#Strong Copyleft" title="Strong Copyleft: Licensing model requiring derivatives to remain under the same terms or licence (e.g. GPL, AGPL, EUPL, and CC BY-SA). SSPL is a strong copyleft source-available licence.">Strong copyleft</a> licence requiring <a href="#Source Code" title="Source Code: Human-readable form of software that is often compiled into binaries. It is the primary IP asset protected by copyright, and required for OSS status.">source code</a> disclosure to all users, even for networked or <a href="#Remote Use" title="Remote Use: Use of software over a network (e.g. Software as a Service), rather than running a local copy. In standard copyleft licences, this does not trigger distribution obligations, whereas network-protective licences (like AGPL) treat this interaction as a trigger for source code disclosure.">remote use</a> (e.g. as a service), thereby closing the <a href="#Cloud Gap" title="Cloud Gap / SaaS Loophole / ASP Loophole: Situation where accessing software as a service over a network (remote use) avoids triggering strong copyleft obligations, as it is not physically distributed. This allows service providers to modify OSS and offer it as a service without releasing source code. This is addressed by network-protective licences like the AGPL.">cloud gap</a>.</dd>

<dt id="Apache License"><b>Apache License</b></dt>
<dd><a href="#Permissive Licence" title="Permissive Licence: Licence allowing use, modification, and distribution with minimal obligations, such as preserving copyright and licence text, and without imposing the same licence on derivatives (e.g. MIT, BSD, Apache, ISC, Artistic, and PSFL). These generally allow sublicensing without requiring a CLA.">Permissive licence</a> with <a href="#Patent" title="Patent: Legal protection for inventions, designs, or processes, preventing unauthorised use or distribution for a fixed term. In OSS, patents are addressed via patent grants and retaliation clauses. In software, patents protect functionality or process, while copyright protects source code.">patent</a> protection, a <a href="#Patent Retaliation Clause" title="Patent Retaliation Clause: Licence term that serves as a defensive termination mechanism, revoking a licensee's rights and the patent grant if they initiate patent litigation against the project or its contributors, also deterring patent trolling (e.g. Apache License).">patent retaliation clause</a>, and <a href="#Patent Grant" title="Patent Grant: Permission to use patents associated with the software and its contributions, typically covering rights held by contributors. This provision is designed to reduce legal uncertainty for users and distributors.">patent grant</a> for <a href="#Licensee" title="Licensee: Individual or organisation granted specific rights to use or modify software under the terms of a licence.">licensees</a>. It requires a <a href="#NOTICE File" title="NOTICE File: File containing mandatory acknowledgements, attributions, and other licence-related notices required by out-licence and dependencies.">NOTICE file</a> for <a href="#Attribution" title="Attribution: Notice required by some licences (e.g. Apache, CC BY, and BSD) to preserve credit to original authors and contributors, reproduce the copyright statement, and indicate modifications.">attribution</a>.</dd>

<dt id="Artistic License"><b>Artistic License</b></dt>
<dd><a href="#Permissive Licence" title="Permissive Licence: Licence allowing use, modification, and distribution with minimal obligations, such as preserving copyright and licence text, and without imposing the same licence on derivatives (e.g. MIT, BSD, Apache, ISC, Artistic, and PSFL). These generally allow sublicensing without requiring a CLA.">Permissive licence</a> originating from the Perl ecosystem; version 2 clarifies terms and has <a href="#Compatibility" title="Compatibility: A shorthand for licence compatibility, which is the ability to combine or distribute software under different licences without violating their terms. For example, using MIT components within a GPL project, or Apache 2.0 code with GPL 3.0 as out-licence, require applying GPL to the combined work. It can be enhanced through dual and multi-licensing.">compatibility</a> with <a href="#GPL" title="GPL – GNU General Public License: Strong copyleft licence requiring derivatives to use the same licence. Versions 2.0 and 3.0 are not mutually compatible. The latter addresses the IoT gap.">GPL</a>.</dd>

<dt id="Attribution"><b>Attribution</b></dt>
<dd>Notice required by some licences (e.g. <a href="#Apache License" title="Apache License: Permissive licence with patent protection, a patent retaliation clause, and patent grant for licensees. It requires a NOTICE file for attribution.">Apache</a>, <a href="#CC BY" title="CC BY – Creative Commons Attribution: Licence allowing reuse and modification, including commercial use, with mandatory attribution and no restrictions on derivatives.">CC BY</a>, and <a href="#BSD License" title="BSD License: Berkeley Software Distribution family of permissive licences with minimal distribution conditions, requiring retention of attribution notices.">BSD</a>) to preserve credit to original authors and <a href="#Contribution" title="Contribution: Any source code or documentation artefacts submitted to a project, typically governed by a CLA or DCO, forming part of the project's copyright and licensing framework while respecting the contributor's moral rights. See Upstream.">contributors</a>, reproduce the <a href="#Copyright" title="Copyright: Legal IP protection granting exclusive rights to reproduce, distribute, and modify a work. It covers the source code, not the underlying ideas or functionality. Most OSS licences are based on copyright, which is distinct from a creator's moral rights.">copyright</a> statement, and indicate modifications.</dd>

<dt id="AUTHORS File"><b>AUTHORS File</b></dt>
<dd>Lists original authors and primary <a href="#Contribution" title="Contribution: Any source code or documentation artefacts submitted to a project, typically governed by a CLA or DCO, forming part of the project's copyright and licensing framework while respecting the contributor's moral rights. See Upstream.">contributors</a> for <a href="#Attribution" title="Attribution: Notice required by some licences (e.g. Apache, CC BY, and BSD) to preserve credit to original authors and contributors, reproduce the copyright statement, and indicate modifications.">attribution</a> and historical reference; <a href="#Contribution" title="Contribution: Any source code or documentation artefacts submitted to a project, typically governed by a CLA or DCO, forming part of the project's copyright and licensing framework while respecting the contributor's moral rights. See Upstream.">contributor</a> identities can be linked to emails or <a href="#ORCID" title="ORCID – Open Researcher and Contributor ID: Persistent digital identifier uniquely distinguishing researchers and contributors. Often included in the AUTHORS file and CONTRIBUTORS file.">ORCID</a> identifiers.</dd>

<dt id="Binaries"><b>Binaries</b></dt>
<dd>Compiled executable files and other binary resources, as opposed to <a href="#Source Code" title="Source Code: Human-readable form of software that is often compiled into binaries. It is the primary IP asset protected by copyright, and required for OSS status.">source code</a>. In <a href="#Proprietary Software" title="Proprietary Software: Software distributed under highly restrictive terms (often in an EULA) limiting access, modification, or distribution, and typically sold as closed source software. It may involve trademarks, and be distributed as commercial software, freeware, or shareware.">proprietary software</a>, only the binaries are typically <a href="#Distribution" title="Distribution: Providing software to third parties, triggering licence compliance obligations such as providing source code or maintaining notice retention.">distributed</a>.</dd>

<dt id="BSD License"><b>BSD License</b></dt>
<dd>Berkeley Software Distribution family of <a href="#Permissive Licence" title="Permissive Licence: Licence allowing use, modification, and distribution with minimal obligations, such as preserving copyright and licence text, and without imposing the same licence on derivatives (e.g. MIT, BSD, Apache, ISC, Artistic, and PSFL). These generally allow sublicensing without requiring a CLA.">permissive licences</a> with minimal <a href="#Distribution" title="Distribution: Providing software to third parties, triggering licence compliance obligations such as providing source code or maintaining notice retention.">distribution</a> conditions, requiring retention of <a href="#Attribution" title="Attribution: Notice required by some licences (e.g. Apache, CC BY, and BSD) to preserve credit to original authors and contributors, reproduce the copyright statement, and indicate modifications.">attribution</a> notices.</dd>

<dt id="CC"><b>CC – Creative Commons</b></dt>
<dd>Family of licences (<a href="#CC BY" title="CC BY – Creative Commons Attribution: Licence allowing reuse and modification, including commercial use, with mandatory attribution and no restrictions on derivatives.">CC BY</a>, <a href="#CC BY-NC" title="CC BY-NC – Creative Commons Attribution-NonCommercial: Like CC BY but prohibiting commercial use; not an OSS licence due to usage restriction.">CC BY-NC</a>, <a href="#CC BY-NC-SA" title="CC BY-NC-SA – Creative Commons Attribution-NonCommercial-ShareAlike: Like CC BY-NC but requiring derivatives to use identical terms; copyleft equivalent with usage restriction.">CC BY-NC-SA</a>, <a href="#CC BY-ND" title="CC BY-ND – Creative Commons Attribution-NoDerivatives: Licence permitting distribution and commercial use, with attribution, but forbidding distribution of modified versions.">CC BY-ND</a>, and <a href="#CC BY-SA" title="CC BY-SA – Creative Commons Attribution-ShareAlike: Strong copyleft licence for content, requiring attribution and mandating that derivatives be distributed under identical terms. Similar to the GPL, but generally not compatible with software licences unless a specific compatibility clause (in version 4.0 for GPL 3.0) is invoked.">CC BY-SA</a>) and the <a href="#CC0" title="CC0 – Creative Commons Zero: Public-domain dedication waiving copyright and related rights. It includes a fallback permissive licence for jurisdictions where waivers of copyright or moral rights are not recognised, ensuring global usability of works.">CC0</a> <a href="#Public Domain" title="Public Domain: Works not protected by copyright, patent, or moral rights, due to expiration of IP protection or explicit waiver by the rights holder (e.g. via CC0 or Unlicense). In jurisdictions not recognising waivers, fallback permissive licences like 0BSD, Unlicense, or MIT-0 can be used.">public-domain</a> dedication for content, <a href="#Documentation Artefacts" title="Documentation Artefacts: Technical or user-facing documents distributed with software, such as README, LICENSE, NOTICE, CHANGELOG, and CONTRIBUTING files, typically following the software's licence. Some are covered by a documentation licence, which may differ from the software licence applied to the code.">documentation artefacts</a>, manuals, diagrams, and other materials that are not software.</dd>

<dt id="CC0"><b>CC0 – Creative Commons Zero</b></dt>
<dd><a href="#Public Domain" title="Public Domain: Works not protected by copyright, patent, or moral rights, due to expiration of IP protection or explicit waiver by the rights holder (e.g. via CC0 or Unlicense). In jurisdictions not recognising waivers, fallback permissive licences like 0BSD, Unlicense, or MIT-0 can be used.">Public-domain</a> dedication waiving <a href="#Copyright" title="Copyright: Legal IP protection granting exclusive rights to reproduce, distribute, and modify a work. It covers the source code, not the underlying ideas or functionality. Most OSS licences are based on copyright, which is distinct from a creator's moral rights.">copyright</a> and related rights. It includes a fallback <a href="#Permissive Licence" title="Permissive Licence: Licence allowing use, modification, and distribution with minimal obligations, such as preserving copyright and licence text, and without imposing the same licence on derivatives (e.g. MIT, BSD, Apache, ISC, Artistic, and PSFL). These generally allow sublicensing without requiring a CLA.">permissive licence</a> for jurisdictions where waivers of <a href="#Copyright" title="Copyright: Legal IP protection granting exclusive rights to reproduce, distribute, and modify a work. It covers the source code, not the underlying ideas or functionality. Most OSS licences are based on copyright, which is distinct from a creator's moral rights.">copyright</a> or <a href="#Moral Rights" title="Moral Rights: Personal, often non-transferable rights of creators to be named as the author (attribution), and to object to derogatory treatment of their work. These rights persist even if copyright is transferred to another entity.">moral rights</a> are not recognised, ensuring global usability of works.</dd>

<dt id="CC BY"><b>CC BY – Creative Commons Attribution</b></dt>
<dd>Licence allowing reuse and modification, including commercial use, with mandatory <a href="#Attribution" title="Attribution: Notice required by some licences (e.g. Apache, CC BY, and BSD) to preserve credit to original authors and contributors, reproduce the copyright statement, and indicate modifications.">attribution</a> and no restrictions on <a href="#Derivative" title="Derivative / Derivative Work: Work based on or incorporating an existing copyrighted work, including modified versions. Under copyleft, it must use the same or a compatible licence, whereas licences like CC BY-ND explicitly prohibit modifications.">derivatives</a>.</dd>

<dt id="CC BY-NC"><b>CC BY-NC – Creative Commons Attribution-NonCommercial</b></dt>
<dd>Like <a href="#CC BY" title="CC BY – Creative Commons Attribution: Licence allowing reuse and modification, including commercial use, with mandatory attribution and no restrictions on derivatives.">CC BY</a> but prohibiting commercial use; not an <a href="#OSS" title="OSS – Open Source Software: Software under licences recognised by the OSI or FSF that grant rights to use, modify, and distribute source code. It is often referred to as FOSS (or FLOSS) to explicitly include free software principles. Usage of software and licences is guided by an organisation's IPR Policy, while an OSPO may promote adoption and manage strategy, contribution policies, and compliance.">OSS</a> licence due to <a href="#Usage Restriction" title="Usage Restriction: Licence term limiting certain uses of the software, including military, nuclear, surveillance, or business models. Such restrictions (e.g. preventing commercial software distribution or remote use as a service) prevent a licence from qualifying as OSS or FOSS.">usage restriction</a>.</dd>

<dt id="CC BY-NC-SA"><b>CC BY-NC-SA – Creative Commons Attribution-NonCommercial-ShareAlike</b></dt>
<dd>Like <a href="#CC BY-NC" title="CC BY-NC – Creative Commons Attribution-NonCommercial: Like CC BY but prohibiting commercial use; not an OSS licence due to usage restriction.">CC BY-NC</a> but requiring <a href="#Derivative" title="Derivative / Derivative Work: Work based on or incorporating an existing copyrighted work, including modified versions. Under copyleft, it must use the same or a compatible licence, whereas licences like CC BY-ND explicitly prohibit modifications.">derivatives</a> to use identical terms; <a href="#Copyleft" title="Copyleft: Licensing principle requiring derivatives to remain under the same or a compatible licence, ensuring software freedom (e.g. GPL, AGPL). This is based on the principle of reciprocity.">copyleft</a> equivalent with <a href="#Usage Restriction" title="Usage Restriction: Licence term limiting certain uses of the software, including military, nuclear, surveillance, or business models. Such restrictions (e.g. preventing commercial software distribution or remote use as a service) prevent a licence from qualifying as OSS or FOSS.">usage restriction</a>.</dd>

<dt id="CC BY-ND"><b>CC BY-ND – Creative Commons Attribution-NoDerivatives</b></dt>
<dd>Licence permitting <a href="#Distribution" title="Distribution: Providing software to third parties, triggering licence compliance obligations such as providing source code or maintaining notice retention.">distribution</a> and commercial use, with <a href="#Attribution" title="Attribution: Notice required by some licences (e.g. Apache, CC BY, and BSD) to preserve credit to original authors and contributors, reproduce the copyright statement, and indicate modifications.">attribution</a>, but forbidding <a href="#Distribution" title="Distribution: Providing software to third parties, triggering licence compliance obligations such as providing source code or maintaining notice retention.">distribution</a> of modified versions.</dd>

<dt id="CC BY-SA"><b>CC BY-SA – Creative Commons Attribution-ShareAlike</b></dt>
<dd><a href="#Strong Copyleft" title="Strong Copyleft: Licensing model requiring derivatives to remain under the same terms or licence (e.g. GPL, AGPL, EUPL, and CC BY-SA). SSPL is a strong copyleft source-available licence.">Strong copyleft</a> licence for content, requiring <a href="#Attribution" title="Attribution: Notice required by some licences (e.g. Apache, CC BY, and BSD) to preserve credit to original authors and contributors, reproduce the copyright statement, and indicate modifications.">attribution</a> and mandating that <a href="#Derivative" title="Derivative / Derivative Work: Work based on or incorporating an existing copyrighted work, including modified versions. Under copyleft, it must use the same or a compatible licence, whereas licences like CC BY-ND explicitly prohibit modifications.">derivatives</a> be <a href="#Distribution" title="Distribution: Providing software to third parties, triggering licence compliance obligations such as providing source code or maintaining notice retention.">distributed</a> under identical terms. Similar to the <a href="#GPL" title="GPL – GNU General Public License: Strong copyleft licence requiring derivatives to use the same licence. Versions 2.0 and 3.0 are not mutually compatible. The latter addresses the IoT gap.">GPL</a>, but generally not <a href="#Compatibility" title="Compatibility: A shorthand for licence compatibility, which is the ability to combine or distribute software under different licences without violating their terms. For example, using MIT components within a GPL project, or Apache 2.0 code with GPL 3.0 as out-licence, require applying GPL to the combined work. It can be enhanced through dual and multi-licensing.">compatible</a> with software licences unless a specific <a href="#Compatibility" title="Compatibility: A shorthand for licence compatibility, which is the ability to combine or distribute software under different licences without violating their terms. For example, using MIT components within a GPL project, or Apache 2.0 code with GPL 3.0 as out-licence, require applying GPL to the combined work. It can be enhanced through dual and multi-licensing.">compatibility</a> clause (in version 4.0 for <a href="#GPL" title="GPL – GNU General Public License: Strong copyleft licence requiring derivatives to use the same licence. Versions 2.0 and 3.0 are not mutually compatible. The latter addresses the IoT gap.">GPL</a> 3.0) is invoked.</dd>

<dt id="CDDL"><b>CDDL – Common Development and Distribution License</b></dt>
<dd><a href="#Weak Copyleft" title="Weak Copyleft: Copyleft scheme used by LGPL, MPL, EPL, and CDDL, where the obligation to share modifications applies only to the specific source code files or libraries, not the entire application. This allows linking with differently licensed or proprietary software.">Weak copyleft</a> licence, mainly used for Java projects. It allows linking with <a href="#Proprietary Software" title="Proprietary Software: Software distributed under highly restrictive terms (often in an EULA) limiting access, modification, or distribution, and typically sold as closed source software. It may involve trademarks, and be distributed as commercial software, freeware, or shareware.">proprietary software</a>, but is not <a href="#Compatibility" title="Compatibility: A shorthand for licence compatibility, which is the ability to combine or distribute software under different licences without violating their terms. For example, using MIT components within a GPL project, or Apache 2.0 code with GPL 3.0 as out-licence, require applying GPL to the combined work. It can be enhanced through dual and multi-licensing.">compatible</a> with the <a href="#GPL" title="GPL – GNU General Public License: Strong copyleft licence requiring derivatives to use the same licence. Versions 2.0 and 3.0 are not mutually compatible. The latter addresses the IoT gap.">GPL</a>.</dd>

<dt id="CHANGELOG File"><b>CHANGELOG File / Changelog / Change Log</b></dt>
<dd>Record of notable changes between releases, relevant for licence <a href="#Compliance" title="Compliance: Adherence to licence, patent, and security requirements. Requires maintaining compatibility and compliance artefacts. It may include notice retention and source code provision. Often guided by standards like OpenChain. Reviews may trigger remediation.">compliance</a>. Often written in Markdown, with entries following <a href="#Semantic Versioning" title="Semantic Versioning: Standardised versioning scheme using MAJOR.MINOR.PATCH notation to communicate the scope of changes in software releases. Used in SBOM and CHANGELOG files.">semantic versioning</a> to indicate release levels and changes. See <a href="#HISTORY File" title="HISTORY File: Equivalent to a CHANGELOG file, used mainly in older Unix, BSD, or GNU projects to track changes over time.">HISTORY File</a>.</dd>

<dt id="CI"><b>CI – Continuous Integration</b></dt>
<dd>Automated build and test process for software changes. It often integrates <a href="#SCA" title="SCA – Software Composition Analysis: Automated detection of dependencies, licences, and vulnerabilities (often using CVE identifiers) to support compliance, risk assessment, and remediation. Tools may be integrated into CI or CI/CD and include snippet detection and snippet matching.">SCA</a> and other tools, providing immediate feedback on <a href="#Dependency" title="Dependency: External component, library, or source code used by software, including both direct and transitive dependencies. Each typically carries an in-licence, and should be recorded in the dependency inventory or SBOM.">dependencies</a> with <a href="#Vulnerability" title="Vulnerability: Security flaw in software code that can be exploited to cause harm, compromise data, or gain unauthorised access. SCA tools identify known vulnerabilities in dependencies (often mapping them to CVE lists) and flag them for remediation.">vulnerabilities</a> and licence <a href="#Compliance" title="Compliance: Adherence to licence, patent, and security requirements. Requires maintaining compatibility and compliance artefacts. It may include notice retention and source code provision. Often guided by standards like OpenChain. Reviews may trigger remediation.">compliance</a>.</dd>

<dt id="CI/CD"><b>CI/CD – Continuous Integration / Continuous Delivery</b></dt>
<dd>Automated pipeline covering <a href="#CI" title="CI – Continuous Integration: Automated build and test process for software changes. It often integrates SCA and other tools, providing immediate feedback on dependencies with vulnerabilities and licence compliance.">CI</a>, testing, and delivery of software to production or release environments. <a href="#SCA" title="SCA – Software Composition Analysis: Automated detection of dependencies, licences, and vulnerabilities (often using CVE identifiers) to support compliance, risk assessment, and remediation. Tools may be integrated into CI or CI/CD and include snippet detection and snippet matching.">SCA</a> can be applied to catch issues prior to deployment or release.</dd>

<dt id="CLA File"><b>CLA File – Contributor License Agreement</b></dt>
<dd>Agreement granting rights to use, modify, and manage <a href="#Contribution" title="Contribution: Any source code or documentation artefacts submitted to a project, typically governed by a CLA or DCO, forming part of the project's copyright and licensing framework while respecting the contributor's moral rights. See Upstream.">contributions</a>; may include <a href="#Copyright" title="Copyright: Legal IP protection granting exclusive rights to reproduce, distribute, and modify a work. It covers the source code, not the underlying ideas or functionality. Most OSS licences are based on copyright, which is distinct from a creator's moral rights.">copyright</a> transfer or <a href="#Sublicensing" title="Sublicensing: Allowing a licensee to pass on certain rights to a third party without transferring copyright or changing licence terms; permissive licences allow it, copyleft licences restrict it to the same terms, and commercial licences usually forbid it.">sublicensing</a> rights, and often requires signature.</dd>

<dt id="Closed Source Software"><b>Closed Source Software</b></dt>
<dd>Software <a href="#Distribution" title="Distribution: Providing software to third parties, triggering licence compliance obligations such as providing source code or maintaining notice retention.">distributed</a> without <a href="#Source Code" title="Source Code: Human-readable form of software that is often compiled into binaries. It is the primary IP asset protected by copyright, and required for OSS status.">source code</a> access or modification rights, unlike <a href="#OSS" title="OSS – Open Source Software: Software under licences recognised by the OSI or FSF that grant rights to use, modify, and distribute source code. It is often referred to as FOSS (or FLOSS) to explicitly include free software principles. Usage of software and licences is guided by an organisation's IPR Policy, while an OSPO may promote adoption and manage strategy, contribution policies, and compliance.">OSS</a> or <a href="#Source-Available" title="Source-Available: Licence or software with viewable source code that lacks full OSS freedoms due to restrictive terms (e.g. Elastic License, SSPL). Unlike Closed Source Software, the code is viewable and often modifiable, but the licence is fauxpen or contains usage restrictions that prevent it from being classified as OSS or FOSS.">source-available</a> software.</dd>

<dt id="Cloud Gap"><b>Cloud Gap / SaaS Loophole / ASP Loophole</b></dt>
<dd>Situation where accessing software as a service over a network (<a href="#Remote Use" title="Remote Use: Use of software over a network (e.g. Software as a Service), rather than running a local copy. In standard copyleft licences, this does not trigger distribution obligations, whereas network-protective licences (like AGPL) treat this interaction as a trigger for source code disclosure.">remote use</a>) avoids triggering <a href="#Strong Copyleft" title="Strong Copyleft: Licensing model requiring derivatives to remain under the same terms or licence (e.g. GPL, AGPL, EUPL, and CC BY-SA). SSPL is a strong copyleft source-available licence.">strong copyleft</a> obligations, as it is not physically <a href="#Distribution" title="Distribution: Providing software to third parties, triggering licence compliance obligations such as providing source code or maintaining notice retention.">distributed</a>. This allows service providers to modify <a href="#OSS" title="OSS – Open Source Software: Software under licences recognised by the OSI or FSF that grant rights to use, modify, and distribute source code. It is often referred to as FOSS (or FLOSS) to explicitly include free software principles. Usage of software and licences is guided by an organisation’s IPR Policy, while an OSPO may promote adoption and manage strategy, contribution policies, and compliance.">OSS</a> and offer it as a service without releasing <a href="#Source Code" title="Source Code: Human-readable form of software that is often compiled into binaries. It is the primary IP asset protected by copyright, and required for OSS status.">source code</a>. This is addressed by <a href="#Network-Protective Licence" title="Network-Protective Licence: Strong copyleft licences (such as the AGPL or SSPL) designed to close the cloud gap by treating use over a network (remote use) as distribution. This triggers the requirement to disclose the modified source code.">network-protective licences</a> like the <a href="#AGPL" title="AGPL – GNU Affero General Public License: Strong copyleft licence requiring source code disclosure to all users, even for networked or remote use (e.g. as a service), thereby closing the cloud gap.">AGPL</a>.</dd>

<dt id="CODE_OF_CONDUCT File"><b>CODE_OF_CONDUCT File / Code of Conduct</b></dt>
<dd>Document establishing standards for social and professional behaviour to ensure a safe, inclusive environment for all community participants. Unlike the <a href="#CONTRIBUTING File" title="CONTRIBUTING File: Describes the process, rules, and technical standards (e.g. coding conventions, testing requirements, and bug reporting) for contributions. It is distinct from the CODE_OF_CONDUCT File, which governs social behaviour. It also references legal conditions, such as copyright transfer via a CLA or DCO.">CONTRIBUTING file</a>’s focus on technical aspects of <a href="#Contribution" title="Contribution: Any source code or documentation artefacts submitted to a project, typically governed by a CLA or DCO, forming part of the project’s copyright and licensing framework while respecting the contributor’s moral rights. See Upstream.">contribution</a>, this governs social rules and conduct regarding etiquette and interaction.</dd>

<dt id="Commercial Licence"><b>Commercial Licence</b></dt>
<dd>Licence granting rights to use, modify, or <a href="#Distribution" title="Distribution: Providing software to third parties, triggering licence compliance obligations such as providing source code or maintaining notice retention.">distribute</a> software for commercial purposes, often under restrictive <a href="#Proprietary Software" title="Proprietary Software: Software distributed under highly restrictive terms (often in an EULA) limiting access, modification, or distribution, and typically sold as closed source software. It may involve trademarks, and be distributed as commercial software, freeware, or shareware.">proprietary software</a> terms, and typically requiring payment or authorisation. These licences typically define <a href="#Usage Restriction" title="Usage Restriction: Licence term limiting certain uses of the software, including military, nuclear, surveillance, or business models. Such restrictions (e.g. preventing commercial software distribution or remote use as a service) prevent a licence from qualifying as OSS or FOSS.">usage restrictions</a> not found in <a href="#OSS" title="OSS – Open Source Software: Software under licences recognised by the OSI or FSF that grant rights to use, modify, and distribute source code. It is often referred to as FOSS (or FLOSS) to explicitly include free software principles. Usage of software and licences is guided by an organisation’s IPR Policy, while an OSPO may promote adoption and manage strategy, contribution policies, and compliance.">OSS</a> licences.</dd>

<dt id="Commercial Software"><b>Commercial Software</b></dt>
<dd>Software sold or licensed for profit, typically under a <a href="#Commercial Licence" title="Commercial Licence: Licence granting rights to use, modify, or distribute software for commercial purposes, often under restrictive proprietary software terms, and typically requiring payment or authorisation. These licences typically define usage restrictions not found in OSS licences.">commercial licence</a> or other restrictive <a href="#Proprietary Software" title="Proprietary Software: Software distributed under highly restrictive terms (often in an EULA) limiting access, modification, or distribution, and typically sold as closed source software. It may involve trademarks, and be distributed as commercial software, freeware, or shareware.">proprietary software</a> terms. It may involve <a href="#Trademark" title="Trademark: Legally protected sign, name, logo, symbol, design, or other identifying mark distinguishing goods or services from those of others. In OSS, trademarks protect the identity and brand of the project, which is a form of IP separate from the code’s copyright.">trademarks</a> or follow an <a href="#Open Core" title="Open Core: Business model where core functionality is OSS, while add-ons with advanced features (enterprise security, monitoring) are proprietary software or source-available software.">Open Core</a> model, where proprietary features are built atop community <a href="#OSS" title="OSS – Open Source Software: Software under licences recognised by the OSI or FSF that grant rights to use, modify, and distribute source code. It is often referred to as FOSS (or FLOSS) to explicitly include free software principles. Usage of software and licences is guided by an organisation’s IPR Policy, while an OSPO may promote adoption and manage strategy, contribution policies, and compliance.">OSS</a> through <a href="#Dual and Multi-Licensing" title="Dual and Multi-Licensing: Distribution under alternative licences (e.g. GPL and commercial licence), including use of a secondary licence, allowing licensees to choose which applies. This in-licence must be compatible with the out-licence or subsuming licence. It enables offering software as strong copyleft, and as proprietary software to commercial vendors.">dual and multi-licensing</a>.</dd>

<dt id="Compatibility"><b>Compatibility</b></dt>
<dd>A shorthand for licence compatibility, which is the ability to combine or <a href="#Distribution" title="Distribution: Providing software to third parties, triggering licence compliance obligations such as providing source code or maintaining notice retention.">distribute</a> software under different licences without violating their terms. For example, using <a href="#MIT License" title="MIT License / X11 License: Simple permissive licence requiring attribution and notice retention, widely used for its brevity and compatibility.">MIT</a> components within a <a href="#GPL" title="GPL – GNU General Public License: Strong copyleft licence requiring derivatives to use the same licence. Versions 2.0 and 3.0 are not mutually compatible. The latter addresses the IoT gap.">GPL</a> project, or <a href="#Apache License" title="Apache License: Permissive licence with patent protection, a patent retaliation clause, and patent grant for licensees. It requires a NOTICE file for attribution.">Apache</a> 2.0 code with <a href="#GPL" title="GPL – GNU General Public License: Strong copyleft licence requiring derivatives to use the same licence. Versions 2.0 and 3.0 are not mutually compatible. The latter addresses the IoT gap.">GPL</a> 3.0 as <a href="#Out-Licence" title="Out-Licence / Outbound Licence: Licence applied to distributed software, which may differ from the in-licences of its dependencies. It defines the terms under which the downstream user can use the software.">out-licence</a>, require applying <a href="#GPL" title="GPL – GNU General Public License: Strong copyleft licence requiring derivatives to use the same licence. Versions 2.0 and 3.0 are not mutually compatible. The latter addresses the IoT gap.">GPL</a> to the combined work. It can be enhanced through <a href="#Dual and Multi-Licensing" title="Dual and Multi-Licensing: Distribution under alternative licences (e.g. GPL and commercial licence), including use of a secondary licence, allowing licensees to choose which applies. This in-licence must be compatible with the out-licence or subsuming licence. It enables offering software as strong copyleft, and as proprietary software to commercial vendors.">dual and multi-licensing</a>.</dd>

<dt id="Compliance"><b>Compliance</b></dt>
<dd>Adherence to licence, <a href="#Patent" title="Patent: Legal protection for inventions, designs, or processes, preventing unauthorised use or distribution for a fixed term. In OSS, patents are addressed via patent grants and retaliation clauses. In software, patents protect functionality or process, while copyright protects source code.">patent</a>, and security requirements. Requires maintaining <a href="#Compatibility" title="Compatibility: A shorthand for licence compatibility, which is the ability to combine or distribute software under different licences without violating their terms. For example, using MIT components within a GPL project, or Apache 2.0 code with GPL 3.0 as out-licence, require applying GPL to the combined work. It can be enhanced through dual and multi-licensing.">compatibility</a> and <a href="#Compliance Artefacts" title="Compliance Artefacts: Documentation artefacts or files required for licence adherence, such as LICENSE, NOTICE, and COPYRIGHT files. They include notice retention obligations to preserve copyright and licence notices in distributions.">compliance artefacts</a>. It may include <a href="#Notice Retention" title="Notice Retention: Requirement to preserve copyright, licence texts, and attribution notices in all (re)distributions of the software.">notice retention</a> and <a href="#Source Code" title="Source Code: Human-readable form of software that is often compiled into binaries. It is the primary IP asset protected by copyright, and required for OSS status.">source code</a> provision. Often guided by standards like <a href="#OpenChain" title="OpenChain: ISO/IEC standard for managing OSS in supply chains, providing guidelines for licence compliance, defining a core curriculum for OSS practices, and specifying conformance requirements for organisations.">OpenChain</a>. Reviews may trigger <a href="#Remediation" title="Remediation: Process of resolving identified issues in a software project, such as updating outdated dependencies with vulnerabilities, replacing incompatible licences or correcting missing notices, to restore compliance and reduce security or legal risk.">remediation</a>.</dd>

<dt id="Compliance Artefacts"><b>Compliance Artefacts</b></dt>
<dd><a href="#Documentation Artefacts" title="Documentation Artefacts: Technical or user-facing documents distributed with software, such as README, LICENSE, NOTICE, CHANGELOG, and CONTRIBUTING files, typically following the software’s licence. Some are covered by a documentation licence, which may differ from the software licence applied to the code.">Documentation artefacts</a> or files required for licence adherence, such as <a href="#LICENSE File" title="LICENSE File: File containing the full licence text, essential for legal compliance and distribution. See COPYING File.">LICENSE</a>, <a href="#NOTICE File" title="NOTICE File: File containing mandatory acknowledgements, attributions, and other licence-related notices required by out-licence and dependencies.">NOTICE</a>, and <a href="#COPYRIGHT File" title="COPYRIGHT File: Lists copyright holders and years, providing a clear ownership record, often with related legal notices, such as a warranty disclaimer.">COPYRIGHT</a> files. They include <a href="#Notice Retention" title="Notice Retention: Requirement to preserve copyright, licence texts, and attribution notices in all (re)distributions of the software.">notice retention</a> obligations to preserve <a href="#Copyright" title="Copyright: Legal IP protection granting exclusive rights to reproduce, distribute, and modify a work. It covers the source code, not the underlying ideas or functionality. Most OSS licences are based on copyright, which is distinct from a creator’s moral rights.">copyright</a> and licence notices in <a href="#Distribution" title="Distribution: Providing software to third parties, triggering licence compliance obligations such as providing source code or maintaining notice retention.">distributions</a>.</dd>

<dt id="CONTRIBUTING File"><b>CONTRIBUTING File</b></dt>
<dd>Describes the process, rules, and technical standards (e.g. coding conventions, testing requirements, and bug reporting) for <a href="#Contribution" title="Contribution: Any source code or documentation artefacts submitted to a project, typically governed by a CLA or DCO, forming part of the project’s copyright and licensing framework while respecting the contributor’s moral rights. See Upstream.">contributions</a>. It is distinct from the <a href="#CODE_OF_CONDUCT File" title="CODE_OF_CONDUCT File / Code of Conduct: Document establishing standards for social and professional behaviour to ensure a safe, inclusive environment for all community participants. Unlike the CONTRIBUTING file’s focus on technical aspects of contribution, this governs social rules and conduct regarding etiquette and interaction.">CODE_OF_CONDUCT file</a>, which governs social behaviour. It also references legal conditions, such as <a href="#Copyright" title="Copyright: Legal IP protection granting exclusive rights to reproduce, distribute, and modify a work. It covers the source code, not the underlying ideas or functionality. Most OSS licences are based on copyright, which is distinct from a creator’s moral rights.">copyright</a> transfer via a <a href="#CLA File" title="CLA File – Contributor License Agreement: Agreement granting rights to use, modify, and manage contributions; may include copyright transfer or sublicensing rights, and often requires signature.">CLA</a> or <a href="#DCO" title="DCO – Developer Certificate of Origin: Lightweight alternative to a CLA, confirmed by a contributor’s “Signed-off-by” line in source code commits.">DCO</a>.</dd>

<dt id="Contribution"><b>Contribution</b></dt>
<dd>Any <a href="#Source Code" title="Source Code: Human-readable form of software that is often compiled into binaries. It is the primary IP asset protected by copyright, and required for OSS status.">source code</a> or <a href="#Documentation Artefacts" title="Documentation Artefacts: Technical or user-facing documents distributed with software, such as README, LICENSE, NOTICE, CHANGELOG, and CONTRIBUTING files, typically following the software’s licence. Some are covered by a documentation licence, which may differ from the software licence applied to the code.">documentation artefacts</a> submitted to a project, typically governed by a <a href="#CLA File" title="CLA File – Contributor License Agreement: Agreement granting rights to use, modify, and manage contributions; may include copyright transfer or sublicensing rights, and often requires signature.">CLA</a> or <a href="#DCO" title="DCO – Developer Certificate of Origin: Lightweight alternative to a CLA, confirmed by a contributor’s “Signed-off-by” line in source code commits.">DCO</a>, forming part of the project’s <a href="#Copyright" title="Copyright: Legal IP protection granting exclusive rights to reproduce, distribute, and modify a work. It covers the source code, not the underlying ideas or functionality. Most OSS licences are based on copyright, which is distinct from a creator’s moral rights.">copyright</a> and <a href="#Licensing" title="Licensing: Governance of licence permissions, obligations, compliance artefacts, and dependency management; also granting permission to use intellectual property.">licensing</a> framework while respecting the contributor’s <a href="#Moral Rights" title="Moral Rights: Personal, often non-transferable rights of creators to be named as the author (attribution), and to object to derogatory treatment of their work. These rights persist even if copyright is transferred to another entity.">moral rights</a>. See <a href="#Upstream" title="Upstream: Original project or repository from which source code is derived or consumed. Downstream projects build upon it or distribute its code, potentially triggering licence obligations and compliance requirements. Upstream contributions provide fixes, enhancements, or new features back to the original source to benefit all users.">Upstream</a>.</dd>

<dt id="CONTRIBUTORS File"><b>CONTRIBUTORS File</b></dt>
<dd>Lists <a href="#Contribution" title="Contribution: Any source code or documentation artefacts submitted to a project, typically governed by a CLA or DCO, forming part of the project’s copyright and licensing framework while respecting the contributor’s moral rights. See Upstream.">contributors</a>; less common than <a href="#AUTHORS File" title="AUTHORS File: Lists original authors and primary contributors for attribution and historical reference; contributor identities can be linked to emails or ORCID identifiers.">AUTHORS file</a>, and used in large community-driven projects.</dd>

<dt id="COPYING File"><b>COPYING File</b></dt>
<dd>Traditional <a href="#GNU" title="GNU – “GNU’s Not Unix”: Project behind the GPL family of licences and a precursor to the Linux operating system, initiated by the FSF to develop a complete free software operating system.">GNU</a>-style filename, signalling adherence to traditional <a href="#Free Software" title="Free Software: Software that respects users’ essential freedoms, as defined by the FSF: the freedom to run the program for any purpose, to study and change the source code, and to distribute copies (original or modified). It is “Free” in FOSS and “Libre” in FLOSS, emphasising liberty over price.">free software</a> conventions. It is used to store the full text of the licence, usually the <a href="#GPL" title="GPL – GNU General Public License: Strong copyleft licence requiring derivatives to use the same licence. Versions 2.0 and 3.0 are not mutually compatible. The latter addresses the IoT gap.">GPL</a>, and is an equivalent to <a href="#LICENSE File" title="LICENSE File: File containing the full licence text, essential for legal compliance and distribution. See COPYING File.">LICENSE file</a>.</dd>

<dt id="Copyleft"><b>Copyleft</b></dt>
<dd><a href="#Licensing" title="Licensing: Governance of licence permissions, obligations, compliance artefacts, and dependency management; also granting permission to use intellectual property.">Licensing</a> principle requiring <a href="#Derivative" title="Derivative / Derivative Work: Work based on or incorporating an existing copyrighted work, including modified versions. Under copyleft, it must use the same or a compatible licence, whereas licences like CC BY-ND explicitly prohibit modifications.">derivatives</a> to remain under the same or a <a href="#Compatibility" title="Compatibility: A shorthand for licence compatibility, which is the ability to combine or distribute software under different licences without violating their terms. For example, using MIT components within a GPL project, or Apache 2.0 code with GPL 3.0 as out-licence, require applying GPL to the combined work. It can be enhanced through dual and multi-licensing.">compatible</a> licence, ensuring software freedom (e.g. <a href="#GPL" title="GPL – GNU General Public License: Strong copyleft licence requiring derivatives to use the same licence. Versions 2.0 and 3.0 are not mutually compatible. The latter addresses the IoT gap.">GPL</a>, <a href="#AGPL" title="AGPL – GNU Affero General Public License: Strong copyleft licence requiring source code disclosure to all users, even for networked or remote use (e.g. as a service), thereby closing the cloud gap.">AGPL</a>). This is based on the principle of <a href="#Reciprocity" title="Reciprocity: Principle requiring that rights granted under a licence (e.g. copyleft) must be extended to derivatives or distributed versions.">reciprocity</a>.</dd>

<dt id="Copyright"><b>Copyright</b></dt>
<dd>Legal <a href="#IP" title="IP – Intellectual Property: Creations of the mind protected by law through copyright, patents, trademarks, and design rights. A licence specifies how others may use such protected works.">IP</a> protection granting exclusive rights to reproduce, <a href="#Distribution" title="Distribution: Providing software to third parties, triggering licence compliance obligations such as providing source code or maintaining notice retention.">distribute</a>, and modify a work. It covers the <a href="#Source Code" title="Source Code: Human-readable form of software that is often compiled into binaries. It is the primary IP asset protected by copyright, and required for OSS status.">source code</a>, not the underlying ideas or functionality. Most <a href="#OSS" title="OSS – Open Source Software: Software under licences recognised by the OSI or FSF that grant rights to use, modify, and distribute source code. It is often referred to as FOSS (or FLOSS) to explicitly include free software principles. Usage of software and licences is guided by an organisation’s IPR Policy, while an OSPO may promote adoption and manage strategy, contribution policies, and compliance.">OSS</a> licences are based on copyright, which is distinct from a creator’s <a href="#Moral Rights" title="Moral Rights: Personal, often non-transferable rights of creators to be named as the author (attribution), and to object to derogatory treatment of their work. These rights persist even if copyright is transferred to another entity.">moral rights</a>.</dd>

<dt id="COPYRIGHT File"><b>COPYRIGHT File</b></dt>
<dd>Lists <a href="#Copyright Holder" title="Copyright Holder: Individual or entity owning exclusive rights to a work and granting permissions via a licence, typically identified in the COPYRIGHT file. See Copyright.">copyright holders</a> and years, providing a clear ownership record, often with related legal notices, such as a <a href="#Warranty Disclaimer" title="Warranty Disclaimer: Clause stating that the software is provided “as is” without guarantees of fitness or quality. It protects the copyright holder and contributors from liability and is typically included in the LICENSE file or COPYRIGHT file.">warranty disclaimer</a>.</dd>

<dt id="Copyright Holder"><b>Copyright Holder</b></dt>
<dd>Individual or entity owning exclusive rights to a work and granting permissions via a licence, typically identified in the <a href="#COPYRIGHT File" title="COPYRIGHT File: Lists copyright holders and years, providing a clear ownership record, often with related legal notices, such as a warranty disclaimer.">COPYRIGHT file</a>. See <a href="#Copyright" title="Copyright: Legal IP protection granting exclusive rights to reproduce, distribute, and modify a work. It covers the source code, not the underlying ideas or functionality. Most OSS licences are based on copyright, which is distinct from a creator’s moral rights.">Copyright</a>.</dd>

<dt id="CVE"><b>CVE – Common Vulnerabilities and Exposures</b></dt>
<dd>System for referencing specific security <a href="#Vulnerability" title="Vulnerability: Security flaw in software code that can be exploited to cause harm, compromise data, or gain unauthorised access. SCA tools identify known vulnerabilities in dependencies (often mapping them to CVE lists) and flag them for remediation.">vulnerabilities</a>. <a href="#SCA" title="SCA – Software Composition Analysis: Automated detection of dependencies, licences, and vulnerabilities (often using CVE identifiers) to support compliance, risk assessment, and remediation. Tools may be integrated into CI or CI/CD and include snippet detection and snippet matching.">SCA</a> tools map <a href="#Dependency" title="Dependency: External component, library, or source code used by software, including both direct and transitive dependencies. Each typically carries an in-licence, and should be recorded in the dependency inventory or SBOM.">dependencies</a> to CVE lists to assess risk.</dd>

<dt id="DCO"><b>DCO – Developer Certificate of Origin</b></dt>
<dd>Lightweight alternative to a <a href="#CLA File" title="CLA File – Contributor License Agreement: Agreement granting rights to use, modify, and manage contributions; may include copyright transfer or sublicensing rights, and often requires signature.">CLA</a>, confirmed by a <a href="#Contribution" title="Contribution: Any source code or documentation artefacts submitted to a project, typically governed by a CLA or DCO, forming part of the project’s copyright and licensing framework while respecting the contributor’s moral rights. See Upstream.">contributor</a>’s “Signed-off-by” line in <a href="#Source Code" title="Source Code: Human-readable form of software that is often compiled into binaries. It is the primary IP asset protected by copyright, and required for OSS status.">source code</a> commits.</dd>

<dt id="Defensive Termination"><b>Defensive Termination</b></dt>
<dd>Licence clause serving as a deterrent against <a href="#Patent Trolling" title="Patent Trolling: Asserting patents to obtain fees or settlements; addressed in some licences through patent retaliation clauses.">patent trolling</a> by automatically terminating a <a href="#Licensee" title="Licensee: Individual or organisation granted specific rights to use or modify software under the terms of a licence.">licensee’s</a> rights if they initiate <a href="#Patent" title="Patent: Legal protection for inventions, designs, or processes, preventing unauthorised use or distribution for a fixed term. In OSS, patents are addressed via patent grants and retaliation clauses. In software, patents protect functionality or process, while copyright protects source code.">patent</a> litigation against the project or its <a href="#Contribution" title="Contribution: Any source code or documentation artefacts submitted to a project, typically governed by a CLA or DCO, forming part of the project’s copyright and licensing framework while respecting the contributor’s moral rights. See Upstream.">contributors</a>. See <a href="#Patent Retaliation Clause" title="Patent Retaliation Clause: Licence term that serves as a defensive termination mechanism, revoking a licensee’s rights and the patent grant if they initiate patent litigation against the project or its contributors, also deterring patent trolling (e.g. Apache License).">Patent Retaliation Clause</a>.</dd>

<dt id="Dependency"><b>Dependency</b></dt>
<dd>External component, library, or <a href="#Source Code" title="Source Code: Human-readable form of software that is often compiled into binaries. It is the primary IP asset protected by copyright, and required for OSS status.">source code</a> used by software, including both <a href="#Direct Dependency" title="Direct Dependency: Library or component explicitly requested by the source code (e.g. listed in “package.json” or “requirements.txt”), as opposed to a transitive dependency which is pulled in by another dependency.">direct</a> and <a href="#Transitive Dependency" title="Transitive Dependency: Dependency of a dependency, as opposed to a direct dependency listed in the project configuration. Their tracking is essential for SCA, SBOM accuracy, and licence compliance, as they may bring additional in-licences.">transitive dependencies</a>. Each typically carries an <a href="#In-Licence" title="In-Licence / Inbound Licence: Licence of external components, libraries, or dependencies incorporated into a project, typically recorded in a dependency inventory or SBOM.">in-licence</a>, and should be recorded in the <a href="#Dependency Inventory" title="Dependency Inventory: Human-readable list of dependencies such as external libraries, frameworks, or essential tools, with versions and licences, often forming the basis for an SBOM.">dependency inventory</a> or <a href="#SBOM" title="SBOM – Software Bill of Materials: Machine-readable dependency inventory of components and their licences, including transitive dependencies, often in SPDX or CycloneDX format, and with semantic versioning and provenance. It supports compliance, risk assessment, and FAIR principles by improving the findability and reusability of information.">SBOM</a>.</dd>

<dt id="Dependency Inventory"><b>Dependency Inventory</b></dt>
<dd>Human-readable list of <a href="#Dependency" title="Dependency: External component, library, or source code used by software, including both direct and transitive dependencies. Each typically carries an in-licence, and should be recorded in the dependency inventory or SBOM.">dependencies</a> such as external libraries, frameworks, or essential tools, with versions and licences, often forming the basis for an <a href="#SBOM" title="SBOM – Software Bill of Materials: Machine-readable dependency inventory of components and their licences, including transitive dependencies, often in SPDX or CycloneDX format, and with semantic versioning and provenance. It supports compliance, risk assessment, and FAIR principles by improving the findability and reusability of information.">SBOM</a>.</dd>

<dt id="Derivative"><b>Derivative / Derivative Work</b></dt>
<dd>Work based on or incorporating an existing <a href="#Copyright" title="Copyright: Legal IP protection granting exclusive rights to reproduce, distribute, and modify a work. It covers the source code, not the underlying ideas or functionality. Most OSS licences are based on copyright, which is distinct from a creator’s moral rights.">copyrighted</a> work, including modified versions. Under <a href="#Copyleft" title="Copyleft: Licensing principle requiring derivatives to remain under the same or a compatible licence, ensuring software freedom (e.g. GPL, AGPL). This is based on the principle of reciprocity.">copyleft</a>, it must use the same or a <a href="#Compatibility" title="Compatibility: A shorthand for licence compatibility, which is the ability to combine or distribute software under different licences without violating their terms. For example, using MIT components within a GPL project, or Apache 2.0 code with GPL 3.0 as out-licence, require applying GPL to the combined work. It can be enhanced through dual and multi-licensing.">compatible</a> licence, whereas licences like <a href="#CC BY-ND" title="CC BY-ND – Creative Commons Attribution-NoDerivatives: Licence permitting distribution and commercial use, with attribution, but forbidding distribution of modified versions.">CC BY-ND</a> explicitly prohibit modifications.</dd>

<dt id="Direct Dependency"><b>Direct Dependency</b></dt>
<dd>Library or component explicitly requested by the <a href="#Source Code" title="Source Code: Human-readable form of software that is often compiled into binaries. It is the primary IP asset protected by copyright, and required for OSS status.">source code</a> (e.g. listed in “package.json” or “requirements.txt”), as opposed to a <a href="#Transitive Dependency" title="Transitive Dependency: Dependency of a dependency, as opposed to a direct dependency listed in the project configuration. Their tracking is essential for SCA, SBOM accuracy, and licence compliance, as they may bring additional in-licences.">transitive dependency</a> which is pulled in by another <a href="#Dependency" title="Dependency: External component, library, or source code used by software, including both direct and transitive dependencies. Each typically carries an in-licence, and should be recorded in the dependency inventory or SBOM.">dependency</a>.</dd>

<dt id="Distribution"><b>Distribution</b></dt>
<dd>Providing software to third parties, triggering licence <a href="#Compliance" title="Compliance: Adherence to licence, patent, and security requirements. Requires maintaining compatibility and compliance artefacts. It may include notice retention and source code provision. Often guided by standards like OpenChain. Reviews may trigger remediation.">compliance</a> obligations such as providing <a href="#Source Code" title="Source Code: Human-readable form of software that is often compiled into binaries. It is the primary IP asset protected by copyright, and required for OSS status.">source code</a> or maintaining <a href="#Notice Retention" title="Notice Retention: Requirement to preserve copyright, licence texts, and attribution notices in all (re)distributions of the software.">notice retention</a>.</dd>

<dt id="Documentation Artefacts"><b>Documentation Artefacts</b></dt>
<dd>Technical or user-facing documents <a href="#Distribution" title="Distribution: Providing software to third parties, triggering licence compliance obligations such as providing source code or maintaining notice retention.">distributed</a> with software, such as <a href="#README File" title="README File: Documentation artefact providing an overview of a project, installation, and usage; typically written in Markdown to ensure clear formatting and readability.">README</a>, <a href="#LICENSE File" title="LICENSE File: File containing the full licence text, essential for legal compliance and distribution. See COPYING File.">LICENSE</a>, <a href="#NOTICE File" title="NOTICE File: File containing mandatory acknowledgements, attributions, and other licence-related notices required by out-licence and dependencies.">NOTICE</a>, <a href="#CHANGELOG File" title="CHANGELOG File / Changelog / Change Log: Record of notable changes between releases, relevant for licence compliance. Often written in Markdown, with entries following semantic versioning to indicate release levels and changes. See HISTORY File.">CHANGELOG</a>, and <a href="#CONTRIBUTING File" title="CONTRIBUTING File: Describes the process, rules, and technical standards (e.g. coding conventions, testing requirements, and bug reporting) for contributions. It is distinct from the CODE_OF_CONDUCT file, which governs social behaviour. It also references legal conditions, such as copyright transfer via a CLA or DCO.">CONTRIBUTING</a> files, typically following the software’s licence. Some are covered by a <a href="#Documentation Licence" title="Documentation Licence: Licence covering non-code and often separate materials, such as manuals, diagrams, presentations, tutorials, wikis, or multimedia. Projects often use Creative Commons licences (e.g. CC BY or CC BY-SA) to facilitate sharing, updating, and translation.">documentation licence</a>, which may differ from the software licence applied to the code.</dd>

<dt id="Documentation Licence"><b>Documentation Licence</b></dt>
<dd>Licence covering non-code and often separate materials, such as manuals, diagrams, presentations, tutorials, wikis, or multimedia. Projects often use <a href="#CC" title="CC – Creative Commons: Family of licences (CC BY, CC BY-NC, CC BY-NC-SA, CC BY-ND, and CC BY-SA) and the CC0 public-domain dedication for content, documentation artefacts, manuals, diagrams, and other materials that are not software.">Creative Commons</a> licences (e.g. <a href="#CC BY" title="CC BY – Creative Commons Attribution: Licence allowing reuse and modification, including commercial use, with mandatory attribution and no restrictions on derivatives.">CC BY</a> or <a href="#CC BY-SA" title="CC BY-SA – Creative Commons Attribution-ShareAlike: Strong copyleft licence for content, requiring attribution and mandating that derivatives be distributed under identical terms. Similar to the GPL, but generally not compatible with software licences unless a specific compatibility clause (in version 4.0 for GPL 3.0) is invoked.">CC BY-SA</a>) to facilitate sharing, updating, and translation.</dd>

<dt id="Downstream"><b>Downstream</b></dt>
<dd>Any project, organisation, or user that consumes, integrates, or <a href="#Distribution" title="Distribution: Providing software to third parties, triggering licence compliance obligations such as providing source code or maintaining notice retention.">distributes</a> software from an <a href="#Upstream" title="Upstream: Original project or repository from which source code is derived or consumed. Downstream projects build upon it or distribute its code, potentially triggering licence obligations and compliance requirements. Upstream contributions provide fixes, enhancements, or new features back to the original source to benefit all users.">upstream</a> source. Downstream users inherit the <a href="#Compliance" title="Compliance: Adherence to licence, patent, and security requirements. Requires maintaining compatibility and compliance artefacts. It may include notice retention and source code provision. Often guided by standards like OpenChain. Reviews may trigger remediation.">compliance</a> obligations defined by the <a href="#Out-Licence" title="Out-Licence / Outbound Licence: Licence applied to distributed software, which may differ from the in-licences of its dependencies. It defines the terms under which the downstream user can use the software.">out-licence</a> of <a href="#Upstream" title="Upstream: Original project or repository from which source code is derived or consumed. Downstream projects build upon it or distribute its code, potentially triggering licence obligations and compliance requirements. Upstream contributions provide fixes, enhancements, or new features back to the original source to benefit all users.">upstream</a> software.</dd>

<dt id="Dual and Multi-Licensing"><b>Dual and Multi-Licensing</b></dt>
<dd><a href="#Distribution" title="Distribution: Providing software to third parties, triggering licence compliance obligations such as providing source code or maintaining notice retention.">Distribution</a> under alternative licences (e.g. <a href="#GPL" title="GPL – GNU General Public License: Strong copyleft licence requiring derivatives to use the same licence. Versions 2.0 and 3.0 are not mutually compatible. The latter addresses the IoT gap.">GPL</a> and <a href="#Commercial Licence" title="Commercial Licence: Licence granting rights to use, modify, or distribute software for commercial purposes, often under restrictive proprietary software terms, and typically requiring payment or authorisation. These licences typically define usage restrictions not found in OSS licences.">commercial licence</a>), including use of a <a href="#Secondary Licence" title="Secondary Licence: Alternative licence permitted by a primary licence to facilitate compatibility with other open source licences.">secondary licence</a>, allowing <a href="#Licensee" title="Licensee: Individual or organisation granted specific rights to use or modify software under the terms of a licence.">licensees</a> to choose which applies. This <a href="#In-Licence" title="In-Licence / Inbound Licence: Licence of external components, libraries, or dependencies incorporated into a project, typically recorded in a dependency inventory or SBOM.">in-licence</a> must be <a href="#Compatibility" title="Compatibility: A shorthand for licence compatibility, which is the ability to combine or distribute software under different licences without violating their terms. For example, using MIT components within a GPL project, or Apache 2.0 code with GPL 3.0 as out-licence, require applying GPL to the combined work. It can be enhanced through dual and multi-licensing.">compatible</a> with the <a href="#Out-Licence" title="Out-Licence / Outbound Licence: Licence applied to distributed software, which may differ from the in-licences of its dependencies. It defines the terms under which the downstream user can use the software.">out-licence</a> or <a href="#Subsuming Licence" title="Subsuming Licence: Licence that governs a combined work when incorporated dependencies impose conditions on the whole, similar to an out-licence but not necessarily implying distribution. “Subsuming into” means incorporating one work into a larger one so it becomes subject to that subsuming licence.">subsuming licence</a>. It enables offering software as <a href="#Strong Copyleft" title="Strong Copyleft: Licensing model requiring derivatives to remain under the same terms or licence (e.g. GPL, AGPL, EUPL, and CC BY-SA). SSPL is a strong copyleft source-available licence.">strong copyleft</a>, and as <a href="#Proprietary Software" title="Proprietary Software: Software distributed under highly restrictive terms (often in an EULA) limiting access, modification, or distribution, and typically sold as closed source software. It may involve trademarks, and be distributed as commercial software, freeware, or shareware.">proprietary software</a> to commercial vendors.</dd>

<dt id="Dynamic Linking"><b>Dynamic Linking</b></dt>
<dd>Linking external libraries at runtime rather than copying code into the executable. Critical for <a href="#Compliance" title="Compliance: Adherence to licence, patent, and security requirements. Requires maintaining compatibility and compliance artefacts. It may include notice retention and source code provision. Often guided by standards like OpenChain. Reviews may trigger remediation.">compliance</a> with <a href="#LGPL" title="LGPL – GNU Lesser General Public License: Weak copyleft licence permitting dynamic linking with differently licensed or proprietary software. Static linking is allowed if the user receives the source code and information required to rebuild the work with a modified version of the library.">LGPL</a>, as it simply allows the main application to remain <a href="#Proprietary Software" title="Proprietary Software: Software distributed under highly restrictive terms (often in an EULA) limiting access, modification, or distribution, and typically sold as closed source software. It may involve trademarks, and be distributed as commercial software, freeware, or shareware.">proprietary software</a>.</dd>

<dt id="Elastic License"><b>Elastic License</b></dt>
<dd><a href="#Source-Available" title="Source-Available: Licence or software with viewable source code that lacks full OSS freedoms due to restrictive terms (e.g. Elastic License, SSPL). Unlike Closed Source Software, the code is viewable and often modifiable, but the licence is fauxpen or contains usage restrictions that prevent it from being classified as OSS or FOSS.">Source-available licence</a> prohibiting offering the software as a managed service, and bypassing key protections; this <a href="#Usage Restriction" title="Usage Restriction: Licence term limiting certain uses of the software, including military, nuclear, surveillance, or business models. Such restrictions (e.g. preventing commercial software distribution or remote use as a service) prevent a licence from qualifying as OSS or FOSS.">usage restriction</a> makes it an exemplary <a href="#Fauxpen" title="Fauxpen: Software or licence presented as OSS but effectively controlled by the vendor, restricting true OSS freedoms (e.g. Elastic License or SSPL).">fauxpen</a>.</dd>

<dt id="EPL"><b>EPL – Eclipse Public License</b></dt>
<dd>Business-friendly <a href="#Weak Copyleft" title="Weak Copyleft: Copyleft scheme used by LGPL, MPL, EPL, and CDDL, where the obligation to share modifications applies only to the specific source code files or libraries, not the entire application. This allows linking with differently licensed or proprietary software.">weak copyleft</a> licence that applies <a href="#Copyleft" title="Copyleft: Licensing principle requiring derivatives to remain under the same or a compatible licence, ensuring software freedom (e.g. GPL, AGPL). This is based on the principle of reciprocity.">copyleft</a> terms only to the file level, allowing <a href="#Proprietary Software" title="Proprietary Software: Software distributed under highly restrictive terms (often in an EULA) limiting access, modification, or distribution, and typically sold as closed source software. It may involve trademarks, and be distributed as commercial software, freeware, or shareware.">proprietary software</a> to link to the <a href="#Source Code" title="Source Code: Human-readable form of software that is often compiled into binaries. It is the primary IP asset protected by copyright, and required for OSS status.">source code</a> under it, but incompatible with the <a href="#GPL" title="GPL – GNU General Public License: Strong copyleft licence requiring derivatives to use the same licence. Versions 2.0 and 3.0 are not mutually compatible. The latter addresses the IoT gap.">GPL</a>.</dd>

<dt id="EULA"><b>EULA – End User Licence Agreement</b></dt>
<dd><a href="#Proprietary Software" title="Proprietary Software: Software distributed under highly restrictive terms (often in an EULA) limiting access, modification, or distribution, and typically sold as closed source software. It may involve trademarks, and be distributed as commercial software, freeware, or shareware.">Proprietary software</a> licence defining rights and restrictions by which an end user may access and use the software.</dd>

<dt id="EUPL"><b>EUPL – European Union Public Licence</b></dt>
<dd>EU-approved <a href="#Copyleft" title="Copyleft: Licensing principle requiring derivatives to remain under the same or a compatible licence, ensuring software freedom (e.g. GPL, AGPL). This is based on the principle of reciprocity.">copyleft</a> licence designed for interoperability, <a href="#Compatibility" title="Compatibility: A shorthand for licence compatibility, which is the ability to combine or distribute software under different licences without violating their terms. For example, using MIT components within a GPL project, or Apache 2.0 code with GPL 3.0 as out-licence, require applying GPL to the combined work. It can be enhanced through dual and multi-licensing.">compatible</a> with various <a href="#OSS" title="OSS – Open Source Software: Software under licences recognised by the OSI or FSF that grant rights to use, modify, and distribute source code. It is often referred to as FOSS (or FLOSS) to explicitly include free software principles. Usage of software and licences is guided by an organisation’s IPR Policy, while an OSPO may promote adoption and manage strategy, contribution policies, and compliance.">OSS</a> licences like the <a href="#GPL" title="GPL – GNU General Public License: Strong copyleft licence requiring derivatives to use the same licence. Versions 2.0 and 3.0 are not mutually compatible. The latter addresses the IoT gap.">GPL</a>.</dd>

<dt id="FAIR"><b>FAIR</b></dt>
<dd>Findability, Accessibility, Interoperability, and Reusability; a set of guiding principles to improve data management in open science. In software, supported by elaborated <a href="#Documentation Artefacts" title="Documentation Artefacts: Technical or user-facing documents distributed with software, such as README, LICENSE, NOTICE, CHANGELOG, and CONTRIBUTING files, typically following the software’s licence. Some are covered by a documentation licence, which may differ from the software licence applied to the code.">documentation artefacts</a> and the <a href="#REUSE" title="REUSE: FSFE initiative defining standardised file headers, licence text and copyright notice placement, and metadata for automated compliance, aligning with FAIR principles through improved accessibility and interoperability of licensing information.">REUSE specification</a>.</dd>

<dt id="Fauxpen"><b>Fauxpen</b></dt>
<dd>Software or licence presented as <a href="#OSS" title="OSS – Open Source Software: Software under licences recognised by the OSI or FSF that grant rights to use, modify, and distribute source code. It is often referred to as FOSS (or FLOSS) to explicitly include free software principles. Usage of software and licences is guided by an organisation’s IPR Policy, while an OSPO may promote adoption and manage strategy, contribution policies, and compliance.">OSS</a> but effectively controlled by the vendor, restricting true <a href="#OSS" title="OSS – Open Source Software: Software under licences recognised by the OSI or FSF that grant rights to use, modify, and distribute source code. It is often referred to as FOSS (or FLOSS) to explicitly include free software principles. Usage of software and licences is guided by an organisation’s IPR Policy, while an OSPO may promote adoption and manage strategy, contribution policies, and compliance.">OSS</a> freedoms (e.g. <a href="#Elastic License" title="Elastic License: Source-available licence prohibiting offering the software as a managed service, and bypassing key protections; this usage restriction makes it an exemplary fauxpen.">Elastic License</a> or <a href="#SSPL" title="SSPL – Server Side Public License: Network-protective, strong copyleft, and source-available licence requiring release of service management layer source code when providing a service. Its additional obligations on the surrounding service stack make it fauxpen.">SSPL</a>).</dd>

<dt id="Fork"><b>Fork</b></dt>
<dd>Divergent development path based on a specific version of a project; often used to continue work from the last <a href="#OSS" title="OSS – Open Source Software: Software under licences recognised by the OSI or FSF that grant rights to use, modify, and distribute source code. It is often referred to as FOSS (or FLOSS) to explicitly include free software principles. Usage of software and licences is guided by an organisation’s IPR Policy, while an OSPO may promote adoption and manage strategy, contribution policies, and compliance.">OSS</a> version in response to <a href="#Relicensing" title="Relicensing: Changing a licence of existing software, often to improve compatibility or for commercial reasons; must comply with original licence or contributor consent. Relicensing to a fauxpen or commercial licence often results in a fork.">relicensing</a> to a <a href="#Proprietary Software" title="Proprietary Software: Software distributed under highly restrictive terms (often in an EULA) limiting access, modification, or distribution, and typically sold as closed source software. It may involve trademarks, and be distributed as commercial software, freeware, or shareware.">proprietary software</a> licence, or to prepare an <a href="#Upstream" title="Upstream: Original project or repository from which source code is derived or consumed. Downstream projects build upon it or distribute its code, potentially triggering licence obligations and compliance requirements. Upstream contributions provide fixes, enhancements, or new features back to the original source to benefit all users.">upstream</a> <a href="#Contribution" title="Contribution: Any source code or documentation artefacts submitted to a project, typically governed by a CLA or DCO, forming part of the project’s copyright and licensing framework while respecting the contributor’s moral rights. See Upstream.">contribution</a> back to the original project.</dd>

<dt id="FOSS"><b>FOSS – Free and Open Source Software / FLOSS</b></dt>
<dd>Software meeting <a href="#Free Software" title="Free Software: Software that respects users’ essential freedoms, as defined by the FSF: the freedom to run the program for any purpose, to study and change the source code, and to distribute copies (original or modified). It is “Free” in FOSS and “Libre” in FLOSS, emphasising liberty over price.">free software</a> criteria set by the <a href="#FSF" title="FSF – Free Software Foundation: Organisation maintaining GNU and the free software definition, advocating for user freedoms, and publishing the GPL family of licences.">FSF</a>; FOSS licences are a subset of <a href="#OSS" title="OSS – Open Source Software: Software under licences recognised by the OSI or FSF that grant rights to use, modify, and distribute source code. It is often referred to as FOSS (or FLOSS) to explicitly include free software principles. Usage of software and licences is guided by an organisation’s IPR Policy, while an OSPO may promote adoption and manage strategy, contribution policies, and compliance.">OSS</a> licences. In FLOSS, L stands for <em>libre</em> to emphasise freedom rather than price.</dd>

<dt id="Free Software"><b>Free Software</b></dt>
<dd>Software that respects users’ essential freedoms, as defined by the <a href="#FSF" title="FSF – Free Software Foundation: Organisation maintaining GNU and the free software definition, advocating for user freedoms, and publishing the GPL family of licences.">FSF</a>: the freedom to run the program for any purpose, to study and change the <a href="#Source Code" title="Source Code: Human-readable form of software that is often compiled into binaries. It is the primary IP asset protected by copyright, and required for OSS status.">source code</a>, and to <a href="#Distribution" title="Distribution: Providing software to third parties, triggering licence compliance obligations such as providing source code or maintaining notice retention.">distribute</a> copies (original or modified). It is “Free” in <a href="#FOSS" title="FOSS – Free and Open Source Software / FLOSS: Software meeting free software criteria set by the FSF; FOSS licences are a subset of OSS licences. In FLOSS, L stands for libre to emphasise freedom rather than price.">FOSS</a> and “Libre” in <a href="#FOSS" title="FOSS – Free and Open Source Software / FLOSS: Software meeting free software criteria set by the FSF; FOSS licences are a subset of OSS licences. In FLOSS, L stands for libre to emphasise freedom rather than price.">FLOSS</a>, emphasising liberty over price.</dd>

<dt id="Freeware"><b>Freeware</b></dt>
<dd><a href="#Proprietary Software" title="Proprietary Software: Software distributed under highly restrictive terms (often in an EULA) limiting access, modification, or distribution, and typically sold as closed source software. It may involve trademarks, and be distributed as commercial software, freeware, or shareware.">Proprietary software</a> available at no cost, but without the freedoms to modify or <a href="#Distribution" title="Distribution: Providing software to third parties, triggering licence compliance obligations such as providing source code or maintaining notice retention.">distribute</a> <a href="#Source Code" title="Source Code: Human-readable form of software that is often compiled into binaries. It is the primary IP asset protected by copyright, and required for OSS status.">source code</a> inherent to <a href="#Free Software" title="Free Software: Software that respects users’ essential freedoms, as defined by the FSF: the freedom to run the program for any purpose, to study and change the source code, and to distribute copies (original or modified). It is “Free” in FOSS and “Libre” in FLOSS, emphasising liberty over price.">free software</a> or <a href="#OSS" title="OSS – Open Source Software: Software under licences recognised by the OSI or FSF that grant rights to use, modify, and distribute source code. It is often referred to as FOSS (or FLOSS) to explicitly include free software principles. Usage of software and licences is guided by an organisation’s IPR Policy, while an OSPO may promote adoption and manage strategy, contribution policies, and compliance.">OSS</a>.</dd>

<dt id="FSF"><b>FSF – Free Software Foundation</b></dt>
<dd>Organisation maintaining <a href="#GNU" title="GNU – “GNU’s Not Unix”: Project behind the GPL family of licences and a precursor to the Linux operating system, initiated by the FSF to develop a complete free software operating system.">GNU</a> and the <a href="#Free Software" title="Free Software: Software that respects users’ essential freedoms, as defined by the FSF: the freedom to run the program for any purpose, to study and change the source code, and to distribute copies (original or modified). It is “Free” in FOSS and “Libre” in FLOSS, emphasising liberty over price.">free software</a> definition, advocating for user freedoms, and publishing the <a href="#GPL" title="GPL – GNU General Public License: Strong copyleft licence requiring derivatives to use the same licence. Versions 2.0 and 3.0 are not mutually compatible. The latter addresses the IoT gap.">GPL</a> family of licences.</dd>

<dt id="FSFE"><b>FSFE – Free Software Foundation Europe</b></dt>
<dd>Sister organisation of the <a href="#FSF" title="FSF – Free Software Foundation: Organisation maintaining GNU and the free software definition, advocating for user freedoms, and publishing the GPL family of licences.">FSF</a>, promoting <a href="#Free Software" title="Free Software: Software that respects users’ essential freedoms, as defined by the FSF: the freedom to run the program for any purpose, to study and change the source code, and to distribute copies (original or modified). It is “Free” in FOSS and “Libre” in FLOSS, emphasising liberty over price.">free software</a> in Europe, and driving the <a href="#REUSE" title="REUSE: FSFE initiative defining standardised file headers, licence text and copyright notice placement, and metadata for automated compliance, aligning with FAIR principles through improved accessibility and interoperability of licensing information.">REUSE</a> initiative to standardise <a href="#Licensing" title="Licensing: Governance of licence permissions, obligations, compliance artefacts, and dependency management; also granting permission to use intellectual property.">licensing</a> information in <a href="#Source Code" title="Source Code: Human-readable form of software that is often compiled into binaries. It is the primary IP asset protected by copyright, and required for OSS status.">source code</a>.</dd>

<dt id="GNU"><b>GNU – “GNU’s Not Unix”</b></dt>
<dd>Project behind the <a href="#GPL" title="GPL – GNU General Public License: Strong copyleft licence requiring derivatives to use the same licence. Versions 2.0 and 3.0 are not mutually compatible. The latter addresses the IoT gap.">GPL</a> family of licences and a precursor to the Linux operating system, initiated by the <a href="#FSF" title="FSF – Free Software Foundation: Organisation maintaining GNU and the free software definition, advocating for user freedoms, and publishing the GPL family of licences.">FSF</a> to develop a complete <a href="#Free Software" title="Free Software: Software that respects users’ essential freedoms, as defined by the FSF: the freedom to run the program for any purpose, to study and change the source code, and to distribute copies (original or modified). It is “Free” in FOSS and “Libre” in FLOSS, emphasising liberty over price.">free software</a> operating system.</dd>

<dt id="GPL"><b>GPL – GNU General Public License</b></dt>
<dd><a href="#Strong Copyleft" title="Strong Copyleft: Licensing model requiring derivatives to remain under the same terms or licence (e.g. GPL, AGPL, EUPL, and CC BY-SA). SSPL is a strong copyleft source-available licence.">Strong copyleft</a> licence requiring <a href="#Derivative" title="Derivative / Derivative Work: Work based on or incorporating an existing copyrighted work, including modified versions. Under copyleft, it must use the same or a compatible licence, whereas licences like CC BY-ND explicitly prohibit modifications.">derivatives</a> to use the same licence. Versions 2.0 and 3.0 are not mutually <a href="#Compatibility" title="Compatibility: A shorthand for licence compatibility, which is the ability to combine or distribute software under different licences without violating their terms. For example, using MIT components within a GPL project, or Apache 2.0 code with GPL 3.0 as out-licence, require applying GPL to the combined work. It can be enhanced through dual and multi-licensing.">compatible</a>. The latter addresses the <a href="#IoT Gap" title="IoT Gap / Tivoisation: Incorporating OSS into hardware while using technical measures like digital signatures or hardware locks to prevent users from running modified versions on that device. It is addressed and prohibited by GPL 3.0.">IoT gap</a>.</dd>

<dt id="GSC"><b>GSC – GÉANT Software Catalogue</b></dt>
<dd>Catalogue of GÉANT software. Used by the <a href="#LT" title="LT – Licensing Team: GÉANT team in charge of SLM, coordinating software licensing, compliance, and governance.">LT</a> for <a href="#SLM" title="SLM – Software and Licence Management: GÉANT subtask supported by the LT, relying on the GSC for software and access to compliance artefacts, and using SLA to assess compliance and risks.">SLM</a> and to track software assets and licence status.</dd>

<dt id="HISTORY File"><b>HISTORY File</b></dt>
<dd>Equivalent to a <a href="#CHANGELOG File" title="CHANGELOG File / Changelog / Change Log: Record of notable changes between releases, relevant for licence compliance. Often written in Markdown, with entries following semantic versioning to indicate release levels and changes. See HISTORY File.">CHANGELOG file</a>, used mainly in older Unix, <a href="#BSD License" title="BSD License: Berkeley Software Distribution family of permissive licences with minimal distribution conditions, requiring retention of attribution notices.">BSD</a>, or <a href="#GNU" title="GNU – “GNU’s Not Unix”: Project behind the GPL family of licences and a precursor to the Linux operating system, initiated by the FSF to develop a complete free software operating system.">GNU</a> projects to track changes over time.</dd>

<dt id="In-Licence"><b>In-Licence / Inbound Licence</b></dt>
<dd>Licence of external components, libraries, or <a href="#Dependency" title="Dependency: External component, library, or source code used by software, including both direct and transitive dependencies. Each typically carries an in-licence, and should be recorded in the dependency inventory or SBOM.">dependencies</a> incorporated into a project, typically recorded in a <a href="#Dependency Inventory" title="Dependency Inventory: Human-readable list of dependencies such as external libraries, frameworks, or essential tools, with versions and licences, often forming the basis for an SBOM.">dependency inventory</a> or <a href="#SBOM" title="SBOM – Software Bill of Materials: Machine-readable dependency inventory of components and their licences, including transitive dependencies, often in SPDX or CycloneDX format, and with semantic versioning and provenance. It supports compliance, risk assessment, and FAIR principles by improving the findability and reusability of information.">SBOM</a>.</dd>

<dt id="IoT Gap"><b>IoT Gap / Tivoisation</b></dt>
<dd>Incorporating <a href="#OSS" title="OSS – Open Source Software: Software under licences recognised by the OSI or FSF that grant rights to use, modify, and distribute source code. It is often referred to as FOSS (or FLOSS) to explicitly include free software principles. Usage of software and licences is guided by an organisation’s IPR Policy, while an OSPO may promote adoption and manage strategy, contribution policies, and compliance.">OSS</a> into hardware while using technical measures like digital signatures or hardware locks to prevent users from running modified versions on that device. It is addressed and prohibited by <a href="#GPL" title="GPL – GNU General Public License: Strong copyleft licence requiring derivatives to use the same licence. Versions 2.0 and 3.0 are not mutually compatible. The latter addresses the IoT gap.">GPL</a> 3.0.</dd>

<dt id="IP"><b>IP – Intellectual Property</b></dt>
<dd>Creations of the mind protected by law through <a href="#Copyright" title="Copyright: Legal IP protection granting exclusive rights to reproduce, distribute, and modify a work. It covers the source code, not the underlying ideas or functionality. Most OSS licences are based on copyright, which is distinct from a creator’s moral rights.">copyright</a>, <a href="#Patent" title="Patent: Legal protection for inventions, designs, or processes, preventing unauthorised use or distribution for a fixed term. In OSS, patents are addressed via patent grants and retaliation clauses. In software, patents protect functionality or process, while copyright protects source code.">patents</a>, <a href="#Trademark" title="Trademark: Legally protected sign, name, logo, symbol, design, or other identifying mark distinguishing goods or services from those of others. In OSS, trademarks protect the identity and brand of the project, which is a form of IP separate from the code’s copyright.">trademarks</a>, and design rights. A licence specifies how others may use such protected works.</dd>

<dt id="IPR"><b>IPR – Intellectual Property Rights</b></dt>
<dd>Legal rights over intangible creations, including <a href="#Copyright" title="Copyright: Legal IP protection granting exclusive rights to reproduce, distribute, and modify a work. It covers the source code, not the underlying ideas or functionality. Most OSS licences are based on copyright, which is distinct from a creator’s moral rights.">copyright</a>, <a href="#Patent" title="Patent: Legal protection for inventions, designs, or processes, preventing unauthorised use or distribution for a fixed term. In OSS, patents are addressed via patent grants and retaliation clauses. In software, patents protect functionality or process, while copyright protects source code.">patents</a>, <a href="#Trademark" title="Trademark: Legally protected sign, name, logo, symbol, design, or other identifying mark distinguishing goods or services from those of others. In OSS, trademarks protect the identity and brand of the project, which is a form of IP separate from the code’s copyright.">trademarks</a>, and trade secrets. Effective <a href="#SLM" title="SLM – Software and Licence Management: GÉANT subtask supported by the LT, relying on the GSC for software and access to compliance artefacts, and using SLA to assess compliance and risks.">SLM</a> requires distinguishing between these rights, particularly when managing <a href="#Sideground IPR" title="Sideground IPR: Intellectual property rights of third-party dependencies, or other copyrighted work incorporated into a project, requiring proper handling to ensure licence compliance.">sideground IPR</a> and <a href="#Dependency" title="Dependency: External component, library, or source code used by software, including both direct and transitive dependencies. Each typically carries an in-licence, and should be recorded in the dependency inventory or SBOM.">dependencies</a>.</dd>

<dt id="IPR Coordinator"><b>IPR Coordinator</b></dt>
<dd>Role managing <a href="#IPR" title="IPR – Intellectual Property Rights: Legal rights over intangible creations, including copyright, patents, trademarks, and trade secrets. Effective SLM requires distinguishing between these rights, particularly when managing sideground IPR and dependencies.">intellectual property rights</a> and licence <a href="#Compliance" title="Compliance: Adherence to licence, patent, and security requirements. Requires maintaining compatibility and compliance artefacts. It may include notice retention and source code provision. Often guided by standards like OpenChain. Reviews may trigger remediation.">compliance</a>, ensuring software projects follow the organisation’s <a href="#IPR Policy" title="IPR Policy: Policy governing intellectual property rights, guiding licence selection and organisational compliance standards.">IPR Policy</a> for licence, <a href="#IP" title="IP – Intellectual Property: Creations of the mind protected by law through copyright, patents, trademarks, and design rights. A licence specifies how others may use such protected works.">IP</a>, and <a href="#Contribution" title="Contribution: Any source code or documentation artefacts submitted to a project, typically governed by a CLA or DCO, forming part of the project’s copyright and licensing framework while respecting the contributor’s moral rights. See Upstream.">contribution</a> management.</dd>

<dt id="IPR Policy"><b>IPR Policy</b></dt>
<dd>Policy governing <a href="#IPR" title="IPR – Intellectual Property Rights: Legal rights over intangible creations, including copyright, patents, trademarks, and trade secrets. Effective SLM requires distinguishing between these rights, particularly when managing sideground IPR and dependencies.">intellectual property rights</a>, guiding licence selection and organisational <a href="#Compliance" title="Compliance: Adherence to licence, patent, and security requirements. Requires maintaining compatibility and compliance artefacts. It may include notice retention and source code provision. Often guided by standards like OpenChain. Reviews may trigger remediation.">compliance</a> standards.</dd>

<dt id="ISC License"><b>ISC License</b></dt>
<dd>Simplified <a href="#Permissive Licence" title="Permissive Licence: Licence allowing use, modification, and distribution with minimal obligations, such as preserving copyright and licence text, and without imposing the same licence on derivatives (e.g. MIT, BSD, Apache, ISC, Artistic, and PSFL). These generally allow sublicensing without requiring a CLA.">permissive licence</a> created by the Internet Software Consortium (now Internet Systems Consortium). It allows unlimited commercial use, modification, and <a href="#Distribution" title="Distribution: Providing software to third parties, triggering licence compliance obligations such as providing source code or maintaining notice retention.">distribution</a> provided the <a href="#Copyright" title="Copyright: Legal IP protection granting exclusive rights to reproduce, distribute, and modify a work. It covers the source code, not the underlying ideas or functionality. Most OSS licences are based on copyright, which is distinct from a creator’s moral rights.">copyright</a> notice and <a href="#Warranty Disclaimer" title="Warranty Disclaimer: Clause stating that the software is provided “as is” without guarantees of fitness or quality. It protects the copyright holder and contributors from liability and is typically included in the LICENSE file or COPYRIGHT file.">warranty disclaimer</a> are preserved.</dd>

<dt id="ISO"><b>ISO – International Organization for Standardization</b></dt>
<dd>Organisation developing international standards, such as <a href="#OpenChain" title="OpenChain: ISO/IEC standard for managing OSS in supply chains, providing guidelines for licence compliance, defining a core curriculum for OSS practices, and specifying conformance requirements for organisations.">OpenChain</a>, including the <a href="#OpenChain" title="OpenChain: ISO/IEC standard for managing OSS in supply chains, providing guidelines for licence compliance, defining a core curriculum for OSS practices, and specifying conformance requirements for organisations.">OpenChain</a> specification for <a href="#OSS" title="OSS – Open Source Software: Software under licences recognised by the OSI or FSF that grant rights to use, modify, and distribute source code. It is often referred to as FOSS (or FLOSS) to explicitly include free software principles. Usage of software and licences is guided by an organisation’s IPR Policy, while an OSPO may promote adoption and manage strategy, contribution policies, and compliance.">open source</a> licence <a href="#Compliance" title="Compliance: Adherence to licence, patent, and security requirements. Requires maintaining compatibility and compliance artefacts. It may include notice retention and source code provision. Often guided by standards like OpenChain. Reviews may trigger remediation.">compliance</a> and quality management.</dd>

<dt id="LGPL"><b>LGPL – GNU Lesser General Public License</b></dt>
<dd><a href="#Weak Copyleft" title="Weak Copyleft: Copyleft scheme used by LGPL, MPL, EPL, and CDDL, where the obligation to share modifications applies only to the specific source code files or libraries, not the entire application. This allows linking with differently licensed or proprietary software.">Weak copyleft</a> licence permitting <a href="#Dynamic Linking" title="Dynamic Linking: Linking external libraries at runtime rather than copying code into the executable. Critical for compliance with LGPL, as it simply allows the main application to remain proprietary software.">dynamic linking</a> with differently licensed or <a href="#Proprietary Software" title="Proprietary Software: Software distributed under highly restrictive terms (often in an EULA) limiting access, modification, or distribution, and typically sold as closed source software. It may involve trademarks, and be distributed as commercial software, freeware, or shareware.">proprietary software</a>. <a href="#Static Linking" title="Static Linking: Copying library code directly into the main executable binary. For weak copyleft licences like LGPL, this may trigger obligations to provide object code or source code to allow relinking.">Static linking</a> is allowed if the user receives the <a href="#Source Code" title="Source Code: Human-readable form of software that is often compiled into binaries. It is the primary IP asset protected by copyright, and required for OSS status.">source code</a> and information required to rebuild the work with a modified version of the library.</dd>

<dt id="Licence"><b>Licence</b></dt>
<dd>Legal instrument granting permissions to use, modify, or <a href="#Distribution" title="Distribution: Providing software to third parties, triggering licence compliance obligations such as providing source code or maintaining notice retention.">distribute</a> <a href="#Copyright" title="Copyright: Legal IP protection granting exclusive rights to reproduce, distribute, and modify a work. It covers the source code, not the underlying ideas or functionality. Most OSS licences are based on copyright, which is distinct from a creator’s moral rights.">copyrighted</a> or <a href="#Patent" title="Patent: Legal protection for inventions, designs, or processes, preventing unauthorised use or distribution for a fixed term. In OSS, patents are addressed via patent grants and retaliation clauses. In software, patents protect functionality or process, while copyright protects source code.">patented</a> software. It sets obligations like <a href="#Attribution" title="Attribution: Notice required by some licences (e.g. Apache, CC BY, and BSD) to preserve credit to original authors and contributors, reproduce the copyright statement, and indicate modifications.">attribution</a> or <a href="#Source Code" title="Source Code: Human-readable form of software that is often compiled into binaries. It is the primary IP asset protected by copyright, and required for OSS status.">source code</a> provision for the <a href="#Licensee" title="Licensee: Individual or organisation granted specific rights to use or modify software under the terms of a licence.">licensee</a>, without transferring ownership from the <a href="#Copyright Holder" title="Copyright Holder: Individual or entity owning exclusive rights to a work and granting permissions via a licence, typically identified in the COPYRIGHT file. See Copyright.">copyright holder</a>. The US spelling and the verb in both UK and US English is <strong>license</strong>, which also appears in licence names and acronyms.</dd>

<dt id="LICENSE File"><b>LICENSE File</b></dt>
<dd>File containing the full licence text, essential for legal <a href="#Compliance" title="Compliance: Adherence to licence, patent, and security requirements. Requires maintaining compatibility and compliance artefacts. It may include notice retention and source code provision. Often guided by standards like OpenChain. Reviews may trigger remediation.">compliance</a> and <a href="#Distribution" title="Distribution: Providing software to third parties, triggering licence compliance obligations such as providing source code or maintaining notice retention.">distribution</a>. See <a href="#COPYING File" title="COPYING File: Traditional GNU-style filename, signalling adherence to traditional free software conventions. It is used to store the full text of the licence, usually the GPL, and is an equivalent to LICENSE file.">COPYING File</a>.</dd>

<dt id="Licensee"><b>Licensee</b></dt>
<dd>Individual or organisation granted specific rights to use or modify software under the terms of a licence.</dd>

<dt id="Licensing"><b>Licensing</b></dt>
<dd>Governance of licence permissions, obligations, <a href="#Compliance Artefacts" title="Compliance Artefacts: Documentation artefacts or files required for licence adherence, such as LICENSE, NOTICE, and COPYRIGHT files. They include notice retention obligations to preserve copyright and licence notices in distributions.">compliance artefacts</a>, and <a href="#Dependency" title="Dependency: External component, library, or source code used by software, including both direct and transitive dependencies. Each typically carries an in-licence, and should be recorded in the dependency inventory or SBOM.">dependency</a> management; also granting permission to use <a href="#IP" title="IP – Intellectual Property: Creations of the mind protected by law through copyright, patents, trademarks, and design rights. A licence specifies how others may use such protected works.">intellectual property</a>.</dd>

<dt id="LT"><b>LT – Licensing Team</b></dt>
<dd>GÉANT team in charge of <a href="#SLM" title="SLM – Software and Licence Management: GÉANT subtask supported by the LT, relying on the GSC for software and access to compliance artefacts, and using SLA to assess compliance and risks.">SLM</a>, coordinating <a href="#Licensing" title="Licensing: Governance of licence permissions, obligations, compliance artefacts, and dependency management; also granting permission to use intellectual property.">software licensing</a>, <a href="#Compliance" title="Compliance: Adherence to licence, patent, and security requirements. Requires maintaining compatibility and compliance artefacts. It may include notice retention and source code provision. Often guided by standards like OpenChain. Reviews may trigger remediation.">compliance</a>, and governance.</dd>

<dt id="MIT License"><b>MIT License / X11 License</b></dt>
<dd>Simple <a href="#Permissive Licence" title="Permissive Licence: Licence allowing use, modification, and distribution with minimal obligations, such as preserving copyright and licence text, and without imposing the same licence on derivatives (e.g. MIT, BSD, Apache, ISC, Artistic, and PSFL). These generally allow sublicensing without requiring a CLA.">permissive licence</a> requiring <a href="#Attribution" title="Attribution: Notice required by some licences (e.g. Apache, CC BY, and BSD) to preserve credit to original authors and contributors, reproduce the copyright statement, and indicate modifications.">attribution</a> and <a href="#Notice Retention" title="Notice Retention: Requirement to preserve copyright, licence texts, and attribution notices in all (re)distributions of the software.">notice retention</a>, widely used for its brevity and <a href="#Compatibility" title="Compatibility: A shorthand for licence compatibility, which is the ability to combine or distribute software under different licences without violating their terms. For example, using MIT components within a GPL project, or Apache 2.0 code with GPL 3.0 as out-licence, require applying GPL to the combined work. It can be enhanced through dual and multi-licensing.">compatibility</a>.</dd>

<dt id="Moral Rights"><b>Moral Rights</b></dt>
<dd>Personal, often non-transferable rights of creators to be named as the author (<a href="#Attribution" title="Attribution: Notice required by some licences (e.g. Apache, CC BY, and BSD) to preserve credit to original authors and contributors, reproduce the copyright statement, and indicate modifications.">attribution</a>), and to object to derogatory treatment of their work. These rights persist even if <a href="#Copyright" title="Copyright: Legal IP protection granting exclusive rights to reproduce, distribute, and modify a work. It covers the source code, not the underlying ideas or functionality. Most OSS licences are based on copyright, which is distinct from a creator’s moral rights.">copyright</a> is transferred to another entity.</dd>

<dt id="MPL"><b>MPL – Mozilla Public License</b></dt>
<dd><a href="#Weak Copyleft" title="Weak Copyleft: Copyleft scheme used by LGPL, MPL, EPL, and CDDL, where the obligation to share modifications applies only to the specific source code files or libraries, not the entire application. This allows linking with differently licensed or proprietary software.">Weak copyleft</a> licence permitting file-level mixing by treating <a href="#Source Code" title="Source Code: Human-readable form of software that is often compiled into binaries. It is the primary IP asset protected by copyright, and required for OSS status.">source code</a> files as individual <a href="#Copyright" title="Copyright: Legal IP protection granting exclusive rights to reproduce, distribute, and modify a work. It covers the source code, not the underlying ideas or functionality. Most OSS licences are based on copyright, which is distinct from a creator’s moral rights.">copyright</a> units. Modifications to files under MPL must remain under it, but files under other licences can be compiled together with them into a single <a href="#Binaries" title="Binaries: Compiled executable files and other binary resources, as opposed to source code. In proprietary software, only the binaries are typically distributed.">binary</a>.</dd>

<dt id="Network-Protective Licence"><b>Network-Protective Licence</b></dt>
<dd><a href="#Strong Copyleft" title="Strong Copyleft: Licensing model requiring derivatives to remain under the same terms or licence (e.g. GPL, AGPL, EUPL, and CC BY-SA). SSPL is a strong copyleft source-available licence.">Strong copyleft</a> licences (such as the <a href="#AGPL" title="AGPL – GNU Affero General Public License: Strong copyleft licence requiring source code disclosure to all users, even for networked or remote use (e.g. as a service), thereby closing the cloud gap.">AGPL</a> or <a href="#SSPL" title="SSPL – Server Side Public License: Network-protective, strong copyleft, and source-available licence requiring release of service management layer source code when providing a service. Its additional obligations on the surrounding service stack make it fauxpen.">SSPL</a>) designed to close the <a href="#Cloud Gap" title="Cloud Gap / SaaS Loophole / ASP Loophole: Situation where accessing software as a service over a network (remote use) avoids triggering strong copyleft obligations, as it is not physically distributed. This allows service providers to modify OSS and offer it as a service without releasing source code. This is addressed by network-protective licences like the AGPL.">cloud gap</a> by treating use over a network (<a href="#Remote Use" title="Remote Use: Use of software over a network (e.g. Software as a Service), rather than running a local copy. In standard copyleft licences, this does not trigger distribution obligations, whereas network-protective licences (like AGPL) treat this interaction as a trigger for source code disclosure.">remote use</a>) as <a href="#Distribution" title="Distribution: Providing software to third parties, triggering licence compliance obligations such as providing source code or maintaining notice retention.">distribution</a>. This triggers the requirement to disclose the modified <a href="#Source Code" title="Source Code: Human-readable form of software that is often compiled into binaries. It is the primary IP asset protected by copyright, and required for OSS status.">source code</a>.</dd>

<dt id="NOTICE File"><b>NOTICE File</b></dt>
<dd>File containing mandatory acknowledgements, <a href="#Attribution" title="Attribution: Notice required by some licences (e.g. Apache, CC BY, and BSD) to preserve credit to original authors and contributors, reproduce the copyright statement, and indicate modifications.">attributions</a>, and other licence-related notices required by <a href="#Out-Licence" title="Out-Licence / Outbound Licence: Licence applied to distributed software, which may differ from the in-licences of its dependencies. It defines the terms under which the downstream user can use the software.">out-licence</a> and <a href="#Dependency" title="Dependency: External component, library, or source code used by software, including both direct and transitive dependencies. Each typically carries an in-licence, and should be recorded in the dependency inventory or SBOM.">dependencies</a>.</dd>

<dt id="Notice Retention"><b>Notice Retention</b></dt>
<dd>Requirement to preserve <a href="#Copyright" title="Copyright: Legal IP protection granting exclusive rights to reproduce, distribute, and modify a work. It covers the source code, not the underlying ideas or functionality. Most OSS licences are based on copyright, which is distinct from a creator’s moral rights.">copyright</a>, licence texts, and <a href="#Attribution" title="Attribution: Notice required by some licences (e.g. Apache, CC BY, and BSD) to preserve credit to original authors and contributors, reproduce the copyright statement, and indicate modifications.">attribution</a> notices in all (re)<a href="#Distribution" title="Distribution: Providing software to third parties, triggering licence compliance obligations such as providing source code or maintaining notice retention.">distributions</a> of the software.</dd>

<dt id="Open Core"><b>Open Core</b></dt>
<dd>Business model where core functionality is <a href="#OSS" title="OSS – Open Source Software: Software under licences recognised by the OSI or FSF that grant rights to use, modify, and distribute source code. It is often referred to as FOSS (or FLOSS) to explicitly include free software principles. Usage of software and licences is guided by an organisation’s IPR Policy, while an OSPO may promote adoption and manage strategy, contribution policies, and compliance.">OSS</a>, while add-ons with advanced features (enterprise security, monitoring) are <a href="#Proprietary Software" title="Proprietary Software: Software distributed under highly restrictive terms (often in an EULA) limiting access, modification, or distribution, and typically sold as closed source software. It may involve trademarks, and be distributed as commercial software, freeware, or shareware.">proprietary software</a> or <a href="#Source-Available" title="Source-Available: Licence or software with viewable source code that lacks full OSS freedoms due to restrictive terms (e.g. Elastic License, SSPL). Unlike Closed Source Software, the code is viewable and often modifiable, but the licence is fauxpen or contains usage restrictions that prevent it from being classified as OSS or FOSS.">source-available software</a>.</dd>

<dt id="OpenChain"><b>OpenChain</b></dt>
<dd><a href="#ISO" title="ISO – International Organization for Standardization: Organisation developing international standards, such as OpenChain, including the OpenChain specification for open source licence compliance and quality management.">ISO</a>/IEC standard for managing <a href="#OSS" title="OSS – Open Source Software: Software under licences recognised by the OSI or FSF that grant rights to use, modify, and distribute source code. It is often referred to as FOSS (or FLOSS) to explicitly include free software principles. Usage of software and licences is guided by an organisation’s IPR Policy, while an OSPO may promote adoption and manage strategy, contribution policies, and compliance.">OSS</a> in supply chains, providing guidelines for licence <a href="#Compliance" title="Compliance: Adherence to licence, patent, and security requirements. Requires maintaining compatibility and compliance artefacts. It may include notice retention and source code provision. Often guided by standards like OpenChain. Reviews may trigger remediation.">compliance</a>, defining a core curriculum for <a href="#OSS" title="OSS – Open Source Software: Software under licences recognised by the OSI or FSF that grant rights to use, modify, and distribute source code. It is often referred to as FOSS (or FLOSS) to explicitly include free software principles. Usage of software and licences is guided by an organisation’s IPR Policy, while an OSPO may promote adoption and manage strategy, contribution policies, and compliance.">OSS</a> practices, and specifying conformance requirements for organisations.</dd>

<dt id="ORCID"><b>ORCID – Open Researcher and Contributor ID</b></dt>
<dd>Persistent digital identifier uniquely distinguishing researchers and <a href="#Contribution" title="Contribution: Any source code or documentation artefacts submitted to a project, typically governed by a CLA or DCO, forming part of the project’s copyright and licensing framework while respecting the contributor’s moral rights. See Upstream.">contributors</a>. Often included in the <a href="#AUTHORS File" title="AUTHORS File: Lists original authors and primary contributors for attribution and historical reference; contributor identities can be linked to emails or ORCID identifiers.">AUTHORS file</a> and <a href="#CONTRIBUTORS File" title="CONTRIBUTORS File: Lists contributors; less common than AUTHORS file, and used in large community-driven projects.">CONTRIBUTORS file</a>.</dd>

<dt id="OSI"><b>OSI – Open Source Initiative</b></dt>
<dd>Non-profit organisation that promotes <a href="#OSS" title="OSS – Open Source Software: Software under licences recognised by the OSI or FSF that grant rights to use, modify, and distribute source code. It is often referred to as FOSS (or FLOSS) to explicitly include free software principles. Usage of software and licences is guided by an organisation’s IPR Policy, while an OSPO may promote adoption and manage strategy, contribution policies, and compliance.">OSS</a> and manages the Open Source Definition (OSD). Licences are generally considered open source only if they have been approved by the OSI.</dd>

<dt id="OSPO"><b>OSPO – Open Source Program Office</b></dt>
<dd>Unit managing <a href="#OSS" title="OSS – Open Source Software: Software under licences recognised by the OSI or FSF that grant rights to use, modify, and distribute source code. It is often referred to as FOSS (or FLOSS) to explicitly include free software principles. Usage of software and licences is guided by an organisation’s IPR Policy, while an OSPO may promote adoption and manage strategy, contribution policies, and compliance.">OSS</a> strategy, <a href="#Compliance" title="Compliance: Adherence to licence, patent, and security requirements. Requires maintaining compatibility and compliance artefacts. It may include notice retention and source code provision. Often guided by standards like OpenChain. Reviews may trigger remediation.">compliance</a>, and engagement. In GÉANT, the <a href="#IPR Coordinator" title="IPR Coordinator: Role managing intellectual property rights and licence compliance, ensuring software projects follow the organisation’s IPR Policy for licence, IP, and contribution management.">IPR Coordinator</a> oversees <a href="#IP" title="IP – Intellectual Property: Creations of the mind protected by law through copyright, patents, trademarks, and design rights. A licence specifies how others may use such protected works.">IP</a> and <a href="#Compliance" title="Compliance: Adherence to licence, patent, and security requirements. Requires maintaining compatibility and compliance artefacts. It may include notice retention and source code provision. Often guided by standards like OpenChain. Reviews may trigger remediation.">compliance</a>, while the <a href="#LT" title="LT – Licensing Team: GÉANT team in charge of SLM, coordinating software licensing, compliance, and governance.">LT</a> implements day-to-day <a href="#SLM" title="SLM – Software and Licence Management: GÉANT subtask supported by the LT, relying on the GSC for software and access to compliance artefacts, and using SLA to assess compliance and risks.">SLM</a> processes.</dd>

<dt id="OSS"><b>OSS – Open Source Software</b></dt>
<dd>Software under licences recognised by the <a href="#OSI" title="OSI – Open Source Initiative: Non-profit organisation that promotes OSS and manages the Open Source Definition (OSD). Licences are generally considered open source only if they have been approved by the OSI.">OSI</a> or <a href="#FSF" title="FSF – Free Software Foundation: Organisation maintaining GNU and the free software definition, advocating for user freedoms, and publishing the GPL family of licences.">FSF</a> that grant rights to use, modify, and <a href="#Distribution" title="Distribution: Providing software to third parties, triggering licence compliance obligations such as providing source code or maintaining notice retention.">distribute</a> <a href="#Source Code" title="Source Code: Human-readable form of software that is often compiled into binaries. It is the primary IP asset protected by copyright, and required for OSS status.">source code</a>. It is often referred to as <a href="#FOSS" title="FOSS – Free and Open Source Software / FLOSS: Software meeting free software criteria set by the FSF; FOSS licences are a subset of OSS licences. In FLOSS, L stands for libre to emphasise freedom rather than price.">FOSS</a> (or <a href="#FOSS" title="FOSS – Free and Open Source Software / FLOSS: Software meeting free software criteria set by the FSF; FOSS licences are a subset of OSS licences. In FLOSS, L stands for libre to emphasise freedom rather than price.">FLOSS</a>) to explicitly include <a href="#Free Software" title="Free Software: Software that respects users’ essential freedoms, as defined by the FSF: the freedom to run the program for any purpose, to study and change the source code, and to distribute copies (original or modified). It is “Free” in FOSS and “Libre” in FLOSS, emphasising liberty over price.">free software</a> principles. Usage of software and licences is guided by an organisation’s <a href="#IPR Policy" title="IPR Policy: Policy governing intellectual property rights, guiding licence selection and organisational compliance standards.">IPR Policy</a>, while an <a href="#OSPO" title="OSPO – Open Source Program Office: Unit managing OSS strategy, compliance, and engagement. In GÉANT, the IPR Coordinator oversees IP and compliance, while the LT implements day-to-day SLM processes.">OSPO</a> may promote adoption and manage strategy, <a href="#Contribution" title="Contribution: Any source code or documentation artefacts submitted to a project, typically governed by a CLA or DCO, forming part of the project’s copyright and licensing framework while respecting the contributor’s moral rights. See Upstream.">contribution</a> policies, and <a href="#Compliance" title="Compliance: Adherence to licence, patent, and security requirements. Requires maintaining compatibility and compliance artefacts. It may include notice retention and source code provision. Often guided by standards like OpenChain. Reviews may trigger remediation.">compliance</a>.</dd>

<dt id="Out-Licence"><b>Out-Licence / Outbound Licence</b></dt>
<dd>Licence applied to <a href="#Distribution" title="Distribution: Providing software to third parties, triggering licence compliance obligations such as providing source code or maintaining notice retention.">distributed</a> software, which may differ from the <a href="#In-Licence" title="In-Licence / Inbound Licence: Licence of external components, libraries, or dependencies incorporated into a project, typically recorded in a dependency inventory or SBOM.">in-licences</a> of its <a href="#Dependency" title="Dependency: External component, library, or source code used by software, including both direct and transitive dependencies. Each typically carries an in-licence, and should be recorded in the dependency inventory or SBOM.">dependencies</a>. It defines the terms under which the <a href="#Downstream" title="Downstream: Any project, organisation, or user that consumes, integrates, or distributes software from an upstream source. Downstream users inherit the compliance obligations defined by the out-licence of upstream software.">downstream</a> user can use the software.</dd>

<dt id="Patent"><b>Patent</b></dt>
<dd>Legal protection for inventions, designs, or processes, preventing unauthorised use or <a href="#Distribution" title="Distribution: Providing software to third parties, triggering licence compliance obligations such as providing source code or maintaining notice retention.">distribution</a> for a fixed term. In <a href="#OSS" title="OSS – Open Source Software: Software under licences recognised by the OSI or FSF that grant rights to use, modify, and distribute source code. It is often referred to as FOSS (or FLOSS) to explicitly include free software principles. Usage of software and licences is guided by an organisation’s IPR Policy, while an OSPO may promote adoption and manage strategy, contribution policies, and compliance.">OSS</a>, patents are addressed via <a href="#Patent Grant" title="Patent Grant: Permission to use patents associated with the software and its contributions, typically covering rights held by contributors. This provision is designed to reduce legal uncertainty for users and distributors.">patent grants</a> and <a href="#Patent Retaliation Clause" title="Patent Retaliation Clause: Licence term that serves as a defensive termination mechanism, revoking a licensee’s rights and the patent grant if they initiate patent litigation against the project or its contributors, also deterring patent trolling (e.g. Apache License).">retaliation clauses</a>. In software, patents protect functionality or process, while <a href="#Copyright" title="Copyright: Legal IP protection granting exclusive rights to reproduce, distribute, and modify a work. It covers the source code, not the underlying ideas or functionality. Most OSS licences are based on copyright, which is distinct from a creator’s moral rights.">copyright</a> protects <a href="#Source Code" title="Source Code: Human-readable form of software that is often compiled into binaries. It is the primary IP asset protected by copyright, and required for OSS status.">source code</a>.</dd>

<dt id="Patent Grant"><b>Patent Grant</b></dt>
<dd>Permission to use <a href="#Patent" title="Patent: Legal protection for inventions, designs, or processes, preventing unauthorised use or distribution for a fixed term. In OSS, patents are addressed via patent grants and retaliation clauses. In software, patents protect functionality or process, while copyright protects source code.">patents</a> associated with the software and its <a href="#Contribution" title="Contribution: Any source code or documentation artefacts submitted to a project, typically governed by a CLA or DCO, forming part of the project’s copyright and licensing framework while respecting the contributor’s moral rights. See Upstream.">contributions</a>, typically covering rights held by contributors. This provision is designed to reduce legal uncertainty for users and distributors.</dd>

<dt id="Patent Retaliation Clause"><b>Patent Retaliation Clause</b></dt>
<dd>Licence term that serves as a <a href="#Defensive Termination" title="Defensive Termination: Licence clause serving as a deterrent against patent trolling by automatically terminating a licensee’s rights if they initiate patent litigation against the project or its contributors. See Patent Retaliation Clause.">defensive termination</a> mechanism, revoking a <a href="#Licensee" title="Licensee: Individual or organisation granted specific rights to use or modify software under the terms of a licence.">licensee’s</a> rights and the <a href="#Patent Grant" title="Patent Grant: Permission to use patents associated with the software and its contributions, typically covering rights held by contributors. This provision is designed to reduce legal uncertainty for users and distributors.">patent grant</a> if they initiate <a href="#Patent" title="Patent: Legal protection for inventions, designs, or processes, preventing unauthorised use or distribution for a fixed term. In OSS, patents are addressed via patent grants and retaliation clauses. In software, patents protect functionality or process, while copyright protects source code.">patent</a> litigation against the project or its <a href="#Contribution" title="Contribution: Any source code or documentation artefacts submitted to a project, typically governed by a CLA or DCO, forming part of the project’s copyright and licensing framework while respecting the contributor’s moral rights. See Upstream.">contributors</a>, also deterring <a href="#Patent Trolling" title="Patent Trolling: Asserting patents to obtain fees or settlements; addressed in some licences through patent retaliation clauses.">patent trolling</a> (e.g. <a href="#Apache License" title="Apache License: Permissive licence with patent protection, a patent retaliation clause, and patent grant for licensees. It requires a NOTICE file for attribution.">Apache License</a>).</dd>

<dt id="Patent Trolling"><b>Patent Trolling</b></dt>
<dd>Asserting <a href="#Patent" title="Patent: Legal protection for inventions, designs, or processes, preventing unauthorised use or distribution for a fixed term. In OSS, patents are addressed via patent grants and retaliation clauses. In software, patents protect functionality or process, while copyright protects source code.">patents</a> to obtain fees or settlements; addressed in some licences through <a href="#Patent Retaliation Clause" title="Patent Retaliation Clause: Licence term that serves as a defensive termination mechanism, revoking a licensee’s rights and the patent grant if they initiate patent litigation against the project or its contributors, also deterring patent trolling (e.g. Apache License).">patent retaliation clauses</a>.</dd>

<dt id="Permissive Licence"><b>Permissive Licence</b></dt>
<dd>Licence allowing use, modification, and <a href="#Distribution" title="Distribution: Providing software to third parties, triggering licence compliance obligations such as providing source code or maintaining notice retention.">distribution</a> with minimal obligations, such as preserving <a href="#Copyright" title="Copyright: Legal IP protection granting exclusive rights to reproduce, distribute, and modify a work. It covers the source code, not the underlying ideas or functionality. Most OSS licences are based on copyright, which is distinct from a creator’s moral rights.">copyright</a> and licence text, and without imposing the same licence on <a href="#Derivative" title="Derivative / Derivative Work: Work based on or incorporating an existing copyrighted work, including modified versions. Under copyleft, it must use the same or a compatible licence, whereas licences like CC BY-ND explicitly prohibit modifications.">derivatives</a> (e.g. <a href="#MIT License" title="MIT License / X11 License: Simple permissive licence requiring attribution and notice retention, widely used for its brevity and compatibility.">MIT</a>, <a href="#BSD License" title="BSD License: Berkeley Software Distribution family of permissive licences with minimal distribution conditions, requiring retention of attribution notices.">BSD</a>, <a href="#Apache License" title="Apache License: Permissive licence with patent protection, a patent retaliation clause, and patent grant for licensees. It requires a NOTICE file for attribution.">Apache</a>, <a href="#ISC License" title="ISC License: Simplified permissive licence created by the Internet Software Consortium (now Internet Systems Consortium). It allows unlimited commercial use, modification, and distribution provided the copyright notice and warranty disclaimer are preserved.">ISC</a>, <a href="#Artistic License" title="Artistic License: Permissive licence originating from the Perl ecosystem; version 2 clarifies terms and has compatibility with GPL.">Artistic</a>, and <a href="#PSFL" title="PSFL – Python Software Foundation License / Python License: Permissive licences governing the Python interpreter and standard library, and granting broad rights to use, modify, and distribute Python with minimal conditions that include a notice and disclaimer requirement.">PSFL</a>). These generally allow <a href="#Sublicensing" title="Sublicensing: Allowing a licensee to pass on certain rights to a third party without transferring copyright or changing licence terms; permissive licences allow it, copyleft licences restrict it to the same terms, and commercial licences usually forbid it.">sublicensing</a> without requiring a <a href="#CLA File" title="CLA File – Contributor License Agreement: Agreement granting rights to use, modify, and manage contributions; may include copyright transfer or sublicensing rights, and often requires signature.">CLA</a>.</dd>

<dt id="Proprietary Software"><b>Proprietary Software</b></dt>
<dd>Software <a href="#Distribution" title="Distribution: Providing software to third parties, triggering licence compliance obligations such as providing source code or maintaining notice retention.">distributed</a> under highly restrictive terms (often in an <a href="#EULA" title="EULA – End User Licence Agreement: Proprietary software licence defining rights and restrictions by which an end user may access and use the software.">EULA</a>) limiting access, modification, or <a href="#Distribution" title="Distribution: Providing software to third parties, triggering licence compliance obligations such as providing source code or maintaining notice retention.">distribution</a>, and typically sold as <a href="#Closed Source Software" title="Closed Source Software: Software distributed without source code access or modification rights, unlike OSS or source-available software.">closed source software</a>. It may involve <a href="#Trademark" title="Trademark: Legally protected sign, name, logo, symbol, design, or other identifying mark distinguishing goods or services from those of others. In OSS, trademarks protect the identity and brand of the project, which is a form of IP separate from the code’s copyright.">trademarks</a>, and be <a href="#Distribution" title="Distribution: Providing software to third parties, triggering licence compliance obligations such as providing source code or maintaining notice retention.">distributed</a> as <a href="#Commercial Software" title="Commercial Software: Software sold or licensed for profit, typically under a commercial licence or other restrictive proprietary software terms. It may involve trademarks or follow an Open Core model, where proprietary features are built atop community OSS through dual and multi-licensing.">commercial software</a>, <a href="#Freeware" title="Freeware: Proprietary software available at no cost, but without the freedoms to modify or distribute source code inherent to free software or OSS.">freeware</a>, or <a href="#Shareware" title="Shareware: Proprietary software provided initially for free (often as a trial) with the expectation that the user will pay for continued use; distinctly different from OSS.">shareware</a>.</dd>

<dt id="PSFL"><b>PSFL – Python Software Foundation License / Python License</b></dt>
<dd><a href="#Permissive Licence" title="Permissive Licence: Licence allowing use, modification, and distribution with minimal obligations, such as preserving copyright and licence text, and without imposing the same licence on derivatives (e.g. MIT, BSD, Apache, ISC, Artistic, and PSFL). These generally allow sublicensing without requiring a CLA.">Permissive licences</a> governing the Python interpreter and standard library, and granting broad rights to use, modify, and <a href="#Distribution" title="Distribution: Providing software to third parties, triggering licence compliance obligations such as providing source code or maintaining notice retention.">distribute</a> Python with minimal conditions that include a notice and disclaimer requirement.</dd>

<dt id="Public Domain"><b>Public Domain</b></dt>
<dd>Works not protected by <a href="#Copyright" title="Copyright: Legal IP protection granting exclusive rights to reproduce, distribute, and modify a work. It covers the source code, not the underlying ideas or functionality. Most OSS licences are based on copyright, which is distinct from a creator’s moral rights.">copyright</a>, <a href="#Patent" title="Patent: Legal protection for inventions, designs, or processes, preventing unauthorised use or distribution for a fixed term. In OSS, patents are addressed via patent grants and retaliation clauses. In software, patents protect functionality or process, while copyright protects source code.">patent</a>, or <a href="#Moral Rights" title="Moral Rights: Personal, often non-transferable rights of creators to be named as the author (attribution), and to object to derogatory treatment of their work. These rights persist even if copyright is transferred to another entity.">moral rights</a>, due to expiration of <a href="#IP" title="IP – Intellectual Property: Creations of the mind protected by law through copyright, patents, trademarks, and design rights. A licence specifies how others may use such protected works.">IP</a> protection or explicit waiver by the rights holder (e.g. via <a href="#CC0" title="CC0 – Creative Commons Zero: Public-domain dedication waiving copyright and related rights. It includes a fallback permissive licence for jurisdictions where waivers of copyright or moral rights are not recognised, ensuring global usability of works.">CC0</a> or <a href="#Unlicense" title="Unlicense: Text used to dedicate a work to the public domain by waiving all copyright and related rights. It includes a fallback permissive licence for jurisdictions where copyright or moral rights cannot be legally abandoned.">Unlicense</a>). In jurisdictions not recognising waivers, fallback <a href="#Permissive Licence" title="Permissive Licence: Licence allowing use, modification, and distribution with minimal obligations, such as preserving copyright and licence text, and without imposing the same licence on derivatives (e.g. MIT, BSD, Apache, ISC, Artistic, and PSFL). These generally allow sublicensing without requiring a CLA.">permissive licences</a> like <a href="#0BSD" title="0BSD – Zero-Clause BSD: Public domain-equivalent permissive licence that does not require attribution, and is often preferred over CC0 for software due to specific legal wording regarding code.">0BSD</a>, <a href="#Unlicense" title="Unlicense: Text used to dedicate a work to the public domain by waiving all copyright and related rights. It includes a fallback permissive licence for jurisdictions where copyright or moral rights cannot be legally abandoned.">Unlicense</a>, or MIT-0 can be used.</dd>

<dt id="README File"><b>README File</b></dt>
<dd><a href="#Documentation Artefacts" title="Documentation Artefacts: Technical or user-facing documents distributed with software, such as README, LICENSE, NOTICE, CHANGELOG, and CONTRIBUTING files, typically following the software’s licence. Some are covered by a documentation licence, which may differ from the software licence applied to the code.">Documentation artefact</a> providing an overview of a project, installation, and usage; typically written in Markdown to ensure clear formatting and readability.</dd>

<dt id="Reciprocity"><b>Reciprocity</b></dt>
<dd>Principle requiring that rights granted under a licence (e.g. <a href="#Copyleft" title="Copyleft: Licensing principle requiring derivatives to remain under the same or a compatible licence, ensuring software freedom (e.g. GPL, AGPL). This is based on the principle of reciprocity.">copyleft</a>) must be extended to <a href="#Derivative" title="Derivative / Derivative Work: Work based on or incorporating an existing copyrighted work, including modified versions. Under copyleft, it must use the same or a compatible licence, whereas licences like CC BY-ND explicitly prohibit modifications.">derivatives</a> or <a href="#Distribution" title="Distribution: Providing software to third parties, triggering licence compliance obligations such as providing source code or maintaining notice retention.">distributed</a> versions.</dd>

<dt id="Relicensing"><b>Relicensing</b></dt>
<dd>Changing a licence of existing software, often to improve <a href="#Compatibility" title="Compatibility: A shorthand for licence compatibility, which is the ability to combine or distribute software under different licences without violating their terms. For example, using MIT components within a GPL project, or Apache 2.0 code with GPL 3.0 as out-licence, require applying GPL to the combined work. It can be enhanced through dual and multi-licensing.">compatibility</a> or for commercial reasons; must comply with original licence or <a href="#Contribution" title="Contribution: Any source code or documentation artefacts submitted to a project, typically governed by a CLA or DCO, forming part of the project’s copyright and licensing framework while respecting the contributor’s moral rights. See Upstream.">contributor</a> consent. Relicensing to a <a href="#Fauxpen" title="Fauxpen: Software or licence presented as OSS but effectively controlled by the vendor, restricting true OSS freedoms (e.g. Elastic License or SSPL).">fauxpen</a> or <a href="#Commercial Licence" title="Commercial Licence: Licence granting rights to use, modify, or distribute software for commercial purposes, often under restrictive proprietary software terms, and typically requiring payment or authorisation. These licences typically define usage restrictions not found in OSS licences.">commercial licence</a> often results in a <a href="#Fork" title="Fork: Divergent development path based on a specific version of a project; often used to continue work from the last OSS version in response to relicensing to a proprietary software licence, or to prepare an upstream contribution back to the original project.">fork</a>.</dd>

<dt id="Remediation"><b>Remediation</b></dt>
<dd>Process of resolving identified issues in a software project, such as updating outdated <a href="#Dependency" title="Dependency: External component, library, or source code used by software, including both direct and transitive dependencies. Each typically carries an in-licence, and should be recorded in the dependency inventory or SBOM.">dependencies</a> with <a href="#Vulnerability" title="Vulnerability: Security flaw in software code that can be exploited to cause harm, compromise data, or gain unauthorised access. SCA tools identify known vulnerabilities in dependencies (often mapping them to CVE lists) and flag them for remediation.">vulnerabilities</a>, replacing incompatible licences or correcting missing notices, to restore <a href="#Compliance" title="Compliance: Adherence to licence, patent, and security requirements. Requires maintaining compatibility and compliance artefacts. It may include notice retention and source code provision. Often guided by standards like OpenChain. Reviews may trigger remediation.">compliance</a> and reduce security or legal risk.</dd>

<dt id="Remote Use"><b>Remote Use</b></dt>
<dd>Use of software over a network (e.g. Software as a Service), rather than running a local copy. In standard <a href="#Copyleft" title="Copyleft: Licensing principle requiring derivatives to remain under the same or a compatible licence, ensuring software freedom (e.g. GPL, AGPL). This is based on the principle of reciprocity.">copyleft</a> licences, this does not trigger <a href="#Distribution" title="Distribution: Providing software to third parties, triggering licence compliance obligations such as providing source code or maintaining notice retention.">distribution</a> obligations, whereas <a href="#Network-Protective Licence" title="Network-Protective Licence: Strong copyleft licences (such as the AGPL or SSPL) designed to close the cloud gap by treating use over a network (remote use) as distribution. This triggers the requirement to disclose the modified source code.">network-protective licences</a> (like <a href="#AGPL" title="AGPL – GNU Affero General Public License: Strong copyleft licence requiring source code disclosure to all users, even for networked or remote use (e.g. as a service), thereby closing the cloud gap.">AGPL</a>) treat this interaction as a trigger for <a href="#Source Code" title="Source Code: Human-readable form of software that is often compiled into binaries. It is the primary IP asset protected by copyright, and required for OSS status.">source code</a> disclosure.</dd>

<dt id="REUSE"><b>REUSE</b></dt>
<dd><a href="#FSFE" title="FSFE – Free Software Foundation Europe: Sister organisation of the FSF, promoting free software in Europe, and driving the REUSE initiative to standardise licensing information in source code.">FSFE</a> initiative defining standardised file headers, licence text and <a href="#Copyright" title="Copyright: Legal IP protection granting exclusive rights to reproduce, distribute, and modify a work. It covers the source code, not the underlying ideas or functionality. Most OSS licences are based on copyright, which is distinct from a creator’s moral rights.">copyright</a> notice placement, and metadata for automated <a href="#Compliance" title="Compliance: Adherence to licence, patent, and security requirements. Requires maintaining compatibility and compliance artefacts. It may include notice retention and source code provision. Often guided by standards like OpenChain. Reviews may trigger remediation.">compliance</a>, aligning with <a href="#FAIR" title="FAIR: Findability, Accessibility, Interoperability, and Reusability; a set of guiding principles to improve data management in open science. In software, supported by elaborated documentation artefacts and the REUSE specification.">FAIR</a> principles through improved accessibility and interoperability of <a href="#Licensing" title="Licensing: Governance of licence permissions, obligations, compliance artefacts, and dependency management; also granting permission to use intellectual property.">licensing</a> information.</dd>

<dt id="SBOM"><b>SBOM – Software Bill of Materials</b></dt>
<dd>Machine-readable <a href="#Dependency Inventory" title="Dependency Inventory: Human-readable list of dependencies such as external libraries, frameworks, or essential tools, with versions and licences, often forming the basis for an SBOM.">dependency inventory</a> of components and their licences, including <a href="#Transitive Dependency" title="Transitive Dependency: Dependency of a dependency, as opposed to a direct dependency listed in the project configuration. Their tracking is essential for SCA, SBOM accuracy, and licence compliance, as they may bring additional in-licences.">transitive dependencies</a>, often in <a href="#SPDX" title="SPDX – Software Package Data Exchange: Standard for machine-readable licence and component metadata, including standard identifiers (e.g. MIT, Apache-2.0, and BSD-3-Clause). It is widely used in SBOMs and REUSE headers for automated compliance checks.">SPDX</a> or CycloneDX format, and with <a href="#Semantic Versioning" title="Semantic Versioning: Standardised versioning scheme using MAJOR.MINOR.PATCH notation to communicate the scope of changes in software releases. Used in SBOM and CHANGELOG files.">semantic versioning</a> and provenance. It supports <a href="#Compliance" title="Compliance: Adherence to licence, patent, and security requirements. Requires maintaining compatibility and compliance artefacts. It may include notice retention and source code provision. Often guided by standards like OpenChain. Reviews may trigger remediation.">compliance</a>, risk assessment, and <a href="#FAIR" title="FAIR: Findability, Accessibility, Interoperability, and Reusability; a set of guiding principles to improve data management in open science. In software, supported by elaborated documentation artefacts and the REUSE specification.">FAIR</a> principles by improving the findability and reusability of information.</dd>

<dt id="SCA"><b>SCA – Software Composition Analysis</b></dt>
<dd>Automated detection of <a href="#Dependency" title="Dependency: External component, library, or source code used by software, including both direct and transitive dependencies. Each typically carries an in-licence, and should be recorded in the dependency inventory or SBOM.">dependencies</a>, licences, and <a href="#Vulnerability" title="Vulnerability: Security flaw in software code that can be exploited to cause harm, compromise data, or gain unauthorised access. SCA tools identify known vulnerabilities in dependencies (often mapping them to CVE lists) and flag them for remediation.">vulnerabilities</a> (often using <a href="#CVE" title="CVE – Common Vulnerabilities and Exposures: System for referencing specific security vulnerabilities. SCA tools map dependencies to CVE lists to assess risk.">CVE</a> identifiers) to support <a href="#Compliance" title="Compliance: Adherence to licence, patent, and security requirements. Requires maintaining compatibility and compliance artefacts. It may include notice retention and source code provision. Often guided by standards like OpenChain. Reviews may trigger remediation.">compliance</a>, risk assessment, and <a href="#Remediation" title="Remediation: Process of resolving identified issues in a software project, such as updating outdated dependencies with vulnerabilities, replacing incompatible licences or correcting missing notices, to restore compliance and reduce security or legal risk.">remediation</a>. Tools may be integrated into <a href="#CI" title="CI – Continuous Integration: Automated build and test process for software changes. It often integrates SCA and other tools, providing immediate feedback on dependencies with vulnerabilities and licence compliance.">CI</a> or <a href="#CI/CD" title="CI/CD – Continuous Integration / Continuous Delivery: Automated pipeline covering CI, testing, and delivery of software to production or release environments. SCA can be applied to catch issues prior to deployment or release.">CI/CD</a> and include <a href="#Snippet Detection" title="Snippet Detection: Scanning source code during SCA to find short, often modified, fragments copied from external sources, by checking code fingerprints. This facilitates the detection of potentially undocumented or questionable code lacking attribution or licence acknowledgement, and is usually followed by snippet matching.">snippet detection</a> and <a href="#Snippet Matching" title="Snippet Matching: Verification of fragments identified during snippet detection by comparing them against a database of known source code to determine each snippet’s origin, licence, and degree of similarity to assess potential copyright infringement and compliance risk, guiding remediation.">snippet matching</a>.</dd>

<dt id="Secondary Licence"><b>Secondary Licence</b></dt>
<dd>Alternative licence permitted by a primary licence to facilitate <a href="#Compatibility" title="Compatibility: A shorthand for licence compatibility, which is the ability to combine or distribute software under different licences without violating their terms. For example, using MIT components within a GPL project, or Apache 2.0 code with GPL 3.0 as out-licence, require applying GPL to the combined work. It can be enhanced through dual and multi-licensing.">compatibility</a> with other <a href="#OSS" title="OSS – Open Source Software: Software under licences recognised by the OSI or FSF that grant rights to use, modify, and distribute source code. It is often referred to as FOSS (or FLOSS) to explicitly include free software principles. Usage of software and licences is guided by an organisation’s IPR Policy, while an OSPO may promote adoption and manage strategy, contribution policies, and compliance.">open source</a> licences.</dd>

<dt id="Semantic Versioning"><b>Semantic Versioning</b></dt>
<dd>Standardised versioning scheme using MAJOR.MINOR.PATCH notation to communicate the scope of changes in software releases. Used in <a href="#SBOM" title="SBOM – Software Bill of Materials: Machine-readable dependency inventory of components and their licences, including transitive dependencies, often in SPDX or CycloneDX format, and with semantic versioning and provenance. It supports compliance, risk assessment, and FAIR principles by improving the findability and reusability of information.">SBOM</a> and <a href="#CHANGELOG File" title="CHANGELOG File / Changelog / Change Log: Record of notable changes between releases, relevant for licence compliance. Often written in Markdown, with entries following semantic versioning to indicate release levels and changes. See HISTORY File.">CHANGELOG</a> files.</dd>

<dt id="Shareware"><b>Shareware</b></dt>
<dd><a href="#Proprietary Software" title="Proprietary Software: Software distributed under highly restrictive terms (often in an EULA) limiting access, modification, or distribution, and typically sold as closed source software. It may involve trademarks, and be distributed as commercial software, freeware, or shareware.">Proprietary software</a> provided initially for free (often as a trial) with the expectation that the user will pay for continued use; distinctly different from <a href="#OSS" title="OSS – Open Source Software: Software under licences recognised by the OSI or FSF that grant rights to use, modify, and distribute source code. It is often referred to as FOSS (or FLOSS) to explicitly include free software principles. Usage of software and licences is guided by an organisation’s IPR Policy, while an OSPO may promote adoption and manage strategy, contribution policies, and compliance.">OSS</a>.</dd>

<dt id="Sideground IPR"><b>Sideground IPR</b></dt>
<dd><a href="#IPR" title="IPR – Intellectual Property Rights: Legal rights over intangible creations, including copyright, patents, trademarks, and trade secrets. Effective SLM requires distinguishing between these rights, particularly when managing sideground IPR and dependencies.">Intellectual property rights</a> of third-party <a href="#Dependency" title="Dependency: External component, library, or source code used by software, including both direct and transitive dependencies. Each typically carries an in-licence, and should be recorded in the dependency inventory or SBOM.">dependencies</a>, or other <a href="#Copyright" title="Copyright: Legal IP protection granting exclusive rights to reproduce, distribute, and modify a work. It covers the source code, not the underlying ideas or functionality. Most OSS licences are based on copyright, which is distinct from a creator’s moral rights.">copyrighted</a> work incorporated into a project, requiring proper handling to ensure licence <a href="#Compliance" title="Compliance: Adherence to licence, patent, and security requirements. Requires maintaining compatibility and compliance artefacts. It may include notice retention and source code provision. Often guided by standards like OpenChain. Reviews may trigger remediation.">compliance</a>.</dd>

<dt id="SLA"><b>SLA – Software Licence Analysis</b></dt>
<dd>Assessment of <a href="#Licensing" title="Licensing: Governance of licence permissions, obligations, compliance artefacts, and dependency management; also granting permission to use intellectual property.">licensing</a> in software projects within <a href="#SLM" title="SLM – Software and Licence Management: GÉANT subtask supported by the LT, relying on the GSC for software and access to compliance artefacts, and using SLA to assess compliance and risks.">SLM</a> involving the identification and review of applicable licences, their <a href="#Compatibility" title="Compatibility: A shorthand for licence compatibility, which is the ability to combine or distribute software under different licences without violating their terms. For example, using MIT components within a GPL project, or Apache 2.0 code with GPL 3.0 as out-licence, require applying GPL to the combined work. It can be enhanced through dual and multi-licensing.">compatibility</a>, and <a href="#Compliance Artefacts" title="Compliance Artefacts: Documentation artefacts or files required for licence adherence, such as LICENSE, NOTICE, and COPYRIGHT files. They include notice retention obligations to preserve copyright and licence notices in distributions.">compliance artefacts</a> to ensure <a href="#Compliance" title="Compliance: Adherence to licence, patent, and security requirements. Requires maintaining compatibility and compliance artefacts. It may include notice retention and source code provision. Often guided by standards like OpenChain. Reviews may trigger remediation.">compliance</a>. It is distinct from the common acronym for “Service Level Agreement.”</dd>

<dt id="SLM"><b>SLM – Software and Licence Management</b></dt>
<dd>GÉANT subtask supported by the <a href="#LT" title="LT – Licensing Team: GÉANT team in charge of SLM, coordinating software licensing, compliance, and governance.">LT</a>, relying on the <a href="#GSC" title="GSC – GÉANT Software Catalogue: Catalogue of GÉANT software. Used by the LT for SLM and to track software assets and licence status.">GSC</a> for software and access to <a href="#Compliance Artefacts" title="Compliance Artefacts: Documentation artefacts or files required for licence adherence, such as LICENSE, NOTICE, and COPYRIGHT files. They include notice retention obligations to preserve copyright and licence notices in distributions.">compliance artefacts</a>, and using <a href="#SLA" title="SLA – Software Licence Analysis: Assessment of licensing in software projects within SLM involving the identification and review of applicable licences, their compatibility, and compliance artefacts to ensure compliance. It is distinct from the common acronym for “Service Level Agreement.”">SLA</a> to assess <a href="#Compliance" title="Compliance: Adherence to licence, patent, and security requirements. Requires maintaining compatibility and compliance artefacts. It may include notice retention and source code provision. Often guided by standards like OpenChain. Reviews may trigger remediation.">compliance</a> and risks.</dd>

<dt id="Snippet Detection"><b>Snippet Detection</b></dt>
<dd>Scanning <a href="#Source Code" title="Source Code: Human-readable form of software that is often compiled into binaries. It is the primary IP asset protected by copyright, and required for OSS status.">source code</a> during <a href="#SCA" title="SCA – Software Composition Analysis: Automated detection of dependencies, licences, and vulnerabilities (often using CVE identifiers) to support compliance, risk assessment, and remediation. Tools may be integrated into CI or CI/CD and include snippet detection and snippet matching.">SCA</a> to find short, often modified, fragments copied from external sources, by checking code fingerprints. This facilitates the detection of potentially undocumented or questionable code lacking <a href="#Attribution" title="Attribution: Notice required by some licences (e.g. Apache, CC BY, and BSD) to preserve credit to original authors and contributors, reproduce the copyright statement, and indicate modifications.">attribution</a> or licence acknowledgement, and is usually followed by <a href="#Snippet Matching" title="Snippet Matching: Verification of fragments identified during snippet detection by comparing them against a database of known source code to determine each snippet’s origin, licence, and degree of similarity to assess potential copyright infringement and compliance risk, guiding remediation.">snippet matching</a>.</dd>

<dt id="Snippet Matching"><b>Snippet Matching</b></dt>
<dd>Verification of fragments identified during <a href="#Snippet Detection" title="Snippet Detection: Scanning source code during SCA to find short, often modified, fragments copied from external sources, by checking code fingerprints. This facilitates the detection of potentially undocumented or questionable code lacking attribution or licence acknowledgement, and is usually followed by snippet matching.">snippet detection</a> by comparing them against a database of known <a href="#Source Code" title="Source Code: Human-readable form of software that is often compiled into binaries. It is the primary IP asset protected by copyright, and required for OSS status.">source code</a> to determine each snippet’s origin, licence, and degree of similarity to assess potential <a href="#Copyright" title="Copyright: Legal IP protection granting exclusive rights to reproduce, distribute, and modify a work. It covers the source code, not the underlying ideas or functionality. Most OSS licences are based on copyright, which is distinct from a creator’s moral rights.">copyright</a> infringement and <a href="#Compliance" title="Compliance: Adherence to licence, patent, and security requirements. Requires maintaining compatibility and compliance artefacts. It may include notice retention and source code provision. Often guided by standards like OpenChain. Reviews may trigger remediation.">compliance</a> risk, guiding <a href="#Remediation" title="Remediation: Process of resolving identified issues in a software project, such as updating outdated dependencies with vulnerabilities, replacing incompatible licences or correcting missing notices, to restore compliance and reduce security or legal risk.">remediation</a>.</dd>

<dt id="Source Code"><b>Source Code</b></dt>
<dd>Human-readable form of software that is often compiled into <a href="#Binaries" title="Binaries: Compiled executable files and other binary resources, as opposed to source code. In proprietary software, only the binaries are typically distributed.">binaries</a>. It is the primary <a href="#IP" title="IP – Intellectual Property: Creations of the mind protected by law through copyright, patents, trademarks, and design rights. A licence specifies how others may use such protected works.">IP</a> asset protected by <a href="#Copyright" title="Copyright: Legal IP protection granting exclusive rights to reproduce, distribute, and modify a work. It covers the source code, not the underlying ideas or functionality. Most OSS licences are based on copyright, which is distinct from a creator’s moral rights.">copyright</a>, and required for <a href="#OSS" title="OSS – Open Source Software: Software under licences recognised by the OSI or FSF that grant rights to use, modify, and distribute source code. It is often referred to as FOSS (or FLOSS) to explicitly include free software principles. Usage of software and licences is guided by an organisation’s IPR Policy, while an OSPO may promote adoption and manage strategy, contribution policies, and compliance.">OSS</a> status.</dd>

<dt id="Source-Available"><b>Source-Available</b></dt>
<dd>Licence or software with viewable <a href="#Source Code" title="Source Code: Human-readable form of software that is often compiled into binaries. It is the primary IP asset protected by copyright, and required for OSS status.">source code</a> that lacks full <a href="#OSS" title="OSS – Open Source Software: Software under licences recognised by the OSI or FSF that grant rights to use, modify, and distribute source code. It is often referred to as FOSS (or FLOSS) to explicitly include free software principles. Usage of software and licences is guided by an organisation’s IPR Policy, while an OSPO may promote adoption and manage strategy, contribution policies, and compliance.">OSS</a> freedoms due to restrictive terms (e.g. <a href="#Elastic License" title="Elastic License: Source-available licence prohibiting offering the software as a managed service, and bypassing key protections; this usage restriction makes it an exemplary fauxpen.">Elastic License</a>, <a href="#SSPL" title="SSPL – Server Side Public License: Network-protective, strong copyleft, and source-available licence requiring release of service management layer source code when providing a service. Its additional obligations on the surrounding service stack make it fauxpen.">SSPL</a>). Unlike <a href="#Closed Source Software" title="Closed Source Software: Software distributed without source code access or modification rights, unlike OSS or source-available software.">Closed Source Software</a>, the code is viewable and often modifiable, but the licence is <a href="#Fauxpen" title="Fauxpen: Software or licence presented as OSS but effectively controlled by the vendor, restricting true OSS freedoms (e.g. Elastic License or SSPL).">fauxpen</a> or contains <a href="#Usage Restriction" title="Usage Restriction: Licence term limiting certain uses of the software, including military, nuclear, surveillance, or business models. Such restrictions (e.g. preventing commercial software distribution or remote use as a service) prevent a licence from qualifying as OSS or FOSS.">usage restrictions</a> that prevent it from being classified as <a href="#OSS" title="OSS – Open Source Software: Software under licences recognised by the OSI or FSF that grant rights to use, modify, and distribute source code. It is often referred to as FOSS (or FLOSS) to explicitly include free software principles. Usage of software and licences is guided by an organisation’s IPR Policy, while an OSPO may promote adoption and manage strategy, contribution policies, and compliance.">OSS</a> or <a href="#FOSS" title="FOSS – Free and Open Source Software / FLOSS: Software meeting free software criteria set by the FSF; FOSS licences are a subset of OSS licences. In FLOSS, L stands for libre to emphasise freedom rather than price.">FOSS</a>.</dd>

<dt id="SPDX"><b>SPDX – Software Package Data Exchange</b></dt>
<dd>Standard for machine-readable licence and component metadata, including standard identifiers (e.g. MIT, Apache-2.0, and BSD-3-Clause). It is widely used in <a href="#SBOM" title="SBOM – Software Bill of Materials: Machine-readable dependency inventory of components and their licences, including transitive dependencies, often in SPDX or CycloneDX format, and with semantic versioning and provenance. It supports compliance, risk assessment, and FAIR principles by improving the findability and reusability of information.">SBOMs</a> and <a href="#REUSE" title="REUSE: FSFE initiative defining standardised file headers, licence text and copyright notice placement, and metadata for automated compliance, aligning with FAIR principles through improved accessibility and interoperability of licensing information.">REUSE</a> headers for automated compliance checks.</dd>

<dt id="SSPL"><b>SSPL – Server Side Public License</b></dt>
<dd><a href="#Network-Protective Licence" title="Network-Protective Licence: Strong copyleft licences (such as the AGPL or SSPL) designed to close the cloud gap by treating use over a network (remote use) as distribution. This triggers the requirement to disclose the modified source code.">Network-protective</a>, <a href="#Strong Copyleft" title="Strong Copyleft: Licensing model requiring derivatives to remain under the same terms or licence (e.g. GPL, AGPL, EUPL, and CC BY-SA). SSPL is a strong copyleft source-available licence.">strong copyleft</a>, and <a href="#Source-Available" title="Source-Available: Licence or software with viewable source code that lacks full OSS freedoms due to restrictive terms (e.g. Elastic License, SSPL). Unlike Closed Source Software, the code is viewable and often modifiable, but the licence is fauxpen or contains usage restrictions that prevent it from being classified as OSS or FOSS.">source-available licence</a> requiring release of service management layer <a href="#Source Code" title="Source Code: Human-readable form of software that is often compiled into binaries. It is the primary IP asset protected by copyright, and required for OSS status.">source code</a> when providing a service. Its additional obligations on the surrounding service stack make it <a href="#Fauxpen" title="Fauxpen: Software or licence presented as OSS but effectively controlled by the vendor, restricting true OSS freedoms (e.g. Elastic License or SSPL).">fauxpen</a>.</dd>

<dt id="Static Linking"><b>Static Linking</b></dt>
<dd>Copying library code directly into the main executable <a href="#Binaries" title="Binaries: Compiled executable files and other binary resources, as opposed to source code. In proprietary software, only the binaries are typically distributed.">binary</a>. For <a href="#Weak Copyleft" title="Weak Copyleft: Copyleft scheme used by LGPL, MPL, EPL, and CDDL, where the obligation to share modifications applies only to the specific source code files or libraries, not the entire application. This allows linking with differently licensed or proprietary software.">weak copyleft</a> licences like <a href="#LGPL" title="LGPL – GNU Lesser General Public License: Weak copyleft licence permitting dynamic linking with differently licensed or proprietary software. Static linking is allowed if the user receives the source code and information required to rebuild the work with a modified version of the library.">LGPL</a>, this may trigger obligations to provide object code or <a href="#Source Code" title="Source Code: Human-readable form of software that is often compiled into binaries. It is the primary IP asset protected by copyright, and required for OSS status.">source code</a> to allow relinking.</dd>

<dt id="Strong Copyleft"><b>Strong Copyleft</b></dt>
<dd>Licensing model requiring <a href="#Derivative" title="Derivative / Derivative Work: Work based on or incorporating an existing copyrighted work, including modified versions. Under copyleft, it must use the same or a compatible licence, whereas licences like CC BY-ND explicitly prohibit modifications.">derivatives</a> to remain under the same terms or licence (e.g. <a href="#GPL" title="GPL – GNU General Public License: Strong copyleft licence requiring derivatives to use the same licence. Versions 2.0 and 3.0 are not mutually compatible. The latter addresses the IoT gap.">GPL</a>, <a href="#AGPL" title="AGPL – GNU Affero General Public License: Strong copyleft licence requiring source code disclosure to all users, even for networked or remote use (e.g. as a service), thereby closing the cloud gap.">AGPL</a>, <a href="#EUPL" title="EUPL – European Union Public Licence: EU-approved copyleft licence designed for interoperability, compatible with various OSS licences like the GPL.">EUPL</a>, and <a href="#CC BY-SA" title="CC BY-SA – Creative Commons Attribution-ShareAlike: Strong copyleft licence for content, requiring attribution and mandating that derivatives be distributed under identical terms. Similar to the GPL, but generally not compatible with software licences unless a specific compatibility clause (in version 4.0 for GPL 3.0) is invoked.">CC BY-SA</a>). <a href="#SSPL" title="SSPL – Server Side Public License: Network-protective, strong copyleft, and source-available licence requiring release of service management layer source code when providing a service. Its additional obligations on the surrounding service stack make it fauxpen.">SSPL</a> is a strong copyleft <a href="#Source-Available" title="Source-Available: Licence or software with viewable source code that lacks full OSS freedoms due to restrictive terms (e.g. Elastic License, SSPL). Unlike Closed Source Software, the code is viewable and often modifiable, but the licence is fauxpen or contains usage restrictions that prevent it from being classified as OSS or FOSS.">source-available licence</a>.</dd>

<dt id="Sublicensing"><b>Sublicensing</b></dt>
<dd>Allowing a <a href="#Licensee" title="Licensee: Individual or organisation granted specific rights to use or modify software under the terms of a licence.">licensee</a> to pass on certain rights to a third party without transferring <a href="#Copyright" title="Copyright: Legal IP protection granting exclusive rights to reproduce, distribute, and modify a work. It covers the source code, not the underlying ideas or functionality. Most OSS licences are based on copyright, which is distinct from a creator’s moral rights.">copyright</a> or changing licence terms; <a href="#Permissive Licence" title="Permissive Licence: Licence allowing use, modification, and distribution with minimal obligations, such as preserving copyright and licence text, and without imposing the same licence on derivatives (e.g. MIT, BSD, Apache, ISC, Artistic, and PSFL). These generally allow sublicensing without requiring a CLA.">permissive licences</a> allow it, <a href="#Copyleft" title="Copyleft: Licensing principle requiring derivatives to remain under the same or a compatible licence, ensuring software freedom (e.g. GPL, AGPL). This is based on the principle of reciprocity.">copyleft</a> licences restrict it to the same terms, and <a href="#Commercial Licence" title="Commercial Licence: Licence granting rights to use, modify, or distribute software for commercial purposes, often under restrictive proprietary software terms, and typically requiring payment or authorisation. These licences typically define usage restrictions not found in OSS licences.">commercial licences</a> usually forbid it.</dd>

<dt id="Subsuming Licence"><b>Subsuming Licence</b></dt>
<dd>Licence that governs a combined work when incorporated <a href="#Dependency" title="Dependency: External component, library, or source code used by software, including both direct and transitive dependencies. Each typically carries an in-licence, and should be recorded in the dependency inventory or SBOM.">dependencies</a> impose conditions on the whole, similar to an <a href="#Out-Licence" title="Out-Licence / Outbound Licence: Licence applied to distributed software, which may differ from the in-licences of its dependencies. It defines the terms under which the downstream user can use the software.">out-licence</a> but not necessarily implying <a href="#Distribution" title="Distribution: Providing software to third parties, triggering licence compliance obligations such as providing source code or maintaining notice retention.">distribution</a>. “Subsuming into” means incorporating one work into a larger one so it becomes subject to that subsuming licence.</dd>

<dt id="Trademark"><b>Trademark</b></dt>
<dd>Legally protected sign, name, logo, symbol, design, or other identifying mark distinguishing goods or services from those of others. In <a href="#OSS" title="OSS – Open Source Software: Software under licences recognised by the OSI or FSF that grant rights to use, modify, and distribute source code. It is often referred to as FOSS (or FLOSS) to explicitly include free software principles. Usage of software and licences is guided by an organisation’s IPR Policy, while an OSPO may promote adoption and manage strategy, contribution policies, and compliance.">OSS</a>, trademarks protect the identity and brand of the project, which is a form of <a href="#IP" title="IP – Intellectual Property: Creations of the mind protected by law through copyright, patents, trademarks, and design rights. A licence specifies how others may use such protected works.">IP</a> separate from the code’s <a href="#Copyright" title="Copyright: Legal IP protection granting exclusive rights to reproduce, distribute, and modify a work. It covers the source code, not the underlying ideas or functionality. Most OSS licences are based on copyright, which is distinct from a creator’s moral rights.">copyright</a>.</dd>

<dt id="Transitive Dependency"><b>Transitive Dependency</b></dt>
<dd><a href="#Dependency" title="Dependency: External component, library, or source code used by software, including both direct and transitive dependencies. Each typically carries an in-licence, and should be recorded in the dependency inventory or SBOM.">Dependency</a> of a <a href="#Dependency" title="Dependency: External component, library, or source code used by software, including both direct and transitive dependencies. Each typically carries an in-licence, and should be recorded in the dependency inventory or SBOM.">dependency</a>, as opposed to a <a href="#Direct Dependency" title="Direct Dependency: Library or component explicitly requested by the source code (e.g. listed in “package.json” or “requirements.txt”), as opposed to a transitive dependency which is pulled in by another dependency.">direct dependency</a> listed in the project configuration. Their tracking is essential for <a href="#SCA" title="SCA – Software Composition Analysis: Automated detection of dependencies, licences, and vulnerabilities (often using CVE identifiers) to support compliance, risk assessment, and remediation. Tools may be integrated into CI or CI/CD and include snippet detection and snippet matching.">SCA</a>, <a href="#SBOM" title="SBOM – Software Bill of Materials: Machine-readable dependency inventory of components and their licences, including transitive dependencies, often in SPDX or CycloneDX format, and with semantic versioning and provenance. It supports compliance, risk assessment, and FAIR principles by improving the findability and reusability of information.">SBOM</a> accuracy, and licence <a href="#Compliance" title="Compliance: Adherence to licence, patent, and security requirements. Requires maintaining compatibility and compliance artefacts. It may include notice retention and source code provision. Often guided by standards like OpenChain. Reviews may trigger remediation.">compliance</a>, as they may bring additional <a href="#In-Licence" title="In-Licence / Inbound Licence: Licence of external components, libraries, or dependencies incorporated into a project, typically recorded in a dependency inventory or SBOM.">in-licences</a>.</dd>

<dt id="Unlicense"><b>Unlicense</b></dt>
<dd>Text used to dedicate a work to the <a href="#Public Domain" title="Public Domain: Works not protected by copyright, patent, or moral rights, due to expiration of IP protection or explicit waiver by the rights holder (e.g. via CC0 or Unlicense). In jurisdictions not recognising waivers, fallback permissive licences like 0BSD, Unlicense, or MIT-0 can be used.">public domain</a> by waiving all <a href="#Copyright" title="Copyright: Legal IP protection granting exclusive rights to reproduce, distribute, and modify a work. It covers the source code, not the underlying ideas or functionality. Most OSS licences are based on copyright, which is distinct from a creator’s moral rights.">copyright</a> and related rights. It includes a fallback <a href="#Permissive Licence" title="Permissive Licence: Licence allowing use, modification, and distribution with minimal obligations, such as preserving copyright and licence text, and without imposing the same licence on derivatives (e.g. MIT, BSD, Apache, ISC, Artistic, and PSFL). These generally allow sublicensing without requiring a CLA.">permissive licence</a> for jurisdictions where <a href="#Copyright" title="Copyright: Legal IP protection granting exclusive rights to reproduce, distribute, and modify a work. It covers the source code, not the underlying ideas or functionality. Most OSS licences are based on copyright, which is distinct from a creator’s moral rights.">copyright</a> or <a href="#Moral Rights" title="Moral Rights: Personal, often non-transferable rights of creators to be named as the author (attribution), and to object to derogatory treatment of their work. These rights persist even if copyright is transferred to another entity.">moral rights</a> cannot be legally abandoned.</dd>

<dt id="Upstream"><b>Upstream</b></dt>
<dd>Original project or repository from which <a href="#Source Code" title="Source Code: Human-readable form of software that is often compiled into binaries. It is the primary IP asset protected by copyright, and required for OSS status.">source code</a> is derived or consumed. <a href="#Downstream" title="Downstream: Any project, organisation, or user that consumes, integrates, or distributes software from an upstream source. Downstream users inherit the compliance obligations defined by the out-licence of upstream software.">Downstream</a> projects build upon it or <a href="#Distribution" title="Distribution: Providing software to third parties, triggering licence compliance obligations such as providing source code or maintaining notice retention.">distribute</a> its <a href="#Source Code" title="Source Code: Human-readable form of software that is often compiled into binaries. It is the primary IP asset protected by copyright, and required for OSS status.">code</a>, potentially triggering licence obligations and <a href="#Compliance" title="Compliance: Adherence to licence, patent, and security requirements. Requires maintaining compatibility and compliance artefacts. It may include notice retention and source code provision. Often guided by standards like OpenChain. Reviews may trigger remediation.">compliance</a> requirements. Upstream <a href="#Contribution" title="Contribution: Any source code or documentation artefacts submitted to a project, typically governed by a CLA or DCO, forming part of the project’s copyright and licensing framework while respecting the contributor’s moral rights. See Upstream.">contributions</a> provide fixes, enhancements, or new features back to the original source to benefit all users.</dd>

<dt id="Usage Restriction"><b>Usage Restriction</b></dt>
<dd>Licence term limiting certain uses of the software, including military, nuclear, surveillance, or business models. Such restrictions (e.g. preventing <a href="#Commercial Software" title="Commercial Software: Software sold or licensed for profit, typically under a commercial licence or other restrictive proprietary software terms. It may involve trademarks or follow an Open Core model, where proprietary features are built atop community OSS through dual and multi-licensing.">commercial software</a> <a href="#Distribution" title="Distribution: Providing software to third parties, triggering licence compliance obligations such as providing source code or maintaining notice retention.">distribution</a> or <a href="#Remote Use" title="Remote Use: Use of software over a network (e.g. Software as a Service), rather than running a local copy. In standard copyleft licences, this does not trigger distribution obligations, whereas network-protective licences (like AGPL) treat this interaction as a trigger for source code disclosure.">remote use</a> as a service) prevent a licence from qualifying as <a href="#OSS" title="OSS – Open Source Software: Software under licences recognised by the OSI or FSF that grant rights to use, modify, and distribute source code. It is often referred to as FOSS (or FLOSS) to explicitly include free software principles. Usage of software and licences is guided by an organisation’s IPR Policy, while an OSPO may promote adoption and manage strategy, contribution policies, and compliance.">OSS</a> or <a href="#FOSS" title="FOSS – Free and Open Source Software / FLOSS: Software meeting free software criteria set by the FSF; FOSS licences are a subset of OSS licences. In FLOSS, L stands for libre to emphasise freedom rather than price.">FOSS</a>.</dd>

<dt id="Vulnerability"><b>Vulnerability</b></dt>
<dd>Security flaw in software code that can be exploited to cause harm, compromise data, or gain unauthorised access. <a href="#SCA" title="SCA – Software Composition Analysis: Automated detection of dependencies, licences, and vulnerabilities (often using CVE identifiers) to support compliance, risk assessment, and remediation. Tools may be integrated into CI or CI/CD and include snippet detection and snippet matching.">SCA</a> tools identify known vulnerabilities in <a href="#Dependency" title="Dependency: External component, library, or source code used by software, including both direct and transitive dependencies. Each typically carries an in-licence, and should be recorded in the dependency inventory or SBOM.">dependencies</a> (often mapping them to <a href="#CVE" title="CVE – Common Vulnerabilities and Exposures: System for referencing specific security vulnerabilities. SCA tools map dependencies to CVE lists to assess risk.">CVE</a> lists) and flag them for <a href="#Remediation" title="Remediation: Process of resolving identified issues in a software project, such as updating outdated dependencies with vulnerabilities, replacing incompatible licences or correcting missing notices, to restore compliance and reduce security or legal risk.">remediation</a>.</dd>

<dt id="Warranty Disclaimer"><b>Warranty Disclaimer</b></dt>
<dd>Clause stating that the software is provided “as is” without guarantees of fitness or quality. It protects the <a href="#Copyright Holder" title="Copyright Holder: Individual or entity owning exclusive rights to a work and granting permissions via a licence, typically identified in the COPYRIGHT file. See Copyright.">copyright holder</a> and <a href="#Contribution" title="Contribution: Any source code or documentation artefacts submitted to a project, typically governed by a CLA or DCO, forming part of the project’s copyright and licensing framework while respecting the contributor’s moral rights. See Upstream.">contributors</a> from liability and is typically included in the <a href="#LICENSE File" title="LICENSE File: File containing the full licence text, essential for legal compliance and distribution. See COPYING File.">LICENSE file</a> or <a href="#COPYRIGHT File" title="COPYRIGHT File: Lists copyright holders and years, providing a clear ownership record, often with related legal notices, such as a warranty disclaimer.">COPYRIGHT file</a>.</dd>

<dt id="Weak Copyleft"><b>Weak Copyleft</b></dt>
<dd><a href="#Copyleft" title="Copyleft: Licensing principle requiring derivatives to remain under the same or a compatible licence, ensuring software freedom (e.g. GPL, AGPL). This is based on the principle of reciprocity.">Copyleft</a> scheme used by <a href="#LGPL" title="LGPL – GNU Lesser General Public License: Weak copyleft licence permitting dynamic linking with differently licensed or proprietary software. Static linking is allowed if the user receives the source code and information required to rebuild the work with a modified version of the library.">LGPL</a>, <a href="#MPL" title="MPL – Mozilla Public License: Weak copyleft licence permitting file-level mixing by treating source code files as individual copyright units. Modifications to files under MPL must remain under it, but files under other licences can be compiled together with them into a single binary.">MPL</a>, <a href="#EPL" title="EPL – Eclipse Public License: Business-friendly weak copyleft licence that applies copyleft terms only to the file level, allowing proprietary software to link to the source code under it, but incompatible with the GPL.">EPL</a>, and <a href="#CDDL" title="CDDL – Common Development and Distribution License: Weak copyleft licence, mainly used for Java projects. It allows linking with proprietary software, but is not compatible with the GPL.">CDDL</a>, where the obligation to share modifications applies only to the specific <a href="#Source Code" title="Source Code: Human-readable form of software that is often compiled into binaries. It is the primary IP asset protected by copyright, and required for OSS status.">source code</a> files or libraries, not the entire application. This allows linking with differently licensed or <a href="#Proprietary Software" title="Proprietary Software: Software distributed under highly restrictive terms (often in an EULA) limiting access, modification, or distribution, and typically sold as closed source software. It may involve trademarks, and be distributed as commercial software, freeware, or shareware.">proprietary software</a>.</dd>

</dl>