<dl>
<dt id="0BSD"><b>0BSD – Zero-Clause BSD</b></dt>
<dd>A <a href="#Public_Domain" title="Public Domain: Works not protected by copyright, either because copyright has expired or has been waived (e.g., via CC0). In jurisdictions where public-domain dedication is not recognised, permissive licences such as 0BSD, Unlicense, or MIT-0 can be used.">public domain</a>-equivalent <a href="#Permissive_Licence" title="Permissive Licence: Licence allowing use, modification, and redistribution 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, PSFL).">permissive licence</a> that does not require <a href="#Attribution" title="Attribution: Notice required by some licences (e.g. Apache, CC BY, BSD License) to preserve credit to original authors and contributors, and to 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 where legally possible.">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="#Network_Protective" title="Network-Protective Licence: Strong copyleft licence requiring source code disclosure in case of remote use (e.g. AGPL).">Network-protective</a> and <a href="#Strong_Copyleft" title="Strong Copyleft: Licensing model requiring derivatives to remain under the same terms or licence (e.g. GPL, AGPL, EUPL, 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.">source code</a> disclosure in case of <a href="#Remote_Use" title="Remote Use: Use of software over a network, potentially triggering copyleft obligations.">remote use</a>, including when the software is accessed as a service.</dd>

<dt id="Apache_License"><b>Apache License</b></dt>
<dd><a href="#Permissive_Licence" title="Permissive Licence: Licence allowing use, modification, and redistribution 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, PSFL).">Permissive licence</a> with <a href="#Patent" title="Patent: Legal protection granting exclusive rights to an invention, preventing others from making, using, selling, or distributing it without permission.">patent</a> protection, <a href="#Attribution" title="Attribution: Notice required by some licences (e.g. Apache, CC BY, BSD License) to preserve credit to original authors and contributors, and to indicate modifications.">attribution</a> requirements, and a <a href="#Patent_Retaliation_Clause" title="Patent Retaliation Clause: Licence term revoking rights and the patent grant if the licencee initiates a patent claim, deterring patent trolling, and implementing defensive termination.">patent retaliation clause</a>, including a <a href="#Patent_Grant" title="Patent Grant: Permission to use patents associated with the software and its contributions, typically covering rights held by contributors and reducing legal uncertainty for users and distributors.">patent grant</a> that permits <a href="#Licencee" title="Licencee: Individual or organisation granted rights under a licence.">licencees</a> to use <a href="#Patent" title="Patent: Legal protection granting exclusive rights to an invention, preventing others from making, using, selling, or distributing it without permission.">patents</a> associated with the software.</dd>

<dt id="Artistic_License"><b>Artistic License</b></dt>
<dd><a href="#Permissive_Licence" title="Permissive Licence: Licence allowing use, modification, and redistribution 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, PSFL).">Permissive licence</a> originating from the Perl ecosystem; version 2 clarifies terms and has <a href="#Licence_Compatibility" title="Licence Compatibility: Ability to combine or distribute software under different licences without violating their terms. For example, MIT components within a GPL project, or Apache 2.0 code with GPL 3.0 as out-licence, require that GPL obligations are met for those components as well.">licence compatibility</a> with <a href="#GPL" title="GPL – GNU General Public License: Strong copyleft licence requiring derivatives to use the same licence.">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, attribution requirements, and a patent retaliation clause, including a patent grant that permits licencees to use patents associated with the software.">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>, <a href="#BSD_License" title="BSD License: Berkeley Software Distribution family of permissive licences with minimal redistribution conditions, requiring retention of attribution notices.">BSD License</a>) to preserve credit to original authors and contributors, and to indicate modifications.</dd>

<dt id="AUTHORS_File"><b>AUTHORS File</b></dt>
<dd>Lists original authors and major contributors for <a href="#Attribution" title="Attribution: Notice required by some licences (e.g. Apache, CC BY, BSD License) to preserve credit to original authors and contributors, and to indicate modifications.">attribution</a> and historical reference; contributor 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.">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.">source code</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 redistribution 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, PSFL).">permissive licences</a> with minimal redistribution conditions, requiring retention of <a href="#Attribution" title="Attribution: Notice required by some licences (e.g. Apache, CC BY, BSD License) to preserve credit to original authors and contributors, and to 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>, <a href="#CC_BY_SA" title="CC BY-SA – Creative Commons Attribution-ShareAlike: Licence requiring attribution, with derivatives licensed under identical terms; copyleft equivalent.">CC BY-SA</a>) and the <a href="#CC0" title="CC0 – Creative Commons Zero: Public-domain dedication waiving copyright and related rights where legally possible.">CC0</a> public-domain dedication for content and <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>, generally not for software. They are often used as a <a href="#Documentation_Licence" title="Documentation Licence: Licence covering manuals, diagrams, or other separate materials; often CC.">documentation licence</a> for manuals, diagrams, and other materials separate from 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, either because copyright has expired or has been waived (e.g., via CC0). In jurisdictions where public-domain dedication is not recognised, permissive licences such as 0BSD, Unlicense, or MIT-0 can be used.">Public-domain</a> dedication waiving <a href="#Copyright" title="Copyright: Legal protection granting exclusive rights to reproduce, distribute, modify, and publicly perform or display a work.">copyright</a> and related rights where legally possible.</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, BSD License) to preserve credit to original authors and contributors, and to 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.">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 / Open Source: Software under licences granting rights to use, modify, and distribute source code, including those recognised by the OSI or FSF. An organisation’s IPR Policy guides OSS use, contribution, and distribution, while an OSPO may promote adoption, establish contribution policies, ensure compliance, and guide OSS strategy.">OSS</a> licence due to <a href="#Usage_Restriction" title="Usage Restriction: Licence term limiting certain uses of the software, including remote use, commercial, military, surveillance, or other applications.">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.">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), and reciprocity in derivative works.">copyleft</a> equivalent with <a href="#Usage_Restriction" title="Usage Restriction: Licence term limiting certain uses of the software, including remote use, commercial, military, surveillance, or other applications.">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 obligations.">distribution</a> and commercial use, with <a href="#Attribution" title="Attribution: Notice required by some licences (e.g. Apache, CC BY, BSD License) to preserve credit to original authors and contributors, and to indicate modifications.">attribution</a>, but forbidding <a href="#Distribution" title="Distribution: Providing software to third parties, triggering licence obligations.">distribution</a> of modified versions.</dd>

<dt id="CC_BY_SA"><b>CC BY-SA – Creative Commons Attribution-ShareAlike</b></dt>
<dd>Licence requiring <a href="#Attribution" title="Attribution: Notice required by some licences (e.g. Apache, CC BY, BSD License) to preserve credit to original authors and contributors, and to indicate modifications.">attribution</a>, with <a href="#Derivative" title="Derivative / Derivative Work: Work based on or incorporating an existing copyrighted work, including modified versions.">derivatives</a> licensed under 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), and reciprocity in derivative works.">copyleft</a> equivalent.</dd>

<dt id="CDDL"><b>CDDL – Common Development and Distribution License</b></dt>
<dd><a href="#Weak_Copyleft" title="Weak Copyleft: Copyleft with limited scope (e.g. LGPL, MPL, EPL, CDDL), usually applying to modifications of the original source code, but allowing linking with differently licensed or proprietary software.">Weak copyleft</a> licence, mainly used for Java projects.</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: Ensuring software use adheres to licence, patent, and security requirements, often via audits. Licence compatibility and appropriate compliance artefacts are necessary to meet licence obligations, and standards such as OpenChain can guide organisational practices.">compliance</a>. Entries typically follow <a href="#Semantic_Versioning" title="Semantic Versioning: Versioning scheme using MAJOR.MINOR.PATCH notation (e.g. 1.2.3).">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; can integrate <a href="#SCA" title="SCA – Software Composition Analysis: Automated detection of dependencies, licences, and vulnerabilities, to support compliance, risk assessment, and remediation, often integrated into CI or CI/CD. SCA tools identify direct and transitive dependencies, and commonly report known vulnerabilities using CVE identifiers.">SCA</a> and other tools providing immediate feedback on <a href="#Dependency" title="Dependency: Component, library, or source code used by another software. Each external dependency typically carries an in-licence, and should be recorded in the dependency inventory or SBOM file.">dependencies</a> with <a href="#Vulnerability" title="Vulnerability: A weakness in software code that can be exploited; SCA tools are primarily used to identify known vulnerabilities (mapped to CVEs) in dependencies.">vulnerabilities</a> and licence <a href="#Compliance" title="Compliance: Ensuring software use adheres to licence, patent, and security requirements, often via audits. Licence compatibility and appropriate compliance artefacts are necessary to meet licence obligations, and standards such as OpenChain can guide organisational practices.">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; can integrate 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, to support compliance, risk assessment, and remediation, often integrated into CI or CI/CD. SCA tools identify direct and transitive dependencies, and commonly report known vulnerabilities using CVE identifiers.">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, documentation artefacts, or work submitted to a project, typically governed by a CLA or DCO, forming part of the project’s copyright and licensing framework. Contributors may retain moral rights, which must be respected even when the work is licensed or assigned. See Upstream Contribution.">contributions</a>; may include <a href="#Copyright" title="Copyright: Legal protection granting exclusive rights to reproduce, distribute, modify, and publicly perform or display a work.">copyright</a> transfer or <a href="#Sublicensing" title="Sublicensing: Allowing a licencee 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 obligations.">distributed</a> without <a href="#Source_Code" title="Source Code: Human-readable form of software that is often compiled into binaries.">source code</a> access or modification rights, unlike <a href="#OSS" title="OSS – Open Source Software / Open Source: Software under licences granting rights to use, modify, and distribute source code, including those recognised by the OSI or FSF. An organisation’s IPR Policy guides OSS use, contribution, and distribution, while an OSPO may promote adoption, establish contribution policies, ensure compliance, and guide OSS strategy.">OSS</a> or <a href="#Source_Available_Licence" title="Source-Available Licence / Source-Available Software: Licence or software with visible source code, but restrictive terms preventing OSS status (e.g. Elastic Licence, SSPL). Unlike Closed Source Software, the source code is viewable, though modification or redistribution may remain limited.">source-available software</a>.</dd>

