LPI OSS Essentials cheat sheet

Source code is human-readable instructions; compiled binaries are machine-executable output produced by a compiler or interpreter toolchain.

Free Software Foundation's four freedoms: run the program for any purpose, study and change it, redistribute copies, and distribute modified versions.

Open source is a development and licensing model; free software is a philosophical movement. The same program can satisfy both definitions.

A package manager resolves dependencies, verifies signatures, and tracks installed versions; examples include apt, dnf, pacman, and zypper.

Libraries provide reusable functions linked at build time (static) or loaded at runtime (shared, e.g. .so or .dll files).

Version numbers commonly follow MAJOR.MINOR.PATCH: MAJOR signals incompatible API changes, MINOR adds backward-compatible features, PATCH fixes bugs.

A distribution bundles the Linux kernel with userland tools, an init system, a package manager, and default configuration choices.

Proprietary software restricts modification and redistribution; its source is typically withheld, so auditing and forking are not permitted.

Reproducible builds let independent parties rebuild identical binaries from source, enabling verification that shipped binaries match published code.

Permissive licenses (MIT, BSD, Apache-2.0) allow relicensing of derivative works under other terms, including proprietary ones.

Copyleft licenses require derivative works distributed publicly to carry the same license terms; GPL triggers on distribution, not on private use.

GPLv2 and GPLv3 are strong copyleft; LGPL is weak copyleft, permitting proprietary programs to link against the library under conditions.

AGPLv3 extends GPL obligations to users interacting with the software over a network, closing the application service provider loophole.

Apache-2.0 includes an express patent grant and a patent retaliation clause; MIT and BSD do not address patents explicitly.

The BSD family (2-clause, 3-clause) differs mainly by the non-endorsement clause in the 3-clause variant.

Compatibility rule: code under a permissive license can usually be combined into a GPL project; combining GPL code into a proprietary product is not permitted.

License compatibility must be checked before merging codebases; two copyleft licenses with conflicting terms may be mutually incompatible.

OSI approval certifies a license meets the Open Source Definition; FSF approval certifies it is a free software license. The lists differ.

Creative Commons licenses are not recommended for software; use them for text, images, audio, video, and educational materials.

CC BY requires attribution only; CC BY-SA adds share-alike, so adaptations must use the same license.

CC BY-NC forbids commercial use; NC is legally ambiguous because 'commercial' is undefined, which complicates corporate adoption.

CC BY-ND permits redistribution of verbatim copies but forbids distributing modified versions; it is therefore not a free license by Definition standards.

CC0 is a public domain dedication with no conditions; it is not a license and waives rights where law allows.

All CC licenses from version 4.0 are irrevocable once granted; authors may stop offering the license but cannot retract rights already given.

Attribution requires identifying the creator, the license, a link to the source, and an indication of whether changes were made.

Open educational resources often use CC BY or CC BY-SA; NC and ND variants restrict remixing and commercial course delivery.

Open data licenses include ODbL (share-alike for databases) and PDDL; government data portals frequently use CC BY or CC0.

Support and services model: software is free, revenue comes from SLAs, consulting, training, and integration work.

Open core: a free community edition plus paid proprietary features, hosting, or enterprise add-ons.

Hosted or SaaS model: the vendor runs the open source software for customers and charges for operations, uptime, and convenience.

Dual licensing: the same code is offered under a copyleft license for free and a proprietary license for a fee, viable only with full copyright ownership.

COSS (commercial open source software) companies rely on the software being genuinely open to build community and trust, then monetize adjacent value.

Relicensing risk: a project that changes from a permissive or copyleft license to a more restrictive one can trigger community forks such as governance-driven alternatives.

Trademark and brand are often the durable asset: the code can be forked, but the project name and certification marks cannot.

Foundation stewardship (e.g. Apache, Linux Foundation) separates governance from any single vendor and reduces single-vendor risk for adopters.

Total cost of ownership includes migration, training, integration, and support contracts, not only license fees.

A roadmap communicates direction and themes over quarters; a release plan commits to specific deliverables and dates.

Issue trackers record bugs, feature requests, and tasks; labels, milestones, and assignees provide triage and prioritization.

Semantic versioning and changelogs let downstream consumers assess upgrade risk before adopting a new release.

Release branches isolate stabilization work; the main branch continues to receive new development.

A CONTRIBUTING file states how to report bugs, submit patches, and run tests; a CODE_OF_CONDUCT sets behavioral expectations.

Governance models range from benevolent dictator to meritocracy to foundation-led; the model determines who can merge and who votes.

Continuous integration runs automated tests on every proposed change, reducing the cost of reviewing and merging contributions.

A maintainer's bus factor measures how many people must disappear before the project stalls; documented processes and shared credentials raise it.

Mailing lists remain the canonical decision record for many projects; archives are public and searchable, giving durable rationale.

Issue trackers and pull requests host code review; review comments are public and become part of the project's technical history.

Real-time chat (IRC, Matrix, Slack) suits quick questions; decisions reached there should be summarized back to a persistent channel.

Asynchronous communication respects time zones; write full context in one message rather than requiring a live conversation.

A patch submission typically includes a commit message explaining why the change is needed, not only what changed.

Code review etiquette: comment on the code, not the person; distinguish blocking issues from optional suggestions.

Forks are legitimate collaboration tools; a fork may later be merged upstream, and forking is not inherently hostile.

Licensing hygiene in collaboration: contributors may need a CLA or DCO sign-off to confirm they have the right to submit the code.

Public archives make tone and clarity matter; sarcasm and terse replies read differently across cultures and languages.