Open Source Licence Communication — MIT, Apache, GPL, CLA Vocabulary
Learn vocabulary for open source licence communication: MIT, Apache 2.0, GPL, CLA (Contributor Licence Agreement), and how to discuss licensing correctly.
0 / 13 completed
1 / 13
What is the key difference between the MIT licence and the Apache 2.0 licence in practical communication?
Both MIT and Apache 2.0 are permissive (allow commercial use, modification, redistribution). The critical Apache 2.0 addition: an express patent licence grant from contributors, and a patent retaliation clause (if you sue the project for patent infringement, your patent licence terminates). This makes Apache 2.0 preferred by large organisations over MIT.
2 / 13
What does 'copyleft' mean in open source licence vocabulary?
Copyleft (a wordplay on 'copyright') — coined by Richard Stallman — means that if you distribute a modified version of copyleft-licensed software, you must release your modifications under the same licence. GPL (strong copyleft), LGPL (weak copyleft — linking exception), MPL (file-level copyleft). This is sometimes called 'viral' by critics.
3 / 13
What is a CLA (Contributor Licence Agreement) and why do some projects require it?
CLAs are controversial: they give the project owner (e.g., a company) more flexibility — including relicensing to a proprietary licence — which critics see as asymmetric. Alternatives: DCO (Developer Certificate of Origin, used by Linux) — a lighter-weight per-commit sign-off. Projects like Apache use ICLAs (Individual) and CCLAs (Corporate). Many community projects avoid CLAs to lower the contribution barrier.
4 / 13
How would you correctly use the phrase 'this project is licensed under' in a README?
Best practice: use the SPDX licence identifier (MIT, Apache-2.0, GPL-3.0-only, GPL-3.0-or-later, LGPL-2.1-only) in the README badge and text. The LICENCE file in the repo root should contain the full licence text. SPDX identifiers are machine-readable and used by dependency scanners, GitHub, FOSSA, and other licence compliance tools.
5 / 13
What is 'licence compatibility' in open source vocabulary and why does it matter?
Licence compatibility is critical when combining libraries: you cannot distribute a single binary/package that combines GPL-2.0-only and Apache-2.0 code (incompatible). GPL-3.0 + Apache-2.0 is compatible (you can combine, the result is GPL-3.0). LGPL allows linking from proprietary code. Always check the FSF compatibility matrix or tools like FOSSA/TLDR Legal before bundling dependencies.
6 / 13
Sarah from Legal just sent you a Slack message: 'We're seeing increasing requests for source code contributions to ProjectPhoenix. To ensure we maintain compliance with open-source licensing, could you add a clause to the PR description stating that all derived works must be licensed under the Apache 2.0?' What is Sarah primarily concerned about?
Sarah's message highlights concerns about copyright infringement. The Apache 2.0 licence is a permissive one, allowing for commercial usage and derivative works – this is the key element she's trying to enforce through explicit communication in the PR description. Options B, C, and D represent secondary considerations regarding contributor information or audit trails, not the core licensing issue.
7 / 13
David is reviewing your pull request for LibSpark. He comments: 'I appreciate the improvements to the data processing module, but I'm unsure about the licensing implications of incorporating this code into a commercial product. Could you clarify which license applies?' What does David's comment most accurately represent?
David is raising the crucial point of 'copyleft.' Licenses like GPL (GNU General Public License) are *copyleft*, meaning that any derivative works must also be licensed under the same terms. The MIT and Apache licenses are permissive – they don't impose this requirement. Option A is incorrect as MIT has no restrictions; option B is a misunderstanding of copyleft, while option D is asking for legal advice, not clarifying the license itself.
8 / 13
Mark, the project lead for OpenDataStream, asks you to update the README.md file with the following statement: 'This software is licensed under the Apache License, Version 2.0.' What does this statement *primarily* communicate?
The statement 'licensed under' establishes the terms of use for the software. While derivative works *do* need to be compatible with the Apache 2.0 license (option 3), the primary communication is acknowledging the original authors and their rights – a standard practice in open-source licensing. Options A and D are incorrect; option B is a detail of attribution, not the core definition of the license.
9 / 13
Alex from the CoreTeam Slack channel asks: 'Hey, I'm using your library, AwesomeUtils. Can you tell me what license it's under?' You should respond with:
The MIT and Apache licenses are commonly used and fairly straightforward. A key distinction is that while both allow commercial use, the Apache 2.0 License requires attribution to the original authors. Responding with 'Apache 2.0' demonstrates understanding of a core open-source license difference. Option A oversimplifies; option B suggests unnecessary legal complexity; and option D indicates an unresolved situation.
10 / 13
During a standup meeting, Ben asks: 'I've been working on integrating the new data pipeline. How do we ensure we're complying with open source licenses when using these components?' Which of the following is the MOST appropriate response to convey the importance of license awareness?
Ben highlights a critical area: dependency management. The core issue with open-source licenses lies in 'copyleft' requirements – where using the code necessitates making derivative works also open source. This response correctly identifies the need for proactive license tracking and understanding of these provisions. Options A is dangerously dismissive; option B accurately explains the core concern; and option C is factually incorrect.
11 / 13
You're writing a pull request description for your contribution to ProjectFlow. You want to clearly state the license. Which of the following sentences is the *most* suitable?
Clearly stating the license at the beginning of the PR description is best practice. The provided option explicitly communicates the license terms – a crucial element in ensuring transparency and compliance. Options B and C are vague or shift responsibility; option D suggests a lack of clarity.
12 / 13
Chloe, the project manager, emails you: 'Regarding the new widget library, we've received a CLA from StellarTech. What is a CLA and why are they relevant to our project?'
The CLA (Contributor Licence Agreement) fundamentally changes the licensing terms. It mandates that if you incorporate StellarTech's code and derive value from it, you must release your own derivative work under an open-source license – typically GPL. This is a key difference from permissive licenses like MIT or Apache 2.0.
13 / 13
You are reviewing a code review comment on a PR for the DataMiner project. The reviewer states: 'I'm concerned about potential license conflicts if we integrate this component with other parts of the system.' What does this comment primarily highlight?
'License compatibility' is central to open-source license management. It refers to ensuring that the licenses of different components used in a project don't conflict, particularly regarding copyleft provisions. If you combine code under GPL with code under MIT, for example, the GPL terms could apply to your entire project.
What will I practise in "Open Source Licence Communication — MIT, Apache, GPL, CLA Vocabulary"?
This module focuses on OSS Governance — real workplace phrasing you'll use on the job. It contains 13 scenario-based multiple-choice questions with instant feedback.
Is this exercise free to use?
Yes. Every exercise on CoderSlingo, including this one, is free to use with no account or sign-up required.
How many questions does this exercise have?
This module includes 13 questions. Each one gives an immediate right/wrong result plus a full explanation of the correct phrasing.
What happens if I answer a question incorrectly?
You'll see the correct answer highlighted straight away, along with a plain-English explanation of why it's right and why the other options don't fit — mistakes are part of the learning here.
Can I retry the exercise if I want a better score?
Yes — use the 'Try again' button on the results screen to reset your score and go through the questions again. There's no limit on attempts.
Who is this OSS Governance exercise for?
It's aimed at IT professionals with working English who want to sound more natural and precise around oss governance — useful whether you're preparing for real conversations at work or just building confidence with the vocabulary.
Do I need an account to track my progress?
No account is needed. Your progress through the exercise is tracked locally in your browser for the current session, and you can replay the module at any time.
How is this different from reading a blog article?
This exercise is an interactive drill that tests and reinforces specific phrasing through multiple-choice questions with instant feedback, while blog articles explain concepts and vocabulary in prose. The two work well together.
Where can I find more OSS Governance exercises?
See the OSS Governance hub for more modules like this one, or browse the full Exercises page for other IT-English topics.
Can I complete this exercise on my phone?
Yes — every exercise on CoderSlingo is fully responsive and works on phones and tablets, so you can practise anywhere.