<dt id="CODE_OF_CONDUCT_File"><b>CODE_OF_CONDUCT File / Code of Conduct</b></dt>
<dd>Document defining expected contributor behaviour.</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 obligations.">distribute</a> software for commercial purposes, often under restrictive <a href="#Proprietary_Software" title="Proprietary Software: Software distributed under restrictive terms limiting access, modification, or redistribution, often requiring authorisation or payment when it is commercial software sold for profit. Such software is typically governed by an EULA, and may be distributed as freeware or shareware. It may also involve trademarks, and is most often closed source software distributed without source code.">proprietary software</a> terms, and typically requiring payment or authorisation.</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.">commercial licence</a> or other restrictive <a href="#Proprietary_Software" title="Proprietary Software: Software distributed under restrictive terms limiting access, modification, or redistribution, often requiring authorisation or payment when it is commercial software sold for profit. Such software is typically governed by an EULA, and may be distributed as freeware or shareware. It may also involve trademarks, and is most often closed source software distributed without source code.">proprietary software</a> terms. It can follow an <a href="#Open_Core" title="Open Core: A business model where the core functionality of a product is OSS (often under a permissive licence or strong copyleft), while advanced features (enterprise security, monitoring) are proprietary software or source-available software.">Open Core</a> model, where the base software is <a href="#OSS" title="OSS – Open Source Software / Open Source: Software under licences granting rights to use, modify, and distribute source code, including those recognised by the OSI or FSF. An organisation’s IPR Policy guides OSS use, contribution, and distribution, while an OSPO may promote adoption, establish contribution policies, ensure compliance, and guide OSS strategy.">OSS</a>, while additional features or services are proprietary. It may include <a href="#Trademark" title="Trademark: Legally protected sign, name, logo, symbol, design, or other identifying mark distinguishing goods or services, granting the owner exclusive rights to its commercial use.">trademarks</a> to distinguish the software or its services.</dd>

<dt id="Compatibility"><b>Compatibility</b></dt>
<dd>See <a href="#Licence_Compatibility" title="Licence Compatibility: Ability to combine or distribute software under different licences without violating their terms. For example, MIT components within a GPL project, or Apache 2.0 code with GPL 3.0 as out-licence, require that GPL obligations are met for those components as well.">Licence Compatibility</a>. More broadly, the general ability of software, systems, or components to work together correctly, interoperate, or exchange data without conflict.</dd>

<dt id="Compliance"><b>Compliance</b></dt>
<dd>Ensuring software use adheres to licence, <a href="#Patent" title="Patent: Legal protection granting exclusive rights to an invention, preventing others from making, using, selling, or distributing it without permission.">patent</a>, and security requirements, often via audits. <a href="#Licence_Compatibility" title="Licence Compatibility: Ability to combine or distribute software under different licences without violating their terms. For example, MIT components within a GPL project, or Apache 2.0 code with GPL 3.0 as out-licence, require that GPL obligations are met for those components as well.">Licence compatibility</a> and appropriate <a href="#Compliance_Artefacts" title="Compliance Artefacts: Documentation artefacts or files required for licence adherence, such as LICENSE, NOTICE, and COPYRIGHT files, including notice retention obligations to preserve copyright and licence notices in distributions. Compliance reviews may trigger remediation, such as correcting notices to meet licence obligations.">compliance artefacts</a> are necessary to meet licence obligations, and 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> can guide organisational practices.</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. See COPYING File.">LICENSE</a>, <a href="#NOTICE_File" title="NOTICE File: Contains acknowledgements, attributions, and licence-related notices.">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, including <a href="#Notice_Retention" title="Notice Retention: Requirement to preserve copyright and licence notices in redistributions.">notice retention</a> obligations to preserve <a href="#Copyright" title="Copyright: Legal protection granting exclusive rights to reproduce, distribute, modify, and publicly perform or display a work.">copyright</a> and licence notices in <a href="#Distribution" title="Distribution: Providing software to third parties, triggering licence obligations.">distributions</a>. <a href="#Compliance" title="Compliance: Ensuring software use adheres to licence, patent, and security requirements, often via audits. Licence compatibility and appropriate compliance artefacts are necessary to meet licence obligations, and standards such as OpenChain can guide organisational practices.">Compliance</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>, such as correcting notices to meet licence obligations.</dd>

<dt id="CONTRIBUTING_File"><b>CONTRIBUTING File</b></dt>
<dd>Describes <a href="#Contribution" title="Contribution: Any source code, documentation artefacts, or work submitted to a project, typically governed by a CLA or DCO, forming part of the project’s copyright and licensing framework. Contributors may retain moral rights, which must be respected even when the work is licensed or assigned. See Upstream Contribution.">contribution</a> rules, including <a href="#Copyright" title="Copyright: Legal protection granting exclusive rights to reproduce, distribute, modify, and publicly perform or display a work.">copyright</a> and licence conditions, and sometimes <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> requirements. It may also reference the project’s <a href="#CODE_OF_CONDUCT_File" title="CODE_OF_CONDUCT File / Code of Conduct: Document defining expected contributor behaviour.">code of conduct</a> to define expected contributor behaviour.</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.">source code</a>, <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 work 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 protection granting exclusive rights to reproduce, distribute, modify, and publicly perform or display a work.">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. Contributors may retain <a href="#Moral_Rights" title="Moral Rights: Personal rights of creators (distinct from economic copyright) to be credited (attribution) and to prevent derogatory treatment of their work; these are often non-transferable and persist even if copyright is transferred.">moral rights</a>, which must be respected even when the work is licensed or assigned. See <a href="#Upstream_Contribution" title="Upstream Contribution: Improvement submitted to the original software or project.">Upstream Contribution</a>.</dd>

<dt id="CONTRIBUTORS_File"><b>CONTRIBUTORS File</b></dt>
<dd>Lists contributors; less common than <a href="#AUTHORS_File" title="AUTHORS File: Lists original authors and major 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><a href="#GNU" title="GNU – “GNU’s Not Unix”: Project behind the GPL, LGPL, and AGPL licence family, promoting free software and user freedoms.">GNU</a>-style file containing the full licence text, equivalent to <a href="#LICENSE_File" title="LICENSE File: File containing the full licence text. 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.">derivatives</a> to remain under the same or a <a href="#Licence_Compatibility" title="Licence Compatibility: Ability to combine or distribute software under different licences without violating their terms. For example, MIT components within a GPL project, or Apache 2.0 code with GPL 3.0 as out-licence, require that GPL obligations are met for those components as well.">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.">GPL</a>, <a href="#AGPL" title="AGPL – GNU Affero General Public License: Network-protective and strong copyleft licence requiring source code disclosure in case of remote use, including when the software is accessed as a service.">AGPL</a>), and <a href="#Reciprocity" title="Reciprocity: Principle requiring that rights granted under a licence (e.g. copyleft) must be extended to derivatives or redistributed versions.">reciprocity</a> in <a href="#Derivative" title="Derivative / Derivative Work: Work based on or incorporating an existing copyrighted work, including modified versions.">derivative works</a>.</dd>

<dt id="Copyright"><b>Copyright</b></dt>
<dd>Legal protection granting exclusive rights to reproduce, <a href="#Distribution" title="Distribution: Providing software to third parties, triggering licence obligations.">distribute</a>, modify, and publicly perform or display a work.</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.">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: Statement denying liability for damages.">warranty disclaimer</a>.</dd>

<dt id="Copyright_Holder"><b>Copyright Holder</b></dt>
<dd>Individual or entity owning exclusive rights to a work.</dd>

<dt id="CVE"><b>CVE – Common Vulnerabilities and Exposures</b></dt>
<dd>A system for referencing specific security <a href="#Vulnerability" title="Vulnerability: A weakness in software code that can be exploited; SCA tools are primarily used to identify known vulnerabilities (mapped to CVEs) in dependencies.">vulnerabilities</a>. <a href="#SCA" title="SCA – Software Composition Analysis: Automated detection of dependencies, licences, and vulnerabilities, to support compliance, risk assessment, and remediation, often integrated into CI or CI/CD. SCA tools identify direct and transitive dependencies, and commonly report known vulnerabilities using CVE identifiers.">SCA</a> tools map <a href="#Dependency" title="Dependency: Component, library, or source code used by another software. Each external dependency typically carries an in-licence, and should be recorded in the dependency inventory or SBOM file.">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 contributor’s “Signed-off-by” line in <a href="#Source_Code" title="Source Code: Human-readable form of software that is often compiled into binaries.">source code</a> commits.</dd>

