Business Source License 1.1 Proposal for Rosie

This page will expire in

Expires

Current Time

Business Source License 1.1 Proposal for Rosie

Prepared for: FPP Governing Board Date: October 2025 Purpose: Licensing strategy recommendation

Executive Summary

Recommendation: License Rosie under Business Source License 1.1 (BSL 1.1) to protect cooperative member value while maintaining source transparency.

Key Benefits:

✅ Source transparency - Code is public and auditable (builds trust)
✅ Prevents exploitation - Hyperscalers cannot offer competing services
✅ Ensures open source future - Automatically converts to Apache 2.0 after 4 years
✅ Aligns with cooperative values - Members benefit, not external corporations
✅ Enables contributions - Community can participate and improve Rosie
✅ Proven successful - Used by MariaDB, CockroachDB, Sentry, HashiCorp

Who Can Use Rosie Under BSL 1.1:

✅ FPP members (unrestricted)
✅ Organizations for internal use
✅ Service providers serving clients
✅ Researchers and educators
✅ Contributors improving the platform

Only Restriction: Cannot offer competing hosted Rosie-as-a-Service without commercial license from FPP.

The Problem: Open Source Exploitation

Recent Industry Examples

ElasticSearch (Open Source → SSPL)

Built thriving open source search platform
AWS launched "AWS Elasticsearch Service" capturing commercial value
Elastic forced to change license to protect business
Lesson: Permissive licensing enables exploitation by well-funded competitors

MongoDB (Open Source → SSPL)

Created popular database as open source
AWS launched "DocumentDB" (MongoDB-compatible) without contributing back
MongoDB switched to Server Side Public License (SSPL)
Lesson: Hyperscalers can commoditize open source work without supporting creators

Redis (Open Source → Dual License)

Built in-memory database as open source
AWS ElastiCache offered managed Redis without upstream contribution
Redis Labs moved to dual licensing model
Lesson: Open source doesn't prevent competitive services

HashiCorp (Open Source → BSL 1.1) - 2023

Terraform, Vault, Consul built as open source
Cloud providers offered competing managed services
HashiCorp switched all products to BSL 1.1
Community initially concerned but adoption continues
Lesson: Even established open source can transition to BSL successfully

The Pattern

Companies building open source infrastructure eventually need protection:

Start with permissive open source (Apache 2.0, MIT)
Build community and adoption
Cloud providers launch competing managed services
Original creators struggle to monetize their work
Forced to switch licenses (but harder after adoption)

BSL 1.1 allows us to be proactive, not reactive.

What is Business Source License 1.1?

Overview

BSL 1.1 is a source-available license created by MariaDB that:

Makes source code publicly viewable and forkable
Allows unrestricted non-production use
Permits production use except for competing services
Automatically converts to open source (Apache 2.0 or MIT) after a Change Date
Enables community contributions to flow back to the project

Key Terms

License Grant:

Source code is publicly available
Anyone can use for development, testing, research
Production use allowed except for "Additional Use Grant" restrictions

Additional Use Grant (Customizable):

You may make production use of the Licensed Work, provided such use
does not constitute a Competing Use.

"Competing Use" means offering the Licensed Work as a hosted service
that competes with Rosie AI Assistant services offered by Licensor or
its authorized partners.

Change Date:

After 4 years (customizable: 3-5 years typical), license automatically converts to Apache 2.0
Code becomes fully open source with no restrictions
Provides time to establish market position

Change License:

Apache 2.0 (recommended) or MIT
OSI-approved open source license
Happens automatically on Change Date

BSL 1.1 vs Traditional Open Source

Comparison Table

Feature	BSL 1.1	Apache 2.0 / MIT	GPL	Proprietary
Source Visible	✅ Yes	✅ Yes	✅ Yes	❌ No
Community Contributions	✅ Yes	✅ Yes	✅ Yes	❌ Limited
Prevents Competing Services	✅ Yes	❌ No	❌ No	✅ Yes
Becomes Open Source	✅ Automatic (4 years)	✅ Already is	✅ Already is	❌ Never
Protects Creator Revenue	✅ Yes	❌ No	❌ No	✅ Yes
Copyleft (Changes Flow Back)	✅ Can require	❌ No	✅ Yes	❌ No
Audit & Security Review	✅ Anyone can	✅ Anyone can	✅ Anyone can	❌ Limited
Fork for Improvements	✅ Yes (non-production)	✅ Yes (any use)	✅ Yes (must share back)	❌ No

Key Insight: BSL 1.1 provides transparency and community benefits of open source while protecting against exploitation.

