What is an SPDX identifier and where would you use it?
SPDX (Software Package Data Exchange) identifiers are standardised short strings for license identification. Examples:
MIT — the MIT License
Apache-2.0 — Apache License 2.0
GPL-3.0-only — GNU GPL v3 only (not later versions)
GPL-3.0-or-later — GPL v3 or any later version
They appear in: SPDX file headers (SPDX-License-Identifier: MIT), package.json "license" fields, SBOM (Software Bill of Materials) documents, and REUSE-compliant projects.
2 / 22
A source file contains the header: SPDX-License-Identifier: Apache-2.0. What does this mean?
The SPDX-License-Identifier tag in a file header identifies the license for that specific file. In multi-license projects (e.g., core code under GPL-3.0, documentation under CC-BY-4.0, configuration files under MIT), each file carries its own SPDX tag. This is the basis of the REUSE specification — machine-readable, per-file license declarations. The tag does not imply anything about the rest of the repository.
3 / 22
Which SPDX expression correctly represents code that can be used under either the MIT License or the Apache-2.0 License (user's choice)?
"MIT OR Apache-2.0" is correct. SPDX compound license expressions use:
OR — licensee can choose either license (common for dual-licensing: "take it under MIT or Apache, your choice")
AND — both licenses apply simultaneously (rare; used when a file combines components under different licenses that must all be respected)
WITH — a license with a specific exception added
The Rust ecosystem uses "MIT OR Apache-2.0" widely. "MIT + Apache-2.0" and "MIT / Apache-2.0" are not valid SPDX syntax.
4 / 22
What is the purpose of the REUSE specification in relation to SPDX identifiers?
REUSE (reuse.software) defines a practical process for making copyright and licensing information machine-readable. The spec requires:
SPDX-License-Identifier tag in every source file (or in a .license sidecar file)
SPDX-FileCopyrightText tag with the copyright statement
License text files stored in a LICENSES/ directory at the project root, named by SPDX identifier (e.g., LICENSES/MIT.txt)
Projects can be checked with the reuse lint tool. This matters for SBOM generation, open-source compliance audits, and contributing to projects that require REUSE compliance.
5 / 22
A package.json contains "license": "GPL-3.0-only". How does this differ from "GPL-3.0-or-later"?
The difference matters for future GPL versions.
GPL-3.0-only — the code is available under GPL version 3 only. If GPL v4 is released, this code cannot automatically be upgraded to v4 without explicit permission from the copyright holder.
GPL-3.0-or-later — the code is available under GPL v3 or any later version the FSF publishes. Recipients can choose to accept the terms of a later GPL version.
The old notation "GPL-3.0+" is equivalent to "GPL-3.0-or-later" (SPDX deprecated the "+" form). When in doubt about which to use: "GPL-3.0-or-later" gives more flexibility to downstream users; "GPL-3.0-only" gives copyright holders more control.
6 / 22
Liam from the security team just commented on your pull request: 'I'm seeing a lot of SPDX-License-Identifier: MIT tags. While MIT is fine, are you sure we're consistently applying it across all our dependencies? We need to ensure proper attribution.' What should you do?
The core purpose of SPDX identifiers is to provide unambiguous licensing information. While MIT is a valid license, consistently applying the *most specific* identifier (BSD-3-Clause in this case) demonstrates best practice and reduces ambiguity for legal review. Simply changing all tags without understanding the underlying licenses could be misleading; responding to Liam shows you're engaged with the issue.
7 / 22
You are working on a new microservice and need to document its dependencies. You've analyzed them using an automated tool that generates a JSON response. The response includes the following snippet:
```json
{
"dependencies": [
{"name": "lodash", "version": "4.17.21", "license": "MIT", "spdx_identifier": "License-Distinction: MIT"}
]
}
```
What does the `spdx_identifier` field in this response indicate?
The `spdx_identifier` field is critical for interoperability and compliance. It provides the actual SPDX expression (`License-Distinction: MIT`) that can be used to accurately represent the license terms of the dependency, enabling consistent tracking and reporting across different tools and systems. Using just a license name like 'MIT' isn't granular enough.
8 / 22
During a standup meeting, Sarah asks: 'How are we handling SPDX identifiers in the new API contract?'. Which of the following is the MOST appropriate response?
The most effective response demonstrates an understanding of best practices. While Apache-2.0 *can* be a good starting point, consistently applying the correct SPDX expression – in this case, using the `License-Distinction: MIT` - is paramount for accurate tracking and legal compliance. Simply stating 'it's simpler' or focusing solely on functionality ignores critical licensing requirements.
9 / 22
You're working on a project that uses several open-source libraries. You've identified the SPDX expressions for each dependency and are preparing a report. What is the primary benefit of using REUSE specifications alongside SPDX identifiers?
The REUSE specification enhances the value of SPDX identifiers by providing a structured way to represent and relate licensing terms. It allows for more nuanced descriptions beyond just the identifier itself, enabling better understanding of how licenses interact within a complex dependency tree – this is crucial for accurate compliance assessment.
10 / 22
Reviewer Comment: 'I noticed a few projects using SPDX-License-Identifier: BSD-3-Clause. While BSD is permissive, are we documenting the specific variations and ensuring consistency across the codebase? It's crucial for legal compliance and transparency.' Which of the following best explains the reviewer's concern?
The reviewer's concern stems from the fact that 'BSD' isn't a single license; it encompasses several related licenses (e.g., BSD-2-Clause, BSD-3-Clause). Each variation has slightly different terms and conditions, so consistent tracking is vital to avoid potential licensing disputes. The options incorrectly assume incompatibility or suggest a restrictive alternative when the core issue is about documentation and consistency.
11 / 22
Slack Message from Alex: 'Hey team, just ran some automated checks on our dependencies. I'm seeing a lot of projects using SPDX-License-Identifier: MIT. Is this the standard we should be aiming for? Should we be documenting *why* we chose MIT licenses in our dependency declarations?' What is Alex's primary question?
Alex isn't advocating for a license change; he's raising a crucial point about documentation. The SPDX-License-Identifier: MIT tag simply indicates the license type without providing context – why it was chosen or any specific considerations related to the project. He wants to understand the rationale behind using MIT licenses and ensure it's consistent with best practices.
12 / 22
Reviewer Comment: 'I'm seeing a mixed bag of SPDX identifiers here – some are `MIT`, others are `Apache-2.0`. While both are permissive, it's important to maintain consistency for our legal team. Can you clarify which identifier you intended to use in this particular file and ensure future files follow the same standard?' Which of the following actions should you take FIRST?
The core issue isn't just about the licenses themselves (both MIT and Apache are permissive). The reviewer is highlighting the importance of *consistency* for legal compliance. Changing files unilaterally without understanding intent is problematic. Discussing with the reviewer allows you to determine the correct application and establish a documented standard, preventing future issues. Option A is incorrect because ignoring inconsistencies isn't a solution; options C & D are premature actions before clarifying requirements.
13 / 22
Slack Message from David: 'Hey team, I've been looking at the SPDX identifiers used in our dependencies and noticed a lot of `LGPL-2.0` licenses. Are we aware of the implications of using LGPL? It's a copyleft license with more restrictions than MIT or Apache.' Which of the following best describes David's concern?
David's message focuses on the *obligations* of the LGPL-2.0 license. While it's true LGPL has more restrictions than MIT or Apache, his primary concern is understanding those obligations – particularly regarding derivative works. The correct answer reflects this focus on compliance and appropriate usage, not just a preference for licenses with fewer restrictions.
14 / 22
Reviewer Comment: 'I'm seeing a lot of SPDX-License-Identifier: MIT tags across our projects. While MIT is generally considered permissive, it's important to understand that different variations exist within the MIT license. Could you provide details on which specific MIT variant we are using and ensure consistent application throughout our codebase for improved traceability?', What does this comment primarily highlight?
The reviewer is not criticizing the MIT license directly but focusing on the lack of detail regarding *which* specific MIT variant is being used. Different variations exist (e.g., some include patent grants), and consistent documentation is crucial for legal compliance and risk management. Option A is incorrect because it advocates for rigid adherence without considering nuance; option C is irrelevant to the license itself, and option D is an extreme overreaction.
15 / 22
PR Description: 'Updating this component's dependencies. We've updated the package.json and added SPDX identifiers for all new and existing dependencies. Specifically, we've standardized on `Apache-2.0` across the board to simplify licensing management. Please review and approve.' Considering the provided information, what is a key reason for standardizing on `Apache-2.0`?
The PR description explicitly states the intention is to 'simplify licensing management.' `Apache-2.0` is a permissive license, meaning it offers greater freedom for users of the software. Options A and D are generally true but not the *primary* reason given; option B is incorrect because Apache-2.0 is one of the *most* permissive licenses.
16 / 22
Standup Update from Emily: 'I've been working on mapping out our dependencies and their associated SPDX identifiers. I'm using a tool to automatically generate this information, which is great for consistency. However, the output includes some ambiguous expressions – like `BSD-Clause` – and I need guidance on how to handle these.' What does Emily primarily require assistance with?
Emily is facing an ambiguous output from her automated tool. The question focuses on understanding and resolving those ambiguities, particularly with `BSD-Clause`, which represents a specific variation within the BSD license family. Options A and D are about the tool itself; option C is about manual work.
17 / 22
API Response Snippet: { "dependency": "lodash", "license": "MIT", "spdx_identifier": "BSD-3-Clause" } What information does this API response primarily convey?
This API response provides a concise summary: it links the dependency (`lodash`) to its license (`MIT`) and its corresponding SPDX identifier (`BSD-3-Clause`). Option A provides version information; option C is a correct description of the data provided but not the *primary* focus of the response, and option B is an overstatement about the MIT license's terms.
18 / 22
During a code review, Mark highlights the following comment on your PR: 'I noticed several dependencies using `SPDX-License-Identifier: MIT`. While MIT is common, are you documenting *why* you chose this identifier for each dependency – particularly considering some have more restrictive licenses? This helps ensure clarity and avoids potential legal issues later.', Which of the following best addresses Mark's concern?
A. Simply change all `MIT` identifiers to `Apache-2.0` for consistency.
B. Confirm that each dependency's license actually *is* MIT, as indicated in its documentation.
C. Document the rationale behind choosing `MIT` for each dependency, acknowledging the permissive nature of the license and any potential conflicts with other licenses.
D. Ignore the comment; Mark is overthinking the SPDX identifiers.
The correct answer focuses on documenting the *reasoning* behind the choice of `MIT`. This addresses Mark's concern about clarity and potential legal issues. Options A and D are incorrect because they provide simplistic or dismissive solutions. Option B is partially correct but misses the core point – it only checks if the identifier is accurate, not why it was chosen.
19 / 22
Sarah in the legal team sends you a Slack message: 'I'm seeing a lot of inconsistent use of SPDX identifiers across our projects. Specifically, some are using `SPDX-License-Identifier: BSD-3-Clause`, while others are using `BSD-2-Clause`. Can you explain the subtle differences between these and ensure we're using them consistently to minimize ambiguity?' What is Sarah primarily asking for?
A. A complete audit of all our projects' dependencies.
b. Confirmation that all dependencies use only permissive licenses.
C. An explanation of the nuances in the BSD license family and guidance on selecting the appropriate identifier based on the specific license terms.
D. A standardized set of SPDX identifiers to be used across all projects, regardless of license details.
Sarah's message highlights the importance of understanding the subtle differences between closely related SPDX identifiers (BSD-3-Clause vs BSD-2-Clause). The correct answer requires an explanation of these nuances. Options A and B focus on broader issues; option D suggests a rigid, potentially incorrect approach.
20 / 22
You're reviewing a PR that includes the following snippet:
```json
{
"dependency": "lodash",
"license": "MIT",
"spdx_identifier": "BSD-3-Clause"
}
```
Which of the following statements BEST describes what this JSON response is intended to convey?
A. The dependency's license is exclusively MIT, despite the `BSD-3-Clause` identifier.
B. The dependency's license is a combination of both MIT and BSD-3-Clause licenses.
C. The tool has incorrectly identified the license; `lodash` actually uses the MIT license.
D. The response provides a single, authoritative SPDX identifier for the dependency, regardless of the actual license details.
This JSON response is meant to represent the *actual* license information associated with the dependency, even if it's not perfectly aligned with the `spdx_identifier`. Option A is incorrect because it misinterprets how SPDX identifiers work. Options C and D are also inaccurate in their descriptions of the data.
21 / 22
During a standup meeting, David asks: 'We're adding SPDX identifiers to our new microservice. What's the best way to ensure we don't accidentally misrepresent the licenses of our dependencies?' Which of the following is the MOST crucial step?
A. Simply assigning the most common SPDX identifier (e.g., `MIT`) to each dependency.
B. Manually reviewing the license documentation for *every* dependency before assigning an identifier.
C. Using a consistent naming convention for all identifiers, regardless of the actual license terms.
D. Relying solely on automated tools to generate SPDX identifiers automatically.
The most crucial step is manual review of the license documentation. This ensures accuracy and prevents misrepresentation. Options A and C are dangerous because they prioritize convenience over correctness. Automated tools (Option D) can help, but should always be validated by a human.
22 / 22
You're preparing a report on your project's open-source dependencies and are considering using REUSE specifications. What is the primary advantage of incorporating REUSE specifications into your SPDX reporting?
A. REUSE specifications automatically generate accurate license compliance reports.
B. REUSE specifications provide a standardized way to represent multiple licenses that apply to a single dependency, simplifying tracking and analysis.
C. REUSE specifications are solely for legal teams to ensure complete license coverage.
D. REUSE specifications replace the need to manually identify and document all dependencies.
REUSE specifications address the common scenario where a single dependency might have multiple licenses associated with it. This provides a structured way to represent this complexity, making tracking and analysis much easier. Option A is incorrect as REUSE doesn't automate compliance; options C and D are misleading.
What will I learn from the "SPDX Identifiers | Coders Lingo" exercise?Is this exercise free to use?
Yes. Every exercise on CoderSlingo, including this one, is free to use with no account, sign-up, or paywall required.
How many questions are in this exercise?
This set contains 22 multiple-choice questions, each with a detailed explanation shown after you answer.
Do I need to create an account to track my progress?
No account is required. Your progress bar and score reset each time you reload the page, but you can retry the exercise as many times as you like.
Who is this Software Licensing exercise for?
This exercise is built for IT professionals and non-native English speakers who need to read, write, and discuss software licensing topics confidently at work.
What happens if I answer a question incorrectly?
You will see the correct answer highlighted along with a detailed explanation of why it is correct -- so every wrong answer becomes a learning moment, not just a lost point.
Can I retry this exercise?
Yes -- click "Try again" on the results screen at any time to reset your score and go through all the questions again.
How long does this exercise take to complete?
Most learners finish all 22 questions in under 10 minutes, since each question is answered by clicking a single option.
Where can I find more Software Licensing exercises?
See the full Software Licensing exercises hub for more vocabulary drills on this topic.
Is this exercise mobile-friendly?
Yes -- the exercise works on any device with a modern browser, including phones and tablets, with no app download required.