<dt id="Defensive_Termination"><b>Defensive Termination</b></dt>
<dd>Licence clause revoking rights if the <a href="#Licencee" title="Licencee: Individual or organisation granted rights under a licence.">licencee</a> initiates <a href="#Patent" title="Patent: Legal protection granting exclusive rights to an invention, preventing others from making, using, selling, or distributing it without permission.">patent</a> litigation. See <a href="#Patent_Retaliation_Clause" title="Patent Retaliation Clause: Licence term revoking rights and the patent grant if the licencee initiates a patent claim, deterring patent trolling, and implementing defensive termination.">Patent Retaliation Clause</a>.</dd>

<dt id="Dependency"><b>Dependency</b></dt>
<dd>Component, library, or <a href="#Source_Code" title="Source Code: Human-readable form of software that is often compiled into binaries.">source code</a> used by another software. Each external dependency 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 external libraries, frameworks, or tools with versions and licences, often forming the basis for an SBOM File.">dependency inventory</a> or <a href="#SBOM_File" title="SBOM File – Software Bill of Materials: Machine-readable dependency inventory listing components and their licences, often in SPDX or CycloneDX format, with semantic versioning and provenance. It should include all components, including transitive dependencies, supporting FAIR principles by improving findability and reusability of information.">SBOM file</a>.</dd>

<dt id="Dependency_Inventory"><b>Dependency Inventory</b></dt>
<dd>Human-readable list of external libraries, frameworks, or tools with versions and licences, often forming the basis for an <a href="#SBOM_File" title="SBOM File – Software Bill of Materials: Machine-readable dependency inventory listing components and their licences, often in SPDX or CycloneDX format, with semantic versioning and provenance. It should include all components, including transitive dependencies, supporting FAIR principles by improving findability and reusability of information.">SBOM File</a>.</dd>

<dt id="Derivative"><b>Derivative / Derivative Work</b></dt>
<dd>Work based on or incorporating an existing copyrighted work, including modified versions.</dd>

<dt id="Distribution"><b>Distribution</b></dt>
<dd>Providing software to third parties, triggering licence obligations.</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 obligations.">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. See COPYING File.">LICENSE</a>, <a href="#NOTICE_File" title="NOTICE File: Contains acknowledgements, attributions, and licence-related notices.">NOTICE</a>, <a href="#CHANGELOG_File" title="CHANGELOG File / Changelog / Change Log: Record of notable changes between releases, relevant for licence compliance. Entries typically follow semantic versioning to indicate release levels and changes. See HISTORY File.">CHANGELOG</a>, and <a href="#CONTRIBUTING_File" title="CONTRIBUTING File: Describes contribution rules, including copyright and licence conditions, and sometimes CLA or DCO requirements. It may also reference the project’s code of conduct to define expected contributor behaviour.">CONTRIBUTING</a> files, typically following the software’s licence. Some are covered by a <a href="#Documentation_Licence" title="Documentation Licence: Licence covering manuals, diagrams, or other separate materials; often CC.">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 manuals, diagrams, or other separate materials; often <a href="#CC" title="CC – Creative Commons: Family of licences (CC BY, CC BY-NC, CC BY-NC-SA, CC BY-ND, CC BY-SA) and the CC0 public-domain dedication for content and documentation artefacts, generally not for software. They are often used as a documentation licence for manuals, diagrams, and other materials separate from software.">CC</a>.</dd>

<dt id="Downstream"><b>Downstream</b></dt>
<dd>Recipient project, organisation, or user that uses or <a href="#Distribution" title="Distribution: Providing software to third parties, triggering licence obligations.">distributes</a> <a href="#Upstream_Software" title="Upstream Software: Original software from which other software is derived. A downstream project or user receives and builds upon it, potentially triggering licence obligations and compliance requirements.">upstream software</a>.</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 obligations.">Distribution</a> under multiple licences, allowing <a href="#Licencee" title="Licencee: Individual or organisation granted rights under a licence.">licencees</a> to select which applies (e.g. MySQL: <a href="#GPL" title="GPL – GNU General Public License: Strong copyleft licence requiring derivatives to use the same licence.">GPL</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.">commercial licence</a>, Qt: <a href="#LGPL" title="LGPL – GNU Lesser General Public License: Weak copyleft licence used mainly for libraries. It permits dynamic linking with differently licensed or proprietary software. Static linking is allowed when users receive the build information, the source code for the LGPL parts and whatever is needed to rebuild the larger work with a modified version of the library.">LGPL</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.">commercial licence</a>). 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-licence</a> of incorporated components must be <a href="#Licence_Compatibility" title="Licence Compatibility: Ability to combine or distribute software under different licences without violating their terms. For example, MIT components within a GPL project, or Apache 2.0 code with GPL 3.0 as out-licence, require that GPL obligations are met for those components as well.">compatible</a> with the <a href="#Out_Licence" title="Out-Licence / Outbound Licence: Licence applied to distributed software, which may differ from the licences of its dependencies.">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>. A <a href="#Secondary_Licence" title="Secondary Licence: Alternative licence permitted by a primary licence for compatibility.">secondary licence</a> is often an example of dual licensing.</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: Ensuring software use adheres to licence, patent, and security requirements, often via audits. Licence compatibility and appropriate compliance artefacts are necessary to meet licence obligations, and standards such as OpenChain can guide organisational practices.">compliance</a> with <a href="#LGPL" title="LGPL – GNU Lesser General Public License: Weak copyleft licence used mainly for libraries. It permits dynamic linking with differently licensed or proprietary software. Static linking is allowed when users receive the build information, the source code for the LGPL parts and whatever is needed to rebuild the larger 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 restrictive terms limiting access, modification, or redistribution, often requiring authorisation or payment when it is commercial software sold for profit. Such software is typically governed by an EULA, and may be distributed as freeware or shareware. It may also involve trademarks, and is most often closed source software distributed without source code.">proprietary software</a>.</dd>

<dt id="Elastic_Licence"><b>Elastic Licence</b></dt>
<dd><a href="#Source_Available_Licence" title="Source-Available Licence / Source-Available Software: Licence or software with visible source code, but restrictive terms preventing OSS status (e.g. Elastic Licence, SSPL). Unlike Closed Source Software, the source code is viewable, though modification or redistribution may remain limited.">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 remote use, commercial, military, surveillance, or other applications.">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, SSPL).">fauxpen</a>.</dd>

<dt id="EPL"><b>EPL – Eclipse Public License</b></dt>
<dd><a href="#Weak_Copyleft" title="Weak Copyleft: Copyleft with limited scope (e.g. LGPL, MPL, EPL, CDDL), usually applying to modifications of the original source code, but allowing linking with differently licensed or proprietary software.">Weak copyleft</a> file-scoped licence commonly used in the Java ecosystem.</dd>

<dt id="EULA"><b>EULA – End User Licence Agreement</b></dt>
<dd><a href="#Proprietary_Software" title="Proprietary Software: Software distributed under restrictive terms limiting access, modification, or redistribution, often requiring authorisation or payment when it is commercial software sold for profit. Such software is typically governed by an EULA, and may be distributed as freeware or shareware. It may also involve trademarks, and is most often closed source software distributed without source code.">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), and reciprocity in derivative works.">copyleft</a> licence <a href="#Licence_Compatibility" title="Licence Compatibility: Ability to combine or distribute software under different licences without violating their terms. For example, MIT components within a GPL project, or Apache 2.0 code with GPL 3.0 as out-licence, require that GPL obligations are met for those components as well.">compatible</a> with various <a href="#OSS" title="OSS – Open Source Software / Open Source: Software under licences granting rights to use, modify, and distribute source code, including those recognised by the OSI or FSF. An organisation’s IPR Policy guides OSS use, contribution, and distribution, while an OSPO may promote adoption, establish contribution policies, ensure compliance, and guide OSS strategy.">OSS</a> licences.</dd>

<dt id="FAIR"><b>FAIR</b></dt>
<dd>Findability, Accessibility, Interoperability, and Reusability principle in open science.</dd>