Alignment with Cooperative Principles

International Cooperative Alliance Principles

1. Voluntary and Open Membership

✅ BSL 1.1 Aligned:

Anyone can become FPP member and use Rosie
No artificial barriers to membership
Source code transparency enables informed participation

❌ Pure Open Source Risk:

Non-members (hyperscalers) can extract value without joining cooperative
Undermines incentive to become member

2. Democratic Member Control

✅ BSL 1.1 Aligned:

Members control Rosie roadmap and governance
Prevents external corporations from forking and fragmenting control
FPP maintains democratic decision-making authority

❌ Pure Open Source Risk:

Anyone can fork and compete without member input
Democratic control diluted by external forks

3. Member Economic Participation

✅ BSL 1.1 Aligned:

Members earn Return on Contributions
IPR licensing revenue flows to members
FPP receives revenue share from Rosie services
Value created by members benefits members

❌ Pure Open Source Risk:

Members contribute work for free
Corporations profit from member contributions
No economic benefit for cooperative members
Classic exploitation: labor without compensation

4. Autonomy and Independence

✅ BSL 1.1 Aligned:

FPP maintains control over canonical Rosie implementation
Cannot be co-opted by external interests
Prevents vendor lock-in by other corporations

❌ Pure Open Source Risk:

AWS or Google could fork, invest heavily, capture market
FPP becomes dependent on external fork
Loss of autonomy

5. Education, Training, and Information

✅ BSL 1.1 Aligned:

Source code available for learning and education
Anyone can study implementation
Researchers can analyze and improve
Full transparency for educational purposes

✅ Pure Open Source: Also aligned (no difference here)

6. Cooperation Among Cooperatives

✅ BSL 1.1 Aligned:

Other cooperatives can use Rosie (not competing services)
FPP can license to partner cooperatives
Enables cooperative ecosystem growth
Example: Platform Coop Development Kit could use Rosie

✅ Pure Open Source: Also aligned (no difference here)

7. Concern for Community

✅ BSL 1.1 Aligned:

Code becomes fully open source after 4 years (community benefit guaranteed)
Source transparency enables community trust
Contributions accepted from anyone
Community can fork if FPP ever violates trust (escape hatch exists)

❌ Pure Open Source Risk:

If hyperscalers capture value, less resources for community investment
FPP struggles financially, community suffers
Sustainability matters for long-term community support

BSL 1.1 is "Cooperative Source Licensing"

Traditional Open Source: "Work for free, corporations profit" BSL 1.1: "Contribute to cooperative, members prosper, eventually fully open"

BSL 1.1 better aligns with cooperative values than pure open source.

Addressing Board Concerns

Concern 1: "Open Source Aligns with Our Trust Mission"

Response:

Source transparency ≠ Permissive licensing

BSL 1.1 provides the transparency needed for trust:

✅ Source code is public and auditable
✅ Anyone can review security and privacy implementations
✅ No "black box" concerns
✅ Community can verify trust claims

Additional Use Grant doesn't compromise transparency:

Only restricts competing hosted services
Doesn't hide code or limit auditing
Organizations can still self-host and audit

FPP's mission: Build trust infrastructure. BSL 1.1 says "We're transparent AND sustainable."

Concern 2: "We Need Maximum Adoption"

Response:

BSL 1.1 does not limit legitimate adoption.

Who Can Use Rosie Under BSL 1.1:

✅ FPP Members - Unrestricted use for all FPP purposes ✅ Organizations - Can deploy internally for their teams ✅ Service Providers - Can use to serve their clients (not competing with Rosie AI Assistant) ✅ Researchers - Can study, fork, experiment ✅ Educators - Can teach using Rosie ✅ Open Source Projects - Can integrate for non-competing purposes ✅ Downstream Organizations - Can extend and customize under derivative license

❌ Only Restriction: Cannot offer "Managed Rosie AI Assistant as a Service" competing with FPP's offerings

Examples of BSL 1.1 adoption success:

MariaDB: 5+ million deployments, thriving ecosystem
CockroachDB: Thousands of enterprise customers
Sentry: 100,000+ organizations using it
HashiCorp: Terraform adoption continues post-BSL switch

Adoption comes from value, not permissive licensing. If Rosie solves real problems, organizations will use it.

Concern 3: "Contributors Won't Participate"

Response:

Evidence shows contributors DO participate in BSL projects:

Successful BSL 1.1 Community Projects:

