LPI OSS Essentials common mistakes
LPI OSS Essentials · Understand the traps and how to avoid them.
Treating 'open source' as meaning 'free of charge' and therefore judging a project's openness by its price tag rather than by the freedoms granted in its license.
The English word 'free' conflates two different ideas (cost versus liberty), and many candidates first meet Linux and open source software as zero-cost downloads, so they carry that framing into every question about licensing and business models.
What to do instead
Before the exam, memorise the four freedoms (run, study, redistribute, improve) and the OSI Open Source Definition as the test for openness. When a question mentions price, ask separately: does the license permit modification and redistribution? Practise by classifying a paid enterprise distribution as open source and a freeware binary as proprietary.
Confusing copyleft with permissive licenses, for example assuming MIT or Apache-2.0 code must be released under the same license when redistributed, or assuming GPL code can be dropped into a proprietary product.
Both families are 'open source', so candidates group them together and remember only that the source is available, missing the reciprocity obligation that distinguishes copyleft.
What to do instead
Build a two-column table: permissive (MIT, BSD, Apache-2.0) require only attribution and notice retention; copyleft (GPL, LGPL, AGPL) require derivative works to carry the same license. Note the specific triggers: distribution for GPL, network use for AGPL, and dynamic linking boundaries for LGPL. Test yourself with short scenarios such as 'vendor modifies GPL code and ships an appliance'.
Treating Creative Commons licenses as interchangeable with software licenses, or ignoring the difference between the CC variants and between CC and public domain dedications.
Candidates see 'open license' in both contexts and assume one mental model fits all, so they overlook the NC (non-commercial) and ND (no derivatives) restrictions that make some CC licenses non-conforming for open content and unsuitable for software.
What to do instead
Learn the CC building blocks (BY, SA, NC, ND) and which combinations are valid, plus CC0 as a public domain dedication rather than a license. Remember that CC does not recommend its licenses for software and that NC and ND versions fail the definition of open content. Practise mapping a stated reuse scenario to the correct license variant.
Describing open source business models as simply 'selling the software' or 'charging for support' without distinguishing the models and how each generates revenue while keeping the license intact.
The models are described with similar-sounding terms (support, subscription, hosted, dual licensing, open core) and candidates memorise labels without the underlying revenue mechanism.
What to do instead
For each model, write one sentence on who pays and for what: support and subscription (paying for SLA, updates, indemnity), hosted/SaaS (paying for operation of the service), dual licensing (paying for a non-copyleft license), open core (paying for proprietary features), crowdfunding and donations, and consortia funding. Then note which models are compatible with strong copyleft and which are not.
Answering project management questions with generic proprietary-software process language, ignoring that open source work is distributed, asynchronous, and volunteer-driven.
Most candidates come from traditional IT environments where release planning, roles, and decision-making are hierarchical, so they default to that vocabulary instead of the meritocratic, consensus-seeking norms of open projects.
What to do instead
Study the typical open source governance artefacts: charter, maintainers and committers, contribution guidelines, code of conduct, release cadence, and the role of the foundation. Practise describing how a decision moves from mailing-list discussion to maintainer consensus to release, and how that differs from a product manager assigning work.
Confusing the roles and mechanics of issue trackers, mailing lists, and pull/merge requests, for example assuming a merged pull request is the same as a released feature or that an issue is a support ticket.
These tools look familiar from everyday use, so candidates project their prior habits onto them rather than learning the review, sign-off, and release conventions of collaborative open source development.
What to do instead
Learn the lifecycle: issue or bug report, discussion, patch or pull request, review and sign-off, merge to the main branch, then release. Note the meaning of a Developer Certificate of Origin sign-off and of maintainer approval. Practise ordering the steps for a contributed bug fix.
Assuming a license automatically applies to a project just because it is publicly visible on a hosting platform, or assuming a repository without a license file is freely reusable.
Public visibility feels like permission, and candidates rarely encounter the default rule that absent a license, all rights are reserved.
What to do instead
Remember the default: no license file means no grant of rights beyond viewing and forking under the platform's terms. Learn to check for a LICENSE file, SPDX identifiers, and per-file headers. Practise answering 'a colleague wants to reuse code from a repository with only a README' with the correct 'ask the author for a license' reasoning.
Mixing up the organisations and artefacts: attributing the Open Source Definition to the FSF, the four freedoms to OSI, or the GPL to Apache, and confusing the FSF with the OSI in governance questions.
The two movements share history and vocabulary, so their names blur together, and candidates learn definitions without anchoring them to a body or document.
What to do instead
Create a small fact sheet: OSI maintains the Open Source Definition and approves licenses; FSF authored the GPL family and the four freedoms; Apache Software Foundation hosts Apache-2.0 and the Apache community process; Creative Commons publishes the CC licenses. Recall one distinctive fact per organisation, then test yourself by matching statements to bodies.
Answering collaboration questions by describing a single centralised workflow, missing the fork-and-pull model, upstream/downstream relationships, and the etiquette of patch submission.
Candidates who have only used a shared-branch workflow in a company assume everyone commits to one repository, so they misread questions about forks, remotes, and contributing changes back.
What to do instead
Learn the fork-and-pull model explicitly: fork upstream, clone, branch, commit, push to your fork, open a pull request, respond to review, and have it merged upstream. Understand upstream versus downstream and the norm of discussing large changes before writing code. Practise describing the path of a patch from a contributor's fork to an upstream release.
Treating 'open standards' and 'open formats' as synonyms for open source software, and assuming a format is open merely because its specification is published.
The word 'open' is reused across software, standards, and data, and candidates do not separate the criteria for each, such as royalty-free licensing and transparent process for standards.
What to do instead
Learn the distinct criteria: open standards require an open, transparent process and royalty-free or FRAND terms; open formats require a published, freely implementable specification; open source requires the four freedoms in the software license. Practise classifying examples such as ODF, PDF, and OOXML against these criteria, and note that an open format can be implemented by proprietary software.