GitButler is now fair source

Original Article ↗ Hacker News Discussion ↗

New “fair source” licenses like the Functional Source License aim to give companies a temporary monopoly on commercial use of their code—especially to fend off cloud giants—while committing to release it under a true open source license after a delay. Commenters weigh this model against traditional open source and open-core approaches, debating whether it fairly balances developer sustainability, investor pressure, and user freedom or simply introduces new lock‑in and legal ambiguity. Many see value in making more code visible that would otherwise stay proprietary, but remain wary of branding that positions non‑free licenses as “fair” and of vague restrictions on what counts as competing use.

Overview of “Fair Source” / FSL

  • “Fair Source” is framed as a middle ground between open source and proprietary:
    • Source is public.
    • You can use/modify/redistribute under restrictions that protect the vendor’s business.
    • After a delay (e.g., 2 years under the Functional Source License, FSL), code automatically becomes MIT/Apache-style open source (“delayed open source publication”, DOSP).
  • Advocates say this enables companies that would otherwise stay closed to publish code at all.

Business Motivation & Hyperscalers

  • Major driver: fear that hyperscalers will host a compatible SaaS using the same code and outcompete the original vendor.
  • Traditional open-core + cloud-hosting models are seen as fragile when AWS/GCP/Azure can undercut pricing and leverage their existing customer bases.
  • Some point to specific relicensing moves (ElasticSearch, Redis, etc.) as symptoms of this pressure plus VC expectations for high returns.

Comparison to Other Models

  • Open source:
    • Praised for user freedom, competition, vendor portability, and legal clarity.
    • Criticized as economically unsustainable for many maintainers; donations and corporate sponsorship often insufficient.
  • Open core:
    • Viewed by some as “freemium that withholds the useful bits.”
    • Others say it works when the free core is strong and the commercial features are well delimited.
  • Fair Source vs “source available”:
    • “Source available” is seen as vague; Fair Source tries to define a subset with public code, real usage rights, and mandatory DOSP.
    • FSL/FCL/BUSL are cited as examples under this umbrella.

User, Contributor, and Legal Concerns

  • Concerns about:
    • Vendor lock-in for at least the delay period (no competing hosting/support vendors).
    • Broad/ambiguous definitions of “competing use,” which can feel like a legal minefield.
    • CLAs that may give vendors more rights than contributors.
    • Potential chilling effects and legal gray areas compared to clean OSS licenses.
  • Some argue forks of relicensed projects are legally fine but acknowledge ongoing legal uncertainty.

Naming & Taxonomy Debate

  • “Fair Source” label is controversial:
    • Critics see it as lobbying/PR, implicitly suggesting other models are less “fair.”
    • Alternatives like “eventually-open source” or “head start” are suggested.
    • Proponents argue multiple specialized Fair Source licenses are needed for different monetization models and that any name would attract criticism.