Sentry: 30,000+ GitHub stars, 500+ contributors
CockroachDB: 25,000+ stars, active community
MariaDB: Massive contributor ecosystem
Redpanda: Growing community, regular contributions

Why contributors participate:

Source is visible - Same transparency as open source
Impact and reputation - Working on important projects builds credibility
Self-interest - Their improvements benefit their own usage
Eventual open source - Contributions WILL be fully open after Change Date
Better than corporate open source - Many "open source" projects controlled by single company anyway

FPP's advantage: We REWARD contributors

Return on Contributions (time credits)
Reputation on leaderboard
Business inquiries from expertise
Potential IPR licensing revenue

Unlike traditional open source (free labor), BSL 1.1 + cooperative model = contributors prosper.

Concern 4: "Too Complex / Unfamiliar"

Response:

BSL 1.1 is simpler than GPL and increasingly familiar:

Simpler than GPL:

GPL: Complex copyleft rules, derivative work definitions, compatibility issues
BSL 1.1: "Use freely, don't compete, becomes Apache 2.0 in 4 years"

Growing adoption and familiarity:

MariaDB (since 2016)
CockroachDB (2019)
Sentry (2019)
HashiCorp Terraform/Vault (2023) - Major validation
Redpanda, Materialize, others

Legal clarity:

Created by MariaDB with legal review
Used by publicly traded companies (HashiCorp)
Clear Additional Use Grant mechanism
Well-understood by enterprise legal teams

If board prefers something even simpler:

Could use Fair Source License (fixed user limits, then open)
Could use Elastic License 2.0 (similar to BSL but different terms)
BSL 1.1 is the most established "source-available with open future" option

Concern 5: "Can We Change License Later?"

Response:

BSL 1.1 provides maximum flexibility:

Built-in evolution:

Automatically becomes Apache 2.0 on Change Date
No relicensing process needed
Predictable open source future

Manual conversion option:

Can convert to Apache 2.0 earlier if board decides
BSL → Open Source is easy
Open Source → BSL is nearly impossible (requires all contributor agreement)

Dual licensing option:

BSL 1.1 for general use (protects FPP)
Commercial license for hosted service providers (revenue generation)
Many successful projects use this model

License flexibility:

Can adjust Additional Use Grant terms for future releases
Can grant exemptions to strategic partners
Can offer different terms to cooperatives vs corporations

Starting with BSL 1.1 preserves options. Starting with MIT/Apache eliminates them forever.

Recommended BSL 1.1 Configuration for Rosie

Proposed Terms

License: Business Source License 1.1

Change Date: 4 years from each release date (Example: Code released in 2025 becomes Apache 2.0 in 2029)

Change License: Apache License 2.0 (Well-established, permissive open source license)

Additional Use Grant:

Additional Use Grant: You may make production use of the Licensed Work,
provided that such use does not include offering the Licensed Work to
third parties as a hosted or managed service competitive with Rosie AI
Assistant services provided by Steven Hazel (Licensor), the First Person
Network Cooperative, or their authorized partners.

For purposes of this license, "competitive service" means:
(a) Offering Rosie AI Assistant functionality as a managed service
    to third parties for a fee, or
(b) Using the Licensed Work as a substantial component of a commercial
    AI assistant platform offering that directly competes with Rosie
    AI Assistant.

Clarifications (NOT considered competing use):
- Using Rosie internally within your organization
- Consultants/service providers using Rosie to serve their clients
- Educational and research use
- Using Rosie as part of a larger product where Rosie is not the
  primary value proposition
- Non-profit and open source project use

Contribution License Agreement:

Any modifications or improvements submitted to the Licensed Work must be
licensed back to the Licensor under the same BSL 1.1 terms, ensuring
contributions benefit the entire community.

Exemptions for Cooperative Ecosystem

FPP Member Exemption:

Members of the First Person Network Cooperative (FPNC) in good standing
are granted unlimited production use rights without restriction under
this Additional Use Grant. This exemption applies to:
- Individual member use
- Organizational member use
- Member-led service provider use

This ensures cooperative members receive maximum value from their
membership and contributions.

Strategic Partner Provision:

Licensor reserves the right to grant explicit exemptions to this
Additional Use Grant to strategic partners, other cooperatives, or
organizations that align with the mission of the First Person Network
Cooperative.

Implementation Plan

Phase 1: Initial Release (Months 1-3)

Actions:

Publish Rosie source code under BSL 1.1 on GitHub
Include clear LICENSE file and explanation
Create documentation explaining:
- What BSL 1.1 means for users
- How to comply with Additional Use Grant
- Path to commercial license if needed
Set up contribution process (CLA)