<dt id="Fauxpen"><b>Fauxpen</b></dt>
<dd>Software or licence presented as <a href="#OSS" title="OSS – Open Source Software / Open Source: Software under licences granting rights to use, modify, and distribute source code, including those recognised by the OSI or FSF. An organisation’s IPR Policy guides OSS use, contribution, and distribution, while an OSPO may promote adoption, establish contribution policies, ensure compliance, and guide OSS strategy.">OSS</a> but effectively controlled by the vendor, restricting true OSS freedoms (e.g. <a href="#Elastic_Licence" title="Elastic Licence: 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 Licence: 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="FLOSS"><b>FLOSS – Free/Libre Open Source Software</b></dt>
<dd>Term mainly used in academic and policy contexts; <em>libre</em> emphasises freedom rather than price. See <a href="#FOSS" title="FOSS – Free and Open Source Software: Software meeting free software criteria set by the FSF; FOSS licences are a subset of OSS licences. See FLOSS.">FOSS</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 / Open Source: Software under licences granting rights to use, modify, and distribute source code, including those recognised by the OSI or FSF. An organisation’s IPR Policy guides OSS use, contribution, and distribution, while an OSPO may promote adoption, establish contribution policies, ensure compliance, and guide OSS strategy.">OSS</a> version in response to <a href="#Relicensing" title="Relicensing: Changing a licence of existing software, often to improve licence 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 restrictive terms limiting access, modification, or redistribution, often requiring authorisation or payment when it is commercial software sold for profit. Such software is typically governed by an EULA, and may be distributed as freeware or shareware. It may also involve trademarks, and is most often closed source software distributed without source code.">proprietary licence</a>, or to prepare an <a href="#Upstream_Contribution" title="Upstream Contribution: Improvement submitted to the original software or project.">upstream contribution</a> back to the original project.</dd>

<dt id="FOSS"><b>FOSS – Free and Open Source Software</b></dt>
<dd>Software meeting <a href="#Free_Software" title="Free Software: Software granting users freedom to use, modify, and share it, per FSF definition.">free software</a> criteria set by the <a href="#FSF" title="FSF – Free Software Foundation: Organisation maintaining GNU licences, and promoting user freedoms.">FSF</a>; FOSS licences are a subset of <a href="#OSS" title="OSS – Open Source Software / Open Source: Software under licences granting rights to use, modify, and distribute source code, including those recognised by the OSI or FSF. An organisation’s IPR Policy guides OSS use, contribution, and distribution, while an OSPO may promote adoption, establish contribution policies, ensure compliance, and guide OSS strategy.">OSS</a> licences. See <a href="#FLOSS" title="FLOSS – Free/Libre Open Source Software: Term mainly used in academic and policy contexts; libre emphasises freedom rather than price. See FOSS.">FLOSS</a>.</dd>

<dt id="Free_Software"><b>Free Software</b></dt>
<dd>Software granting users freedom to use, modify, and share it, per <a href="#FSF" title="FSF – Free Software Foundation: Organisation maintaining GNU licences, and promoting user freedoms.">FSF</a> definition.</dd>

<dt id="Freeware"><b>Freeware</b></dt>
<dd><a href="#Proprietary_Software" title="Proprietary Software: Software distributed under restrictive terms limiting access, modification, or redistribution, often requiring authorisation or payment when it is commercial software sold for profit. Such software is typically governed by an EULA, and may be distributed as freeware or shareware. It may also involve trademarks, and is most often closed source software distributed without source code.">Proprietary software</a> available at no cost, but without the freedoms to modify or redistribute <a href="#Source_Code" title="Source Code: Human-readable form of software that is often compiled into binaries.">source code</a> inherent to <a href="#Free_Software" title="Free Software: Software granting users freedom to use, modify, and share it, per FSF definition.">free software</a> or <a href="#OSS" title="OSS – Open Source Software / Open Source: Software under licences granting rights to use, modify, and distribute source code, including those recognised by the OSI or FSF. An organisation’s IPR Policy guides OSS use, contribution, and distribution, while an OSPO may promote adoption, establish contribution policies, ensure compliance, and guide OSS strategy.">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, LGPL, and AGPL licence family, promoting free software and user freedoms.">GNU</a> licences, and promoting user freedoms.</dd>

<dt id="FSFE"><b>FSFE – Free Software Foundation Europe</b></dt>
<dd>Organisation promoting <a href="#Free_Software" title="Free Software: Software granting users freedom to use, modify, and share it, per FSF definition.">free software</a> in Europe, and maintaining the <a href="#REUSE" title="REUSE / REUSE Specification: FSFE initiative defining standardised file headers, licence text placement, and metadata for automated compliance, aligning with FAIR principles through improved accessibility and interoperability of licensing information.">REUSE specification</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.">GPL</a>, <a href="#LGPL" title="LGPL – GNU Lesser General Public License: Weak copyleft licence used mainly for libraries. It permits dynamic linking with differently licensed or proprietary software. Static linking is allowed when users receive the build information, the source code for the LGPL parts and whatever is needed to rebuild the larger work with a modified version of the library.">LGPL</a>, and <a href="#AGPL" title="AGPL – GNU Affero General Public License: Network-protective and strong copyleft licence requiring source code disclosure in case of remote use, including when the software is accessed as a service.">AGPL</a> licence family, promoting <a href="#Free_Software" title="Free Software: Software granting users freedom to use, modify, and share it, per FSF definition.">free software</a> and user freedoms.</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, 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.">derivatives</a> to use the same licence.</dd>

<dt id="GSC"><b>GSC – GÉANT Software Catalogue</b></dt>
<dd>Catalogue of GÉANT software.</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. Entries typically follow 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 redistribution conditions, requiring retention of attribution notices.">BSD</a>, or <a href="#GNU" title="GNU – “GNU’s Not Unix”: Project behind the GPL, LGPL, and AGPL licence family, promoting free software and user freedoms.">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: Component, library, or source code used by another software. Each external dependency typically carries an in-licence, and should be recorded in the dependency inventory or SBOM file.">dependencies</a> incorporated into a project, typically recorded in a <a href="#Dependency_Inventory" title="Dependency Inventory: Human-readable list of external libraries, frameworks, or tools with versions and licences, often forming the basis for an SBOM File.">dependency inventory</a> or <a href="#SBOM_File" title="SBOM File – Software Bill of Materials: Machine-readable dependency inventory listing components and their licences, often in SPDX or CycloneDX format, with semantic versioning and provenance. It should include all components, including transitive dependencies, supporting FAIR principles by improving findability and reusability of information.">SBOM</a>.</dd>

<dt id="IoT_Gap"><b>IoT Gap</b></dt>
<dd>Circumventing <a href="#OSS" title="OSS – Open Source Software / Open Source: Software under licences granting rights to use, modify, and distribute source code, including those recognised by the OSI or FSF. An organisation’s IPR Policy guides OSS use, contribution, and distribution, while an OSPO may promote adoption, establish contribution policies, ensure compliance, and guide OSS strategy.">OSS</a> rights in networked or embedded software that can be used but not modified; see <a href="#Tivoisation" title="Tivoisation: Restricting software modification on devices; prohibited by GPL 3.0; closely related to the IoT gap.">Tivoisation</a>.</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 protection granting exclusive rights to reproduce, distribute, modify, and publicly perform or display a work.">copyright</a>, <a href="#Patent" title="Patent: Legal protection granting exclusive rights to an invention, preventing others from making, using, selling, or distributing it without permission.">patents</a>, <a href="#Trademark" title="Trademark: Legally protected sign, name, logo, symbol, design, or other identifying mark distinguishing goods or services, granting the owner exclusive rights to its commercial use.">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 covering <a href="#Patent" title="Patent: Legal protection granting exclusive rights to an invention, preventing others from making, using, selling, or distributing it without permission.">patents</a>, <a href="#Copyright" title="Copyright: Legal protection granting exclusive rights to reproduce, distribute, modify, and publicly perform or display a work.">copyright</a>, and <a href="#Trademark" title="Trademark: Legally protected sign, name, logo, symbol, design, or other identifying mark distinguishing goods or services, granting the owner exclusive rights to its commercial use.">trademarks</a>. See <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>.</dd>

<dt id="IPR_Coordinator"><b>IPR Coordinator</b></dt>
<dd>Role managing <a href="#IPR" title="IPR – Intellectual Property Rights: Legal rights covering patents, copyright, and trademarks. See Sideground IPR.">intellectual property rights</a> and licence <a href="#Compliance" title="Compliance: Ensuring software use adheres to licence, patent, and security requirements, often via audits. Licence compatibility and appropriate compliance artefacts are necessary to meet licence obligations, and standards such as OpenChain can guide organisational practices.">compliance</a>, ensuring software projects follow the organisation’s <a href="#IPR_Policy" title="IPR Policy: Policy governing intellectual property rights, licence selection, and compliance.">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, documentation artefacts, or work submitted to a project, typically governed by a CLA or DCO, forming part of the project’s copyright and licensing framework. Contributors may retain moral rights, which must be respected even when the work is licensed or assigned. See Upstream Contribution.">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 covering patents, copyright, and trademarks. See Sideground IPR.">intellectual property rights</a>, licence selection, and <a href="#Compliance" title="Compliance: Ensuring software use adheres to licence, patent, and security requirements, often via audits. Licence compatibility and appropriate compliance artefacts are necessary to meet licence obligations, and standards such as OpenChain can guide organisational practices.">compliance</a>.</dd>

<dt id="ISC"><b>ISC License</b></dt>
<dd><a href="#Permissive_Licence" title="Permissive Licence: Licence allowing use, modification, and redistribution 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, PSFL).">Permissive licence</a> created by the Internet Software Consortium (now Internet Systems Consortium).</dd>

<dt id="ISO"><b>ISO – International Organisation for Standardisation</b></dt>
<dd>Organisation developing international standards.</dd>

<dt id="LGPL"><b>LGPL – GNU Lesser General Public License</b></dt>
<dd><a href="#Weak_Copyleft" title="Weak Copyleft: Copyleft with limited scope (e.g. LGPL, MPL, EPL, CDDL), usually applying to modifications of the original source code, but allowing linking with differently licensed or proprietary software.">Weak copyleft</a> licence used mainly for libraries. It permits <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 restrictive terms limiting access, modification, or redistribution, often requiring authorisation or payment when it is commercial software sold for profit. Such software is typically governed by an EULA, and may be distributed as freeware or shareware. It may also involve trademarks, and is most often closed source software distributed without source code.">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 when users receive the build information, the <a href="#Source_Code" title="Source Code: Human-readable form of software that is often compiled into binaries.">source code</a> for the LGPL parts and whatever is needed to rebuild the larger work with a modified version of the library.</dd>

<dt id="Licence"><b>Licence</b></dt>
<dd>Legal instrument granting permissions, and imposing obligations on the use, modification, or <a href="#Distribution" title="Distribution: Providing software to third parties, triggering licence obligations.">distribution</a> of software.</dd>

<dt id="Licence_Compatibility"><b>Licence Compatibility</b></dt>
<dd>Ability to combine or <a href="#Distribution" title="Distribution: Providing software to third parties, triggering licence obligations.">distribute</a> software under different licences without violating their terms. For example, <a href="#MIT" title="MIT License / X11 License: Simple permissive licence requiring attribution and notice retention.">MIT</a> components within a <a href="#GPL" title="GPL – GNU General Public License: Strong copyleft licence requiring derivatives to use the same licence.">GPL</a> project, or <a href="#Apache_License" title="Apache License: Permissive licence with patent protection, attribution requirements, and a patent retaliation clause, including a patent grant that permits licencees to use patents associated with the software.">Apache 2.0</a> code with <a href="#GPL" title="GPL – GNU General Public License: Strong copyleft licence requiring derivatives to use the same licence.">GPL</a> 3.0 as <a href="#Out_Licence" title="Out-Licence / Outbound Licence: Licence applied to distributed software, which may differ from the licences of its dependencies.">out-licence</a>, require that <a href="#GPL" title="GPL – GNU General Public License: Strong copyleft licence requiring derivatives to use the same licence.">GPL</a> obligations are met for those components as well.</dd>

<dt id="Licencee"><b>Licencee</b></dt>
<dd>Individual or organisation granted rights under a licence.</dd>

<dt id="License"><b>License</b></dt>
<dd>US spelling of licence; also verb form in both US and UK English; used in official licence names or acronyms.</dd>

<dt id="LICENSE_File"><b>LICENSE File</b></dt>
<dd>File containing the full licence text. See <a href="#COPYING_File" title="COPYING File: GNU-style file containing the full licence text, equivalent to LICENSE File.">COPYING File</a>.</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, including notice retention obligations to preserve copyright and licence notices in distributions. Compliance reviews may trigger remediation, such as correcting notices to meet licence obligations.">compliance artefacts</a>, and <a href="#Dependency" title="Dependency: Component, library, or source code used by another software. Each external dependency typically carries an in-licence, and should be recorded in the dependency inventory or SBOM file.">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 software licensing, <a href="#Compliance" title="Compliance: Ensuring software use adheres to licence, patent, and security requirements, often via audits. Licence compatibility and appropriate compliance artefacts are necessary to meet licence obligations, and standards such as OpenChain can guide organisational practices.">compliance</a>, and governance.</dd>

<dt id="Markdown"><b>Markdown</b></dt>
<dd>Lightweight text formatting syntax.</dd>

<dt id="MIT"><b>MIT License / X11 License</b></dt>
<dd>Simple <a href="#Permissive_Licence" title="Permissive Licence: Licence allowing use, modification, and redistribution 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, PSFL).">permissive licence</a> requiring <a href="#Attribution" title="Attribution: Notice required by some licences (e.g. Apache, CC BY, BSD License) to preserve credit to original authors and contributors, and to indicate modifications.">attribution</a> and <a href="#Notice_Retention" title="Notice Retention: Requirement to preserve copyright and licence notices in redistributions.">notice retention</a>.</dd>

<dt id="Moral_Rights"><b>Moral Rights</b></dt>
<dd>Personal rights of creators (distinct from economic <a href="#Copyright" title="Copyright: Legal protection granting exclusive rights to reproduce, distribute, modify, and publicly perform or display a work.">copyright</a>) to be credited (<a href="#Attribution" title="Attribution: Notice required by some licences (e.g. Apache, CC BY, BSD License) to preserve credit to original authors and contributors, and to indicate modifications.">attribution</a>) and to prevent derogatory treatment of their work; these are often non-transferable and persist even if <a href="#Copyright" title="Copyright: Legal protection granting exclusive rights to reproduce, distribute, modify, and publicly perform or display a work.">copyright</a> is transferred.</dd>

<dt id="MPL"><b>MPL – Mozilla Public License</b></dt>
<dd><a href="#Weak_Copyleft" title="Weak Copyleft: Copyleft with limited scope (e.g. LGPL, MPL, EPL, CDDL), usually applying to modifications of the original source code, but allowing linking with differently licensed or proprietary software.">Weak copyleft</a> licence permitting file-level mixing.</dd>

<dt id="Multi_Licensing"><b>Multi-Licensing</b></dt>
<dd>See <a href="#Dual_and_Multi_Licensing" title="Dual and Multi-Licensing: Distribution under multiple licences, allowing licencees to select which applies (e.g. MySQL: GPL + commercial licence, Qt: LGPL + commercial licence). The in-licence of incorporated components must be compatible with the out-licence or subsuming licence. A secondary licence is often an example of dual licensing.">Dual and Multi-Licensing</a>.</dd>

<dt id="Network_Protective"><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, 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.">source code</a> disclosure in case of <a href="#Remote_Use" title="Remote Use: Use of software over a network, potentially triggering copyleft obligations.">remote use</a> (e.g. <a href="#AGPL" title="AGPL – GNU Affero General Public License: Network-protective and strong copyleft licence requiring source code disclosure in case of remote use, including when the software is accessed as a service.">AGPL</a>).</dd>

<dt id="NOTICE_File"><b>NOTICE File</b></dt>
<dd>Contains acknowledgements, <a href="#Attribution" title="Attribution: Notice required by some licences (e.g. Apache, CC BY, BSD License) to preserve credit to original authors and contributors, and to indicate modifications.">attributions</a>, and licence-related notices.</dd>

<dt id="Notice_Retention"><b>Notice Retention</b></dt>
<dd>Requirement to preserve <a href="#Copyright" title="Copyright: Legal protection granting exclusive rights to reproduce, distribute, modify, and publicly perform or display a work.">copyright</a> and licence notices in re<a href="#Distribution" title="Distribution: Providing software to third parties, triggering licence obligations.">distributions</a>.</dd>

<dt id="Open_Core"><b>Open Core</b></dt>
<dd>A business model where the core functionality of a product is <a href="#OSS" title="OSS – Open Source Software / Open Source: Software under licences granting rights to use, modify, and distribute source code, including those recognised by the OSI or FSF. An organisation’s IPR Policy guides OSS use, contribution, and distribution, while an OSPO may promote adoption, establish contribution policies, ensure compliance, and guide OSS strategy.">OSS</a> (often under a <a href="#Permissive_Licence" title="Permissive Licence: Licence allowing use, modification, and redistribution 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, PSFL).">permissive licence</a> or <a href="#Strong_Copyleft" title="Strong Copyleft: Licensing model requiring derivatives to remain under the same terms or licence (e.g. GPL, AGPL, EUPL, CC BY-SA). SSPL is a strong copyleft source-available licence.">strong copyleft</a>), while advanced features (enterprise security, monitoring) are <a href="#Proprietary_Software" title="Proprietary Software: Software distributed under restrictive terms limiting access, modification, or redistribution, often requiring authorisation or payment when it is commercial software sold for profit. Such software is typically governed by an EULA, and may be distributed as freeware or shareware. It may also involve trademarks, and is most often closed source software distributed without source code.">proprietary software</a> or <a href="#Source_Available_Licence" title="Source-Available Licence / Source-Available Software: Licence or software with visible source code, but restrictive terms preventing OSS status (e.g. Elastic Licence, SSPL). Unlike Closed Source Software, the source code is viewable, though modification or redistribution may remain limited.">source-available software</a>.</dd>

<dt id="OpenChain"><b>OpenChain</b></dt>
<dd><a href="#ISO" title="ISO – International Organisation for Standardisation: Organisation developing international standards.">ISO</a>/IEC standard for managing <a href="#OSS" title="OSS – Open Source Software / Open Source: Software under licences granting rights to use, modify, and distribute source code, including those recognised by the OSI or FSF. An organisation’s IPR Policy guides OSS use, contribution, and distribution, while an OSPO may promote adoption, establish contribution policies, ensure compliance, and guide OSS strategy.">OSS</a> in supply chains, providing guidelines for licence <a href="#Compliance" title="Compliance: Ensuring software use adheres to licence, patent, and security requirements, often via audits. Licence compatibility and appropriate compliance artefacts are necessary to meet licence obligations, and standards such as OpenChain can guide organisational practices.">compliance</a>, defining a core curriculum for <a href="#OSS" title="OSS – Open Source Software / Open Source: Software under licences granting rights to use, modify, and distribute source code, including those recognised by the OSI or FSF. An organisation’s IPR Policy guides OSS use, contribution, and distribution, while an OSPO may promote adoption, establish contribution policies, ensure compliance, and guide OSS strategy.">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 contributors.</dd>

<dt id="OSI"><b>OSI – Open Source Initiative</b></dt>
<dd>Organisation approving <a href="#OSS" title="OSS – Open Source Software / Open Source: Software under licences granting rights to use, modify, and distribute source code, including those recognised by the OSI or FSF. An organisation’s IPR Policy guides OSS use, contribution, and distribution, while an OSPO may promote adoption, establish contribution policies, ensure compliance, and guide OSS strategy.">OSS</a> licences.</dd>

<dt id="OSPO"><b>OSPO – Open Source Program Office</b></dt>
<dd>Unit managing <a href="#OSS" title="OSS – Open Source Software / Open Source: Software under licences granting rights to use, modify, and distribute source code, including those recognised by the OSI or FSF. An organisation’s IPR Policy guides OSS use, contribution, and distribution, while an OSPO may promote adoption, establish contribution policies, ensure compliance, and guide OSS strategy.">OSS</a> strategy, <a href="#Compliance" title="Compliance: Ensuring software use adheres to licence, patent, and security requirements, often via audits. Licence compatibility and appropriate compliance artefacts are necessary to meet licence obligations, and standards such as OpenChain can guide organisational practices.">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 licence <a href="#Compliance" title="Compliance: Ensuring software use adheres to licence, patent, and security requirements, often via audits. Licence compatibility and appropriate compliance artefacts are necessary to meet licence obligations, and standards such as OpenChain can guide organisational practices.">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 / Open Source</b></dt>
<dd>Software under licences granting rights to use, modify, and <a href="#Distribution" title="Distribution: Providing software to third parties, triggering licence obligations.">distribute</a> <a href="#Source_Code" title="Source Code: Human-readable form of software that is often compiled into binaries.">source code</a>, including those recognised by the <a href="#OSI" title="OSI – Open Source Initiative: Organisation approving OSS licences.">OSI</a> or <a href="#FSF" title="FSF – Free Software Foundation: Organisation maintaining GNU licences, and promoting user freedoms.">FSF</a>. An organisation’s <a href="#IPR_Policy" title="IPR Policy: Policy governing intellectual property rights, licence selection, and compliance.">IPR Policy</a> guides OSS use, <a href="#Contribution" title="Contribution: Any source code, documentation artefacts, or work submitted to a project, typically governed by a CLA or DCO, forming part of the project’s copyright and licensing framework. Contributors may retain moral rights, which must be respected even when the work is licensed or assigned. See Upstream Contribution.">contribution</a>, and <a href="#Distribution" title="Distribution: Providing software to third parties, triggering licence obligations.">distribution</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 licence compliance, while the LT implements day-to-day SLM processes.">OSPO</a> may promote adoption, establish <a href="#Contribution" title="Contribution: Any source code, documentation artefacts, or work submitted to a project, typically governed by a CLA or DCO, forming part of the project’s copyright and licensing framework. Contributors may retain moral rights, which must be respected even when the work is licensed or assigned. See Upstream Contribution.">contribution</a> policies, ensure <a href="#Compliance" title="Compliance: Ensuring software use adheres to licence, patent, and security requirements, often via audits. Licence compatibility and appropriate compliance artefacts are necessary to meet licence obligations, and standards such as OpenChain can guide organisational practices.">compliance</a>, and guide OSS strategy.</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 obligations.">distributed</a> software, which may differ from the licences of its <a href="#Dependency" title="Dependency: Component, library, or source code used by another software. Each external dependency typically carries an in-licence, and should be recorded in the dependency inventory or SBOM file.">dependencies</a>.</dd>

<dt id="Patent"><b>Patent</b></dt>
<dd>Legal protection granting exclusive rights to an invention, preventing others from making, using, selling, or <a href="#Distribution" title="Distribution: Providing software to third parties, triggering licence obligations.">distributing</a> it without permission.</dd>

<dt id="Patent_Grant"><b>Patent Grant</b></dt>
<dd>Permission to use <a href="#Patent" title="Patent: Legal protection granting exclusive rights to an invention, preventing others from making, using, selling, or distributing it without permission.">patents</a> associated with the software and its <a href="#Contribution" title="Contribution: Any source code, documentation artefacts, or work submitted to a project, typically governed by a CLA or DCO, forming part of the project’s copyright and licensing framework. Contributors may retain moral rights, which must be respected even when the work is licensed or assigned. See Upstream Contribution.">contributions</a>, typically covering rights held by contributors and reducing legal uncertainty for users and distributors.</dd>

<dt id="Patent_Retaliation_Clause"><b>Patent Retaliation Clause</b></dt>
<dd>Licence term revoking 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 and reducing legal uncertainty for users and distributors.">patent grant</a> if the <a href="#Licencee" title="Licencee: Individual or organisation granted rights under a licence.">licencee</a> initiates a <a href="#Patent" title="Patent: Legal protection granting exclusive rights to an invention, preventing others from making, using, selling, or distributing it without permission.">patent</a> claim, 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>, and implementing <a href="#Defensive_Termination" title="Defensive Termination: Licence clause revoking rights if the licencee initiates patent litigation. See Patent Retaliation Clause.">defensive termination</a>.</dd>

<dt id="Patent_Trolling"><b>Patent Trolling</b></dt>
<dd>Asserting <a href="#Patent" title="Patent: Legal protection granting exclusive rights to an invention, preventing others from making, using, selling, or distributing it without permission.">patents</a> to obtain fees or settlements; addressed in some licences through <a href="#Patent_Retaliation_Clause" title="Patent Retaliation Clause: Licence term revoking rights and the patent grant if the licencee initiates a patent claim, deterring patent trolling, and implementing defensive termination.">patent retaliation clauses</a>.</dd>

<dt id="Permissive_Licence"><b>Permissive Licence</b></dt>
<dd>Licence allowing use, modification, and redistribution with minimal obligations, such as preserving <a href="#Copyright" title="Copyright: Legal protection granting exclusive rights to reproduce, distribute, modify, and publicly perform or display a work.">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.">derivatives</a> (e.g. <a href="#MIT" title="MIT License / X11 License: Simple permissive licence requiring attribution and notice retention.">MIT</a>, <a href="#BSD_License" title="BSD License: Berkeley Software Distribution family of permissive licences with minimal redistribution conditions, requiring retention of attribution notices.">BSD</a>, <a href="#Apache_License" title="Apache License: Permissive licence with patent protection, attribution requirements, and a patent retaliation clause, including a patent grant that permits licencees to use patents associated with the software.">Apache</a>, <a href="#ISC" title="ISC License: Permissive licence created by the Internet Software Consortium (now Internet Systems Consortium).">ISC</a>, <a href="#Artistic_License" title="Artistic License: Permissive licence originating from the Perl ecosystem; version 2 clarifies terms and has licence compatibility with GPL.">Artistic</a>, <a href="#PSFL" title="PSFL – Python Software Foundation Licence / 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>).</dd>

<dt id="Proprietary_Software"><b>Proprietary Software</b></dt>
<dd>Software <a href="#Distribution" title="Distribution: Providing software to third parties, triggering licence obligations.">distributed</a> under restrictive terms limiting access, modification, or redistribution, often requiring authorisation or payment when it is <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 can follow an Open Core model, where the base software is OSS, while additional features or services are proprietary. It may include trademarks to distinguish the software or its services.">commercial software</a> sold for profit. Such software is typically governed by 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>, and may be distributed as <a href="#Freeware" title="Freeware: Proprietary software available at no cost, but without the freedoms to modify or redistribute 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>. It may also involve <a href="#Trademark" title="Trademark: Legally protected sign, name, logo, symbol, design, or other identifying mark distinguishing goods or services, granting the owner exclusive rights to its commercial use.">trademarks</a>, and is most often <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> <a href="#Distribution" title="Distribution: Providing software to third parties, triggering licence obligations.">distributed</a> without <a href="#Source_Code" title="Source Code: Human-readable form of software that is often compiled into binaries.">source code</a>.</dd>

<dt id="PSFL"><b>PSFL – Python Software Foundation Licence / Python License</b></dt>
<dd><a href="#Permissive_Licence" title="Permissive Licence: Licence allowing use, modification, and redistribution 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, PSFL).">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 obligations.">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 protection granting exclusive rights to reproduce, distribute, modify, and publicly perform or display a work.">copyright</a>, either because it has expired or has been waived (e.g., via <a href="#CC0" title="CC0 – Creative Commons Zero: Public-domain dedication waiving copyright and related rights where legally possible.">CC0</a>). In jurisdictions where public-domain dedication is not recognised, <a href="#Permissive_Licence" title="Permissive Licence: Licence allowing use, modification, and redistribution 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, PSFL).">permissive licences</a> such as <a href="#0BSD" title="0BSD – Zero-Clause BSD: A 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: Permissive licence used in jurisdictions where public-domain dedication is not recognised.">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 <a href="#Markdown" title="Markdown: Lightweight text formatting syntax.">Markdown</a> 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), and reciprocity in derivative works.">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.">derivatives</a> or re<a href="#Distribution" title="Distribution: Providing software to third parties, triggering licence obligations.">distributed</a> versions.</dd>

