Rug pulls, forks, and open-source feudalism

Building from source and packaging models

• Several comments argue that routinely building from source shifts power to users: switching remotes is easier than abandoning vendor binaries, and cherry‑picking fixes doesn’t require maintainer releases.
• Guix (and likely Nix) is praised for “source by default” with binary caches and easy local patching; Debian/Devuan cited as long‑standing, reproducible‑build ecosystems, though not as “source‑transparent” as Guix.

CLAs, copyleft, and power asymmetry

• Many see CLAs that grant unilateral relicensing as the core enabler of rug pulls, especially when combined with copyleft: the company can go proprietary while others remain bound.
• Others note some CLAs (e.g., certain nonprofit/foundation ones) explicitly promise continued free licensing and are seen as acceptable when backed by strong governance.
• Copyleft without a CLA (e.g., Linux) spreads copyright to many contributors, making a lock‑in relicensing practically impossible.
• AGPL+CLA is described as particularly lopsided for SaaS: the company can run a closed service while competitors must publish their changes; Stallman’s view is summarized as prioritizing user freedom over contributor symmetry.

What is a “rug pull”?

• One camp says there’s no rug pull in FLOSS: old code and GPL/MIT versions “exist forever,” and maintainers owe no future labor. Rug pull can only mean stopping maintenance, which is always allowed.
• Another camp stresses dependency lock‑in, branding/network effects, active marketing of “open source forever,” and explicit promises (e.g., around core licenses). Under those conditions, relicensing is seen as betrayal.
• Some distinguish “snapshot and fork” from the large, ongoing effort of sustaining a competitive fork.

Hyperscalers, SaaS, and sustainability

• Strong resentment toward large cloud providers that monetize popular OSS as services without funding maintainers; examples like Elastic/Mongo/Redis are framed as defensive license changes against this.
• Others counter that clouds contribute heavily to core infrastructure (kernel, toolchains) and free marketing; they’re just using permissive licenses as written.
• There’s disagreement on whether criticizing rug pulls is “toxic purism” that distracts from the larger structural issue (hyperscaler dominance), or a necessary defense of community trust.

Funding, responsibility, and entitlement

• Multiple comments emphasize that most of us are “free riders”; OSS is gift‑giving, and it’s legitimate for maintainers to stop or change direction.
• Others argue gifts given repeatedly and heavily promoted create moral obligations, especially when users invest labor, integrations, and advocacy.
• There’s growing interest in more deliberate funding models: sponsoring foundations, directly paying maintainers, industry coordination mechanisms, or even government/sectoral funds.
• Some enterprises report being burned by license/business changes (Chef, CentOS, VMware/Tanzu) and are pivoting toward funding upstream OSS (e.g., Proxmox/QEMU) instead of proprietary vendors.

SSPL, AGPL, and license design

• SSPL is seen by some as “almost good”: a stronger anti‑SaaS copyleft, but criticized for vague scope (what counts as the “service”) and incompatibility with GPL/AGPL, making it risky in practice.
• Several participants wish for a clearer, OSI‑acceptable “AGPL‑plus” that targets proprietary hosted services without sweeping in generic infrastructure or breaking compatibility.