Communication:

Blog post: "Why Rosie Uses BSL 1.1: Protecting Cooperative Value"
FAQ page addressing common questions
Proactive outreach to potential users explaining terms

Phase 2: Community Building (Months 3-12)

Actions:

Accept community contributions
Build contributor leaderboard and recognition
Offer Return on Contributions rewards
Grant strategic exemptions as appropriate

Monitoring:

Track forks and how they're being used
Monitor for potential competing services
Engage with community about license

Phase 3: Dual Licensing (Year 1+)

Actions:

Offer commercial licenses to organizations wanting to offer competing services
Price commercial licenses to generate FPP revenue
Use commercial license revenue to fund development and cooperative operations

Example Commercial License Terms:

Hosted service providers: % of revenue or annual fee
Strategic partners: Custom terms aligned with mutual benefit
Cooperatives: Generous terms or exemptions

Phase 4: Open Source Conversion (Year 4)

Actions:

Year 4 code automatically converts to Apache 2.0
Celebrate full open source release
Continue releasing new versions under BSL 1.1 (with their own 4-year countdown)

Result:

Mature, established code is fully open
New innovations continue to have 4-year protection
Best of both worlds: protection + eventual openness

Financial Impact

Revenue Protection

Scenario: Without BSL 1.1 (Pure Open Source)

Year 1: FPP releases Rosie as MIT licensed Year 2: AWS notices growing adoption Year 3: AWS launches "AWS Rosie Managed Service" Year 4: AWS captures 80% of market, FPP gets nothing Year 5: FPP struggles to fund development, falls behind AWS version

FPP Total Revenue: Minimal, from consulting only

Scenario: With BSL 1.1

Year 1: FPP releases Rosie under BSL 1.1 Year 2: Organizations adopt for internal use (allowed) Year 3: Some want managed service → license from FPP → revenue Year 4: FPP uses licensing revenue to improve Rosie Year 5: Original code becomes Apache 2.0, new code still BSL protected

FPP Total Revenue: Licensing fees + consulting + service revenue

Revenue Sources Under BSL 1.1:

Rosie AI Assistant hourly rates (FPP revenue share)
IPR licensing fees (FPP revenue share)
Commercial licenses for competing services
Consulting and implementation services
Strategic partnership agreements

Cost Comparison

Pure Open Source:

$0 licensing revenue
Vulnerable to well-funded competition
Difficult to sustain development
Risk: Project fizzles due to lack of funding

BSL 1.1:

Licensing revenue stream
Protected from exploitation
Sustainable development funding
Risk: Some users complain about restrictions (minor, manageable)

Net Financial Impact: BSL 1.1 significantly more favorable for FPP sustainability.

Risk Analysis

Risks of BSL 1.1

Risk 1: Some Users Refuse Due to License

Likelihood: Low to Medium Mitigation:

Clear documentation explaining terms
Generous Additional Use Grant (only restricts competing services)
Offer exemptions for strategic use cases
Highlight automatic open source conversion

Reality Check: HashiCorp adopted BSL 1.1 for Terraform despite millions of users. Adoption continues.

Risk 2: Community Fork for "Freedom"

Likelihood: Low Mitigation:

Source-available allows forking for non-production (experimentation allowed)
Engage with community about sustainability concerns
Highlight cooperative benefits and contributor rewards

Reality Check: Most BSL projects have not seen significant "freedom forks." Users understand the reasoning.

Risk 3: Perception as "Not True Open Source"

Likelihood: Medium Mitigation:

Frame as "Cooperative Source" aligned with FPP values
Emphasize automatic Apache 2.0 conversion (open source future guaranteed)
Point to successful BSL 1.1 projects (MariaDB, CockroachDB, HashiCorp)

Reality Check: Transparency and mission matter more than OSI approval. Many "open source" projects are controlled by single corporation anyway (MongoDB Atlas, Elastic Cloud, etc.).

Risks of Pure Open Source (MIT/Apache 2.0)

Risk 1: Hyperscaler Exploitation

Likelihood: HIGH Impact: SEVERE

AWS, Google Cloud, or Microsoft could launch managed Rosie service, capturing all commercial value while contributing nothing. FPP left with no revenue stream.

This has happened repeatedly: ElasticSearch, MongoDB, Redis, Kafka, and more.

Risk 2: Fork Fragmentation

Likelihood: Medium Impact: HIGH

Multiple competing forks emerge, fragmenting ecosystem. Users confused about which version to use. Community divides. FPP loses control of roadmap.