<dt id="Relicensing"><b>Relicensing</b></dt>
<dd>Changing a licence of existing software, often to improve <a href="#Licence_Compatibility" title="Licence Compatibility: Ability to combine or distribute software under different licences without violating their terms. For example, MIT components within a GPL project, or Apache 2.0 code with GPL 3.0 as out-licence, require that GPL obligations are met for those components as well.">licence compatibility</a> or for commercial reasons; must comply with original licence or contributor 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, 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.">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 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: Component, library, or source code used by another software. Each external dependency typically carries an in-licence, and should be recorded in the dependency inventory or SBOM file.">dependencies</a> with <a href="#Vulnerability" title="Vulnerability: A weakness in software code that can be exploited; SCA tools are primarily used to identify known vulnerabilities (mapped to CVEs) in dependencies.">vulnerabilities</a>, replacing incompatible licences or correcting missing notices, to restore <a href="#Compliance" title="Compliance: Ensuring software use adheres to licence, patent, and security requirements, often via audits. Licence compatibility and appropriate compliance artefacts are necessary to meet licence obligations, and standards such as OpenChain can guide organisational practices.">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, potentially triggering <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), and reciprocity in derivative works.">copyleft</a> obligations.</dd>

<dt id="REUSE"><b>REUSE / REUSE Specification</b></dt>
<dd><a href="#FSFE" title="FSFE – Free Software Foundation Europe: Organisation promoting free software in Europe, and maintaining the REUSE specification.">FSFE</a> initiative defining standardised file headers, licence text placement, and metadata for automated <a href="#Compliance" title="Compliance: Ensuring software use adheres to licence, patent, and security requirements, often via audits. Licence compatibility and appropriate compliance artefacts are necessary to meet licence obligations, and standards such as OpenChain can guide organisational practices.">compliance</a>, aligning with <a href="#FAIR" title="FAIR: Findability, Accessibility, Interoperability, and Reusability principle in open science.">FAIR</a> principles through improved accessibility and interoperability of licensing information.</dd>

