14.1 Open Source Benefits and GitHub Sponsors

Why GH-900 tests open source and Sponsors

Domain 7 of GitHub Foundations (GH-900)—Explore the GitHub community, 5–10% of the exam—opens with describe the benefits of open source and GitHub Sponsors. The January 2026 outline is product-and-community knowledge, not a bar exam in copyright. You must still know what open source is, why teams publish it, how the three common licenses differ at a conceptual level, and how money reaches maintainers on GitHub.com.

GitHub's About GitHub Sponsors page is the product source for fees, eligibility, and the closed Matching Fund. GitHub's Licensing a repository page plus choosealicense.com are the license sources. GH-900 will not ask you to recite clause numbers. It will ask whether a public repo is automatically open source (it is not), whether MIT includes an express patent grant (it does not; Apache 2.0 does), and whether GitHub keeps a cut of a personal-account sponsorship (it does not).

What open source actually means

Open source software is software whose license lets anyone use, modify, and share it, including for commercial purposes, under stated conditions. Microsoft Learn's InnerSource module uses that same three-verb definition. The idea behind the license is that sharing source produces more reliable software because more people can inspect it, reuse it, and improve it.

A public repository on GitHub is not the same thing. GitHub's Terms of Service give other GitHub.com users the right to view and fork a public repository. That is a platform right, not a copyright license to ship the code in a product. Without a license file, default copyright applies: the author keeps all rights, and nobody else may reproduce, distribute, or create derivative works. GitHub's licensing docs state this trap in plain language. Exam cue: "the repo is public, so a company can embed the library in a closed-source app" is false until a license says so.

Put a LICENSE (or LICENSE.md / LICENSE.txt) in the repository root. GitHub's license picker appears when you create a new repository; after that you add the file yourself. GitHub detects a known license with Licensee and shows a badge. A one-line README note ("MIT licensed") helps humans; the file is what scanners and GH-900 both expect.

Benefits GH-900 wants by name

Four benefits show up in Domain 7.1 scenarios. Name them, then apply them.

Transparency. Anyone can read the source, the issue tracker, and the pull request history. Security researchers, downstream packagers, and hiring managers can all inspect the same tree. Hidden defects and surprise telemetry are harder to bury when the code is public. Transparency is not "no secrets ever"—maintainers still keep deploy keys and production credentials out of git—but the product is inspectable.

Reuse. Libraries, CLIs, and GitHub Actions that already exist do not need to be rewritten. Permissive licenses make reuse in both open and closed products straightforward. Copyleft licenses still allow reuse, including commercial reuse, if you honor the same-license and source-disclosure conditions. The career-adjacent version of reuse is a public portfolio: a merged pull request is evidence you can work in someone else's codebase.

Community. Issues, Discussions, and pull requests concentrate contributors who do not share an employer. Maintainers get bug reports, translations, and docs from people they never hired. Contributors get mentorship and a shared vocabulary. GitHub's contributing guide treats non-code work—docs, design, triage, mentorship—as real contribution. Do not pick "only merged code counts" on the exam.

Career. Public history is a résumé that compiles. Recruiters search GitHub. Students use the GitHub Student Developer Pack to practice on the same tools professionals use. Maintainers who later apply for jobs can point at releases, CODEOWNERS reviews, and Sponsors profiles. Career value is a listed Domain 7.1 benefit, not a soft extra.

The three licenses at conceptual depth

GH-900 expects MIT, Apache License 2.0, and GPL (the GNU General Public License family, typically v3.0 in choosealicense tables). All three allow commercial use, distribution, modification, and private use. They split on what you must give back.

MIT is a short permissive license. The one condition is: keep the copyright notice and the license notice in copies and substantial portions. You may ship a closed-source product that includes MIT code. You may relicense your larger work under different terms. MIT does not include an express patent grant. Choosealicense summarizes MIT as "keep notices; modifications and larger works may be distributed under different terms and without source code."

Apache License 2.0 is also permissive, and it adds an express patent grant from each contributor. Recipients get a royalty-free patent license covering claims necessarily infringed by the contribution. Conditions: keep license and copyright notices, and state changes in modified files. Apache 2.0 also does not grant trademarks. If a scenario says "we need a permissive license and a patent grant from contributors," the answer is Apache 2.0, not MIT.

GPL (usually GNU GPLv3 on GitHub) is copyleft. Permissions are conditioned on making complete source of licensed works and modifications available, including larger works that use the licensed work, under the same license. You must preserve copyright and license notices and state changes. Commercial use is allowed—GPL is about freedom, not price—but you cannot drop GPL code into a proprietary binary and keep the combined work closed. GPLv3 also includes an express patent grant; the exam distinction versus Apache is copyleft, not patents.

GitHub Sponsors: funding maintainers on the platform

GitHub Sponsors lets the developer community financially support people and organizations who design, build, and maintain the open source they depend on, directly on GitHub. You sponsor anyone with a sponsored developer profile or sponsored organization profile. You can do that on behalf of your personal account or an organization. Tiers are set by the sponsored account: one-time amounts, monthly amounts, and optional benefits. Sponsorships reuse the paying account's existing billing date, payment method, and receipt. You can sponsor one profile or several in bulk.

Fees: the number GH-900 will quote

GitHub's About GitHub Sponsors page is explicit:

• Sponsorships from personal accounts: GitHub charges no fees. 100% of those sponsorships go to the sponsored developer or organization.
• Sponsorships from organization accounts: GitHub charges a fee of up to 6%. That 6% splits as 3% credit card processing plus 3% GitHub service processing.
• Organizations can save the 3% card fee by switching to invoiced billing for sponsorships.

Memorize the split, not a vague "GitHub takes a small cut." A trap option that says personal-account sponsorships pay 6% is wrong. A trap that says organization sponsorships are always free is wrong. Invoice billing does not erase the GitHub 3% service fee; it can erase the card 3%.

Who can receive money

Anyone who contributes to an open source project and lives in a supported region is eligible to become a sponsored developer. GitHub's contribution list is deliberately wide: bug reports, issue triage, code, documentation, leadership, business development, project management, mentorship, and design. You do not need to be the repository owner or a high-star maintainer. If you live outside a supported region, you join a waitlist. Any organization that contributes to an open source project and legally operates in a supported region can become a sponsored organization; otherwise it also waitlists at github.com/sponsors.

Anyone in any region can sponsor eligible maintainers. The geographic limit is on receiving funds, not on sending them. Extra GitHub Sponsors terms apply once you are sponsored.

Matching Fund: closed, not current

The GitHub Sponsors Matching Fund aimed to match community funding for eligible individual maintainers. Eligibility has passed. Applications received after the January 1, 2020 deadline are not eligible. Payments to sponsored organizations and payments from organizations were never eligible. Donations between sponsored developers were not matched. If a 2026 exam item says GitHub still matches new Sponsors dollar-for-dollar, the answer is false. Treat the Matching Fund as historical policy, not a live benefit.

Exam scenarios and traps

• "Public on GitHub, no LICENSE" → viewers may view and fork under the Terms of Service; they may not treat the code as open source. Add MIT, Apache 2.0, or GPL (or another license) on purpose.
• "We want permissive reuse and an explicit patent grant" → Apache 2.0, not MIT.
• "We want derivatives to stay under the same license with source" → GPL, not MIT.
• "GPL forbids commercial use" → false. GPL allows commercial use; copyleft is the constraint.
• "Sponsor a maintainer from my user account" → no GitHub fee, 100% to the sponsored party.
• "Our company org account sponsors the same maintainer" → up to 6% (3% + 3%); invoice billing can drop the card 3%.
• "I triage issues and write docs; can I join Sponsors?" → yes, if you also live in a supported region. Contribution is not code-only.
• "GitHub will match my new 2026 sponsorship" → no. Matching Fund applications after 1 January 2020 are ineligible.

If you can name the four benefits, pick MIT vs Apache 2.0 vs GPL from a one-line story, and quote the personal-account 0% / organization-account up-to-6% fee split, you have Domain 7.1. The next section is how GitHub hosts and discovers those projects for free.