Certified Open Source Developer for Enterprise key terms

A ten-criteria statement maintained by the Open Source Initiative that a license must satisfy to be certified as open source, covering free redistribution, source code availability, derived works, and no discrimination against persons or fields of use.

An organization founded by Richard Stallman that promotes software freedom and publishes the four freedoms, which emphasize running, studying, redistributing, and improving software rather than licensing terms alone.

The FSF's statement that users may run a program for any purpose, study how it works, redistribute copies, and distribute modified versions, with access to source code required for the latter two.

A nonprofit that reviews licenses against the Open Source Definition and maintains the canonical list of approved open source licenses used by enterprises and projects to validate license status.

A licensing technique that requires redistributors of modified software to release the modified source under the same terms, using copyright law to keep derivative works open rather than permitting proprietary relicensing.

A license such as MIT or Apache-2.0 that allows reuse, modification, and redistribution, including in closed-source products, typically requiring only attribution and preservation of notices and warranty disclaimers.

A strong copyleft license requiring that distributed derivative works be licensed under the GPL and that corresponding source be offered, with version 3 adding patent and anti-tivoization terms absent from version 2.

A weak copyleft license mainly for libraries: modifications to the library itself must stay under the LGPL, while applications that merely link to it may remain under other terms if relinking conditions are met.

A permissive license that grants an express patent license from contributors, requires notices and a NOTICE file to be preserved, and imposes a patent termination clause on parties that sue over the software.

A short permissive license granting use, copy, modification, and distribution rights provided the copyright notice and permission notice are included; it contains no explicit patent grant and no copyleft obligation.

A family of permissive licenses, including two-clause, three-clause, and four-clause variants, differing mainly in whether they forbid endorsement using the authors' names or require advertising acknowledgements.

A licensing approach that applies reciprocal source obligations only to the licensed component and its direct modifications, not to separate software that links to or calls it, lowering the burden on integrators.

A file-level weak copyleft license: modified files must remain under the MPL, but larger works combining those files with other code may be distributed under different terms, and it is compatible with GPL and LGPL.

The property that obligations of two or more licenses can be satisfied simultaneously when code is combined or redistributed, allowing the combined work to be released lawfully under an acceptable license.

A short standardized token such as Apache-2.0 or GPL-3.0-only, maintained by the SPDX project, that machines can parse to record exactly which license applies to a component or file.

A distribution model in which a project offers the same software under two license options, often a copyleft license for open use and a commercial license for proprietary integration, letting the maintainer monetize without closing the code.

A business approach where a vendor releases a core product as open source while reserving certain enterprise features, hosted services, or support under commercial terms to generate revenue.

A legal document in which a contributor grants a project the rights to use, relicense, or sublicense their contribution, often required before a pull request is merged into a foundation or corporate project.

A lightweight contribution attestation, added as a Signed-off-by line in commits, where the contributor certifies they have the right to submit the code under the project's license without a separate signed agreement.

A transfer of copyright ownership from a contributor to a project, foundation, or company, giving the recipient authority to enforce and relicense the code, unlike a CLA that only grants a license.

A proposed change submitted to a repository for review, discussion, and automated testing before the maintainers merge it, serving as the main review workflow on platforms such as GitHub and GitLab.

The practice of having maintainers or peers read a proposed change to check correctness, tests, style, security, and license headers before it is accepted into the main branch.

A person with write or administrative rights over a project who reviews contributions, merges changes, sets direction, and is often the gatekeeper for licensing and release decisions.

The documented structure of how a project makes decisions, such as benevolent dictator, meritocratic committer model, or foundation-directed board, covering roles, voting, and escalation paths.

A decision rule where proposals proceed unless significant objections are raised, often expressed as lazy consensus, allowing many projects to move quickly without formal votes on routine changes.

Applying open source practices such as shared repositories, inner-source licenses, and pull-request review inside a single company, so teams reuse internal code across organizational boundaries.

A team that centralizes an organization's open source strategy, covering license compliance, contribution approval, inventory, security response, and community engagement across engineering and legal.

An internal rule set defining how employees may contribute to or consume external open source projects, including approval steps, allowed licenses, and rules for disclosing company affiliation.

A tool-driven process that inventories third-party and open source components in a codebase, identifies their licenses and versions, and flags conflicts, obsolete dependencies, and known vulnerabilities.

A machine-readable inventory of a software product's components, versions, suppliers, and dependency relationships, often in SPDX or CycloneDX format, used for vulnerability and license tracking.

An automated inspection of source code, binaries, or package manifests to detect declared and undeclared licenses, producing findings that compliance reviewers then evaluate against policy.

The coordinated process by which a security flaw is reported privately to maintainers, fixed, and then published with a CVE identifier and advisory so downstream users can assess and patch.

A publicly maintained identifier scheme that gives each disclosed security flaw a unique standardized name, enabling tools and vendors to reference the same issue consistently across advisories and databases.

A published notice describing affected versions, severity, impact, and remediation for a flaw, often issued by a project or a database such as the GitHub Advisory Database or an OS vendor.

A copy of a repository, or a new community project derived from existing source, that evolves independently; forks may be short-lived development branches or permanent splits over direction or governance.

The canonical project repository and maintainers from which a downstream copy, fork, or internal derivative receives changes; fixing issues upstream avoids maintaining divergent local patches.

A small change applied to source code, often to fix a bug or backport a security fix; enterprises track local patches because they create divergence from upstream and must be re-evaluated on upgrade.

A company that builds a product whose core is open source and earns revenue through subscriptions, hosted services, support, or proprietary add-ons, balancing community rights with commercial sustainability.

The obligation under some copyleft licenses to provide corresponding source code to recipients of binaries, usually by including it or by a written offer valid for a stated period.