<dt id="SBOM_File"><b>SBOM File – Software Bill of Materials</b></dt>
<dd>Machine-readable <a href="#Dependency_Inventory" title="Dependency Inventory: Human-readable list of external libraries, frameworks, or tools with versions and licences, often forming the basis for an SBOM File.">dependency inventory</a> listing components and their licences, 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, BSD-3-Clause); widely used in SBOMs and REUSE headers.">SPDX</a> or CycloneDX format, with <a href="#Semantic_Versioning" title="Semantic Versioning: Versioning scheme using MAJOR.MINOR.PATCH notation (e.g. 1.2.3).">semantic versioning</a> and provenance. It should include all components, including <a href="#Transitive_Dependency" title="Transitive Dependency: Dependency required by another dependency rather than by the project directly. Tracking transitive dependencies is essential for SCA, SBOM accuracy and licence compliance.">transitive dependencies</a>, supporting <a href="#FAIR" title="FAIR: Findability, Accessibility, Interoperability, and Reusability principle in open science.">FAIR</a> principles by improving 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: Component, library, or source code used by another software. Each external dependency typically carries an in-licence, and should be recorded in the dependency inventory or SBOM file.">dependencies</a>, licences, and <a href="#Vulnerability" title="Vulnerability: A weakness in software code that can be exploited; SCA tools are primarily used to identify known vulnerabilities (mapped to CVEs) in dependencies.">vulnerabilities</a>, to support <a href="#Compliance" title="Compliance: Ensuring software use adheres to licence, patent, and security requirements, often via audits. Licence compatibility and appropriate compliance artefacts are necessary to meet licence obligations, and standards such as OpenChain can guide organisational practices.">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>, often integrated into <a href="#CI" title="CI – Continuous Integration: Automated build and test process for software changes; can integrate 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>. SCA tools identify direct and <a href="#Transitive_Dependency" title="Transitive Dependency: Dependency required by another dependency rather than by the project directly. Tracking transitive dependencies is essential for SCA, SBOM accuracy and licence compliance.">transitive dependencies</a>, and commonly report known <a href="#Vulnerability" title="Vulnerability: A weakness in software code that can be exploited; SCA tools are primarily used to identify known vulnerabilities (mapped to CVEs) in dependencies.">vulnerabilities</a> using <a href="#CVE" title="CVE – Common Vulnerabilities and Exposures: A system for referencing specific security vulnerabilities. SCA tools map dependencies to CVE lists to assess risk.">CVE</a> identifiers.</dd>

<dt id="Secondary_Licence"><b>Secondary Licence</b></dt>
<dd>Alternative licence permitted by a primary licence for <a href="#Licence_Compatibility" title="Licence Compatibility: Ability to combine or distribute software under different licences without violating their terms. For example, MIT components within a GPL project, or Apache 2.0 code with GPL 3.0 as out-licence, require that GPL obligations are met for those components as well.">compatibility</a>.</dd>

<dt id="Semantic_Versioning"><b>Semantic Versioning</b></dt>
<dd>Versioning scheme using MAJOR.MINOR.PATCH notation (e.g. 1.2.3).</dd>

<dt id="Shareware"><b>Shareware</b></dt>
<dd><a href="#Proprietary_Software" title="Proprietary Software: Software distributed under restrictive terms limiting access, modification, or redistribution, often requiring authorisation or payment when it is commercial software sold for profit. Such software is typically governed by an EULA, and may be distributed as freeware or shareware. It may also involve trademarks, and is most often closed source software distributed without source code.">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 / Open Source: Software under licences granting rights to use, modify, and distribute source code, including those recognised by the OSI or FSF. An organisation’s IPR Policy guides OSS use, contribution, and distribution, while an OSPO may promote adoption, establish contribution policies, ensure compliance, and guide OSS strategy.">OSS</a>.</dd>

<dt id="Sideground_IPR"><b>Sideground IPR</b></dt>
<dd><a href="#IPR" title="IPR – Intellectual Property Rights: Legal rights covering patents, copyright, and trademarks. See Sideground IPR.">Intellectual property rights</a> of third-party <a href="#Dependency" title="Dependency: Component, library, or source code used by another software. Each external dependency typically carries an in-licence, and should be recorded in the dependency inventory or SBOM file.">dependencies</a>, or other copyrighted work incorporated into a project, requiring proper handling to ensure licence <a href="#Compliance" title="Compliance: Ensuring software use adheres to licence, patent, and security requirements, often via audits. Licence compatibility and appropriate compliance artefacts are necessary to meet licence obligations, and standards such as OpenChain can guide organisational practices.">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.</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.">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, including notice retention obligations to preserve copyright and licence notices in distributions. Compliance reviews may trigger remediation, such as correcting notices to meet licence obligations.">compliance artefacts</a>, and using <a href="#SLA" title="SLA – Software Licence Analysis: Assessment of licensing in software projects.">SLA</a> to assess <a href="#Compliance" title="Compliance: Ensuring software use adheres to licence, patent, and security requirements, often via audits. Licence compatibility and appropriate compliance artefacts are necessary to meet licence obligations, and standards such as OpenChain can guide organisational practices.">compliance</a> and risks.</dd>

<dt id="Software_Licence"><b>Software Licence</b></dt>
<dd>See <a href="#Licence" title="Licence: Legal instrument granting permissions, and imposing obligations on the use, modification, or distribution of software.">Licence</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.">binaries</a>.</dd>