Risk 3: Unsustainable Development

Likelihood: HIGH Impact: SEVERE

Without revenue, FPP cannot fund development. All-volunteer model leads to burnout. Rosie stagnates. Users abandon for better-funded alternatives.

Risk Comparison

Risk	BSL 1.1	Pure Open Source
Hyperscaler Exploitation	✅ Protected	❌ Likely
Loss of Revenue	✅ Protected	❌ Likely
Fork Fragmentation	✅ Reduced	❌ Possible
Unsustainable Development	✅ Funded	❌ Likely
Some Users Refuse	⚠️ Possible	✅ Unlikely
Community Complaints	⚠️ Possible	✅ Unlikely

BSL 1.1 has minor, manageable risks. Pure open source has existential risks.

Alternatives Considered

Option 1: Fully Proprietary (Closed Source)

Rejected because:

❌ Contradicts transparency mission
❌ No community contributions
❌ Reduces trust (black box)
❌ Never becomes open source

Option 2: GPL (Copyleft Open Source)

Rejected because:

❌ Doesn't prevent competing services (AWS can offer managed GPL software)
❌ Complex copyleft rules confuse users
❌ Viral nature may deter enterprise adoption
❌ Provides no revenue protection

Option 3: SSPL (Server Side Public License)

Considered but not recommended:

✅ Prevents hyperscaler exploitation (like BSL)
❌ Not OSI-approved, controversial
❌ More aggressive copyleft than needed
❌ MongoDB/ElasticSearch baggage (reactive, not proactive)

BSL 1.1 is better received than SSPL.

Option 4: Fair Source License

Considered as alternative:

✅ Simple user-based limits
✅ Converts to open source after threshold
❌ Less established than BSL 1.1
❌ User counting can be complex

BSL 1.1 is more established and flexible.

Option 5: Elastic License 2.0

Considered as alternative:

✅ Similar restrictions to BSL 1.1
✅ Used by ElasticSearch, Kibana
❌ No automatic open source conversion (stays proprietary)
❌ ElasticSearch has contentious history with AWS

BSL 1.1 better aligns with eventual open source commitment.

Recommendation

Adopt Business Source License 1.1 with:

4-year Change Date
Apache 2.0 Change License
Additional Use Grant preventing competing hosted services
FPP member exemption for unlimited use
Contribution license requiring changes flow back to community

Rationale:

✅ Protects FPP and members from exploitation
✅ Maintains source transparency for trust
✅ Enables community contributions
✅ Ensures open source future (automatic conversion)
✅ Aligns with cooperative values (members benefit)
✅ Proven successful by multiple projects
✅ Provides sustainable revenue model

BSL 1.1 is the optimal balance between transparency, community, sustainability, and protection.

Next Steps

If Board Approves:

Legal Review (Week 1-2)
- Have legal counsel review BSL 1.1 terms
- Customize Additional Use Grant for Rosie
- Finalize FPP member exemption language
Documentation (Week 2-3)
- Create LICENSE file
- Write "Why BSL 1.1" explanation page
- Develop FAQ for users
- Prepare contributor agreement
Communication Plan (Week 3-4)
- Blog post announcing license and rationale
- Proactive outreach to potential users
- Address concerns and questions transparently
GitHub Release (Week 4)
- Publish Rosie source code
- Include clear licensing documentation
- Enable community contributions
Monitor and Iterate (Ongoing)
- Track community response
- Grant strategic exemptions as appropriate
- Adjust Additional Use Grant if needed

Conclusion

Business Source License 1.1 enables FPP to:

Build trust through transparency (source-available)
Protect cooperative member value (prevents exploitation)
Ensure sustainable development (revenue generation)
Commit to open source future (automatic conversion)
Align with cooperative principles (members benefit)

This is not choosing proprietary over open source. This is choosing sustainable cooperative development over exploitation by well-funded corporations.

The choice is:

BSL 1.1: Transparent, community-driven, eventually open source, financially sustainable
Pure Open Source: Transparent, community-driven, already open source, financially vulnerable to exploitation

For a cooperative committed to long-term sustainability and member benefit, BSL 1.1 is the responsible choice.

Recommended Board Motion:

"The FPP Governing Board approves the use of Business Source License 1.1 for Rosie, with a 4-year Change Date to Apache 2.0, an Additional Use Grant preventing competing hosted services, and an exemption for FPP members. This license protects cooperative member value while maintaining source transparency and ensuring an open source future."

Questions or Discussion: [Contact Information]

Supporting Materials: