Open-source software Study Guide

📖 Core Concepts Open‑source software (OSS): Code released under a license that grants the rights to use, study, modify, and redistribute the software and its source code. License types: Permissive (e.g., MIT, BSD, Apache) – lets derivative works be relicensed under any terms. Copyleft (e.g., GPL, MPL, EPL) – requires derivatives to keep the same OSS license (strong vs. weak). Development models: Cathedral – centralized, fixed roles (architect → manager → implementer). Bazaar – decentralized, users act as co‑developers; rapid releases, frequent integration. Key OSS tools: Distributed version control (Git), hosting platforms (GitHub/GitLab), issue trackers, mailing lists/IRC. Legal backbone: OSI’s Open Source Definition (based on Debian Free Software Guidelines) and case law such as Jacobson v. Katzer enforce license terms. Economic & social drivers: Reputation, network effects, public‑good value; enterprises adopt OSS for cost, portability, and speed, while contributors gain experience and visibility. --- 📌 Must Remember Four essential freedoms (FSF) → the subset of OSS that is “free software”. Permissive vs. copyleft: permissive → no downstream licensing restriction; copyleft → same‑license downstream. Bazaar workflow: early releases → community bug reports → contributors pick tasks → peer review → CI → stable release. Key legal precedent: Jacobson v. Katzer (2008) upheld that OSS license conditions are enforceable. Primary OSS development tools: Git (distributed VCS) > Subversion/CVS (centralized). Major adoption drivers: reduced licensing cost, rapid deployment, cross‑platform support, and avoidance of vendor lock‑in. --- 🔄 Key Processes Open‑sourcing a project Audit code for proprietary bits → clean up → choose an OSS license → publish repository → set up communication channels (mailing list, issue tracker). Bazaar development cycle Publish early/buggy “development” branch → community submits bug reports & pull requests → automated testing + CI → merge → create stable branch → freeze → final release. License selection workflow Identify desired downstream reuse (any license vs. must stay OSS) → pick permissive if you want maximal adoption; pick copyleft if you want to enforce openness of derivatives. Contributor onboarding New contributor reads CONTRIBUTING.md → picks a “good first issue” → forks repo → opens a pull request → receives mentor feedback → gains commit rights. --- 🔍 Key Comparisons Free software vs. Open‑source software Free software: emphasizes user freedoms (the four essential freedoms). Open source: emphasizes practical benefits (quality, speed, cost) and may allow proprietary add‑ons. Permissive vs. Copyleft license Permissive: “use‑anywhere” → easy corporate adoption, no obligation to open derivatives. Copyleft: “share‑alike” → guarantees that improvements stay open, may deter some commercial use. Cathedral vs. Bazaar model Cathedral: top‑down, fixed hierarchy, slower releases. Bazaar: bottom‑up, fluid roles, rapid, community‑driven releases. Centralized VCS vs. Distributed VCS Centralized (SVN, CVS): single repository, requires network access for most actions. Distributed (Git): each clone is a full repo → offline work, easy branching/forking. --- ⚠️ Common Misunderstandings “Open source = free of cost” – OSS may be free to use, but services (support, hosting) can be paid. “Any source‑available code is OSS” – source availability alone is insufficient; the license must grant modification and redistribution rights. “Copyleft prevents commercial use” – companies can commercialize OSS under copyleft; they just must release source of derivative works. “All contributors are paid employees” – most OSS contributors are volunteers; payment is rare and usually for support services. --- 🧠 Mental Models / Intuition “License as a contract”: Treat the license like a lease – it tells you what you can do with the house (code) and what you must return (attributions, same‑license). “Bazaar as a marketplace”: Think of the codebase as a stall where anyone can set up a booth (fork) and sell improvements (pull requests) back to the market. “Copyleft as a viral vaccine: once introduced, the “openness” spreads to all downstream products, ensuring the ecosystem stays healthy. --- 🚩 Exceptions & Edge Cases Weak copyleft (e.g., LGPL, MPL) – only certain parts (libraries) must stay open; programs that link to them can be proprietary. Dual licensing – a project may offer both a copyleft and a permissive/commercial license; users choose based on their needs. Source‑available but non‑OSS – some “open core” models release the core as OSS but keep valuable extensions under restrictive licenses. --- 📍 When to Use Which Choose a permissive license when you want maximum industry adoption, want to allow proprietary extensions, or are releasing a library/framework. Choose a copyleft license when you aim to build a community that shares improvements (e.g., core system tools, platforms). Use the Bazaar model for projects that benefit from many contributors, rapid prototyping, or when you lack a large internal team. Use the Cathedral model for safety‑critical, highly regulated software where strict governance is required. Pick Git for any new OSS project; fall back to SVN only when collaborating with legacy infrastructures. --- 👀 Patterns to Recognize “Development branch → nightly builds → stable release” pattern signals a Bazaar workflow. License block at the top of each file → indicates a copyleft project that enforces attribution per Jacobson v. Katzer. Issue tracker with “good first issue” label → a mature project encouraging new contributors. Presence of both LICENSE and CONTRIBUTING.md → indicates a well‑structured OSS project ready for external collaboration. --- 🗂️ Exam Traps Mistaking “source‑available” for “open source” – exam may list a tool that only shares source but restricts redistribution; answer: Not OSS. Confusing “free software” with “free of cost” – a question may ask which definition guarantees the four freedoms; answer: FSF’s free software definition. Assuming all GPL‑licensed code cannot be used commercially – the trap is the word “commercial”; GPL permits commercial use as long as source is released. Choosing “cathedral” for a project that has many community pull requests – the presence of frequent community contributions points to a Bazaar model, not cathedral. Over‑applying copyleft to a weak‑copyleft license – MPL/EPL require only modifications to the MPL/EPL‑covered files to stay open, not the entire program. ---