<dt id="Source_Available_Licence"><b>Source-Available Licence / Source-Available Software</b></dt>
<dd>Licence or software with visible <a href="#Source_Code" title="Source Code: Human-readable form of software that is often compiled into binaries.">source code</a>, but restrictive terms preventing <a href="#OSS" title="OSS – Open Source Software / Open Source: Software under licences granting rights to use, modify, and distribute source code, including those recognised by the OSI or FSF. An organisation’s IPR Policy guides OSS use, contribution, and distribution, while an OSPO may promote adoption, establish contribution policies, ensure compliance, and guide OSS strategy.">OSS</a> status (e.g. <a href="#Elastic_Licence" title="Elastic Licence: Source-available licence prohibiting offering the software as a managed service, and bypassing key protections; this usage restriction makes it an exemplary fauxpen.">Elastic Licence</a>, <a href="#SSPL" title="SSPL – Server Side Public Licence: 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 <a href="#Source_Code" title="Source Code: Human-readable form of software that is often compiled into binaries.">source code</a> is viewable, though modification or redistribution may remain limited.</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. <a href="#MIT" title="MIT License / X11 License: Simple permissive licence requiring attribution and notice retention.">MIT</a>, <a href="#Apache_License" title="Apache License: Permissive licence with patent protection, attribution requirements, and a patent retaliation clause, including a patent grant that permits licencees to use patents associated with the software.">Apache</a>-2.0, <a href="#BSD_License" title="BSD License: Berkeley Software Distribution family of permissive licences with minimal redistribution conditions, requiring retention of attribution notices.">BSD</a>-3-Clause); widely used in <a href="#SBOM_File" title="SBOM File – Software Bill of Materials: Machine-readable dependency inventory listing components and their licences, often in SPDX or CycloneDX format, with semantic versioning and provenance. It should include all components, including transitive dependencies, supporting FAIR principles by improving findability and reusability of information.">SBOMs</a> and <a href="#REUSE" title="REUSE / REUSE Specification: FSFE initiative defining standardised file headers, licence text placement, and metadata for automated compliance, aligning with FAIR principles through improved accessibility and interoperability of licensing information.">REUSE</a> headers.</dd>

<dt id="SSPL"><b>SSPL – Server Side Public Licence</b></dt>
<dd><a href="#Network_Protective" title="Network-Protective Licence: Strong copyleft licence requiring source code disclosure in case of remote use (e.g. AGPL).">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, CC BY-SA). SSPL is a strong copyleft source-available licence.">strong copyleft</a>, and <a href="#Source_Available_Licence" title="Source-Available Licence / Source-Available Software: Licence or software with visible source code, but restrictive terms preventing OSS status (e.g. Elastic Licence, SSPL). Unlike Closed Source Software, the source code is viewable, though modification or redistribution may remain limited.">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.">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, 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.">binary</a>. For <a href="#Weak_Copyleft" title="Weak Copyleft: Copyleft with limited scope (e.g. LGPL, MPL, EPL, CDDL), usually applying to modifications of the original source code, but allowing 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 used mainly for libraries. It permits dynamic linking with differently licensed or proprietary software. Static linking is allowed when users receive the build information, the source code for the LGPL parts and whatever is needed to rebuild the larger 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.">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.">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.">GPL</a>, <a href="#AGPL" title="AGPL – GNU Affero General Public License: Network-protective and strong copyleft licence requiring source code disclosure in case of remote use, including when the software is accessed as a service.">AGPL</a>, <a href="#EUPL" title="EUPL – European Union Public Licence: EU-approved copyleft licence compatible with various OSS licences.">EUPL</a>, <a href="#CC_BY_SA" title="CC BY-SA – Creative Commons Attribution-ShareAlike: Licence requiring attribution, with derivatives licensed under identical terms; copyleft equivalent.">CC BY-SA</a>). <a href="#SSPL" title="SSPL – Server Side Public Licence: 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_Licence" title="Source-Available Licence / Source-Available Software: Licence or software with visible source code, but restrictive terms preventing OSS status (e.g. Elastic Licence, SSPL). Unlike Closed Source Software, the source code is viewable, though modification or redistribution may remain limited.">source-available licence</a>.</dd>

<dt id="Sublicensing"><b>Sublicensing</b></dt>
<dd>Allowing a <a href="#Licencee" title="Licencee: Individual or organisation granted rights under a licence.">licencee</a> to pass on certain rights to a third party without transferring <a href="#Copyright" title="Copyright: Legal protection granting exclusive rights to reproduce, distribute, modify, and publicly perform or display a work.">copyright</a> or changing licence terms; <a href="#Permissive_Licence" title="Permissive Licence: Licence allowing use, modification, and redistribution 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, PSFL).">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), and reciprocity in derivative works.">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.">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: Component, library, or source code used by another software. Each external dependency typically carries an in-licence, and should be recorded in the dependency inventory or SBOM file.">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 licences of its dependencies.">out-licence</a> but not necessarily implying <a href="#Distribution" title="Distribution: Providing software to third parties, triggering licence obligations.">distribution</a>. “Subsuming into” means incorporating one work into a larger one so it becomes subject to that subsuming licence.</dd>

<dt id="Tivoisation"><b>Tivoisation</b></dt>
<dd>Restricting software modification on devices; prohibited by <a href="#GPL" title="GPL – GNU General Public License: Strong copyleft licence requiring derivatives to use the same licence.">GPL</a> 3.0; closely related to the <a href="#IoT_Gap" title="IoT Gap: Circumventing OSS rights in networked or embedded software that can be used but not modified; see Tivoisation.">IoT gap</a>.</dd>

<dt id="Trademark"><b>Trademark</b></dt>
<dd>Legally protected sign, name, logo, symbol, design, or other identifying mark distinguishing goods or services, granting the owner exclusive rights to its commercial use.</dd>

<dt id="Transitive_Dependency"><b>Transitive Dependency</b></dt>
<dd><a href="#Dependency" title="Dependency: Component, library, or source code used by another software. Each external dependency typically carries an in-licence, and should be recorded in the dependency inventory or SBOM file.">Dependency</a> required by another dependency rather than by the project directly. Tracking transitive dependencies is essential for <a href="#SCA" title="SCA – Software Composition Analysis: Automated detection of dependencies, licences, and vulnerabilities, to support compliance, risk assessment, and remediation, often integrated into CI or CI/CD. SCA tools identify direct and transitive dependencies, and commonly report known vulnerabilities using CVE identifiers.">SCA</a>, <a href="#SBOM_File" title="SBOM File – Software Bill of Materials: Machine-readable dependency inventory listing components and their licences, often in SPDX or CycloneDX format, with semantic versioning and provenance. It should include all components, including transitive dependencies, supporting FAIR principles by improving findability and reusability of information.">SBOM</a> accuracy and licence <a href="#Compliance" title="Compliance: Ensuring software use adheres to licence, patent, and security requirements, often via audits. Licence compatibility and appropriate compliance artefacts are necessary to meet licence obligations, and standards such as OpenChain can guide organisational practices.">compliance</a>.</dd>

<dt id="Unlicense"><b>Unlicense</b></dt>
<dd><a href="#Permissive_Licence" title="Permissive Licence: Licence allowing use, modification, and redistribution 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, PSFL).">Permissive licence</a> used in jurisdictions where <a href="#Public_Domain" title="Public Domain: Works not protected by copyright, either because it has expired or has been waived (e.g., via CC0). In jurisdictions where public-domain dedication is not recognised, permissive licences such as 0BSD, Unlicense, or MIT-0 can be used.">public-domain</a> dedication is not recognised.</dd>

<dt id="Upstream_Contribution"><b>Upstream Contribution</b></dt>
<dd>Improvement submitted to the original software or project.</dd>

<dt id="Upstream_Software"><b>Upstream Software</b></dt>
<dd>Original software from which other software is derived. A <a href="#Downstream" title="Downstream: Recipient project, organisation, or user that uses or distributes upstream software.">downstream</a> project or user receives and builds upon it, potentially triggering licence obligations and <a href="#Compliance" title="Compliance: Ensuring software use adheres to licence, patent, and security requirements, often via audits. Licence compatibility and appropriate compliance artefacts are necessary to meet licence obligations, and standards such as OpenChain can guide organisational practices.">compliance</a> requirements.</dd>

<dt id="Usage_Restriction"><b>Usage Restriction</b></dt>
<dd>Licence term limiting certain uses of the software, including <a href="#Remote_Use" title="Remote Use: Use of software over a network, potentially triggering copyleft obligations.">remote use</a>, <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 can follow an Open Core model, where the base software is OSS, while additional features or services are proprietary. It may include trademarks to distinguish the software or its services.">commercial</a>, military, surveillance, or other applications.</dd>

<dt id="Vulnerability"><b>Vulnerability</b></dt>
<dd>A weakness in software code that can be exploited; <a href="#SCA" title="SCA – Software Composition Analysis: Automated detection of dependencies, licences, and vulnerabilities, to support compliance, risk assessment, and remediation, often integrated into CI or CI/CD. SCA tools identify direct and transitive dependencies, and commonly report known vulnerabilities using CVE identifiers.">SCA</a> tools are primarily used to identify known vulnerabilities (mapped to <a href="#CVE" title="CVE – Common Vulnerabilities and Exposures: A system for referencing specific security vulnerabilities. SCA tools map dependencies to CVE lists to assess risk.">CVEs</a>) in <a href="#Dependency" title="Dependency: Component, library, or source code used by another software. Each external dependency typically carries an in-licence, and should be recorded in the dependency inventory or SBOM file.">dependencies</a>.</dd>

<dt id="Warranty_Disclaimer"><b>Warranty Disclaimer</b></dt>
<dd>Statement denying liability for damages.</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), and reciprocity in derivative works.">Copyleft</a> with limited scope (e.g. <a href="#LGPL" title="LGPL – GNU Lesser General Public License: Weak copyleft licence used mainly for libraries. It permits dynamic linking with differently licensed or proprietary software. Static linking is allowed when users receive the build information, the source code for the LGPL parts and whatever is needed to rebuild the larger 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.">MPL</a>, <a href="#EPL" title="EPL – Eclipse Public License: Weak copyleft file-scoped licence commonly used in the Java ecosystem.">EPL</a>, <a href="#CDDL" title="CDDL – Common Development and Distribution License: Weak copyleft licence, mainly used for Java projects.">CDDL</a>), usually applying to modifications of the original <a href="#Source_Code" title="Source Code: Human-readable form of software that is often compiled into binaries.">source code</a>, but allowing linking with differently licensed or <a href="#Proprietary_Software" title="Proprietary Software: Software distributed under restrictive terms limiting access, modification, or redistribution, often requiring authorisation or payment when it is commercial software sold for profit. Such software is typically governed by an EULA, and may be distributed as freeware or shareware. It may also involve trademarks, and is most often closed source software distributed without source code.">proprietary software</a>.</dd>
</dl>