BSL 1.1 Usage Strategy - Presenter Notes

This page will expire in

Expires

Current Time

BSL 1.1 Usage Strategy - Presenter Notes

Purpose: Internal strategy guide for presenting Business Source License 1.1 to FPP Board

Related Documents:

Main 1-Pager - What board sees first
Full BSL 1.1 Proposal - Detailed rationale for follow-up

Core Strategy: Lead with Value, Follow with Protection

Phase 1: Initial Presentation (Focus on Rosie's Potential)

DO:

✅ Lead with "What is Rosie?" and business opportunity
✅ Emphasize immediate value (leaderboard, reputation, business inquiries)
✅ Show ecosystem diagram and revenue opportunities
✅ Highlight automatic cascading updates innovation
✅ Mention BSL 1.1 as "Cooperative Protection" feature (it's in the table)
✅ Keep licensing as ONE feature among many

DON'T:

❌ Lead with licensing discussion
❌ Apologize for or defend BSL 1.1 unprompted
❌ Compare to open source unless asked
❌ Get into legal details in initial presentation
❌ Act defensive about the choice

If No One Asks About BSL:

Perfect! They understood it as a feature
Continue with value proposition
Mention in closing: "Happy to provide detailed licensing rationale if helpful"

Phase 2: When Board Asks About BSL 1.1

Expected Questions & Responses

Question 1: "What is Business Source License?"

Your Response (30 seconds):

"BSL 1.1 is a source-available license that provides transparency while protecting cooperative value. The code is publicly viewable and auditable - critical for our trust mission. It prevents hyperscalers like AWS or Google from offering competing managed services while contributing nothing back. After 4 years, it automatically converts to fully open source under Apache 2.0.

Think of it as 'Cooperative Source Licensing' - members benefit from the value they create, rather than external corporations exploiting free labor."

Key Points:

✅ Source-available = transparent
✅ Protects cooperatives from exploitation
✅ Automatically becomes open source
✅ Aligns with cooperative values

Question 2: "Why not just use MIT or Apache 2.0?"

Your Response (45 seconds):

"Pure open source like MIT or Apache allows anyone - including well-funded hyperscalers - to offer competing services without contributing back. We've seen this repeatedly:

ElasticSearch had to switch from Apache to SSPL after AWS launched competing service

MongoDB switched licenses after AWS DocumentDB captured their market

Redis moved to dual licensing after AWS ElastiCache

HashiCorp just switched Terraform to BSL 1.1 in 2023 for the same reasons

These companies were reactive - they built communities, then had to change licenses and upset users. We're being proactive. BSL 1.1 lets us sustain development and ensure FPP members benefit, not Amazon shareholders.

I have a detailed proposal document with all the industry examples if you'd like to review."

Key Points:

✅ Industry precedent (reactive license changes are worse)
✅ Protects sustainability
✅ We're being proactive, not reactive
✅ Offer detailed document for follow-up

Question 3: "Doesn't this contradict our open/transparent values?"

Your Response (30 seconds):

"Not at all. Transparency and permissive licensing are different things. BSL 1.1 provides full transparency:

Source code is public on GitHub

Anyone can read, audit, fork, improve

Community can contribute (changes flow back)

Automatically becomes Apache 2.0 open source after 4 years

The only restriction is: don't use our code to compete with us as a managed service. That's not limiting transparency - that's protecting the cooperative from exploitation."

Key Points:

✅ Transparency ≠ Unlimited commercial use
✅ Source is fully visible and auditable
✅ Path to full open source guaranteed

Question 4: "Won't this hurt adoption?"

Your Response (45 seconds):

"No, BSL 1.1 doesn't limit legitimate adoption. Here's who CAN use Rosie:

✅ All FPP members - unrestricted use

✅ Organizations for internal deployment

✅ Service providers using it for their clients

✅ Researchers and educators

✅ Anyone contributing improvements

The only restriction is competing hosted services. And the evidence shows BSL projects thrive:

MariaDB: 5+ million deployments

CockroachDB: thousands of enterprise customers

Sentry: 100,000+ organizations

HashiCorp: Terraform adoption continues post-BSL

Adoption comes from value, not licensing permissiveness. If Rosie solves real problems, people will use it."

Key Points:

✅ BSL doesn't limit legitimate use
✅ Industry examples show strong adoption
✅ Value drives adoption, not license

Question 5: "What about contributors? Will people still contribute?"

Your Response (30 seconds):

"Yes, and we have evidence. Sentry has 30,000 GitHub stars and 500+ contributors under BSL. CockroachDB has 25,000 stars and active community. Contributors participate because:

Source is visible and forkable (same as open source)

Their contributions will be fully open source in 4 years

Impact and reputation matter more than license

Self-interest - improvements benefit their own usage

Plus, unlike traditional open source where contributors work for free, we REWARD contributors with Return on Contributions, reputation, and potential licensing revenue. That's more aligned with cooperative values."

Key Points:

✅ BSL projects have active communities
✅ We reward contributors (better than free labor)
✅ Cooperative model > traditional open source

Question 6: "Can we change the license later if this doesn't work?"

Your Response (20 seconds):

"Yes! BSL 1.1 provides flexibility:

It automatically converts to Apache 2.0 after 4 years

We can manually convert earlier if the board decides

BSL → Open Source is easy

Open Source → BSL is nearly impossible (requires all contributor agreement)

Starting with BSL preserves options. Starting with MIT eliminates them forever."

Key Points:

✅ Built-in flexibility
✅ Can convert earlier if needed
✅ Preserves future options

Phase 3: Handling Objections

Strong Objection: "This feels like a proprietary license"

Your Response:

"I understand the concern. Let me clarify the difference:

BSL 1.1:

✅ Source code is public

✅ Anyone can audit, fork, improve

✅ Community contributions accepted

✅ Automatically becomes Apache 2.0 (open source)

✅ Non-production use is unrestricted

Proprietary:

❌ Source is secret

❌ No community contributions

❌ Never becomes open source

❌ No forking, no auditing

BSL 1.1 is 'open source with a 4-year protective period.' It's not proprietary - it's cooperative protection.

Think of it this way: Would we rather have FPP members benefit from Rosie, or watch AWS build a managed service and capture all the value while we get nothing? That's the choice."

Follow-up if still resistant:

"I respect your concern about values. Can I ask: how would you suggest we prevent hyperscalers from exploiting our work? ElasticSearch, MongoDB, and Redis all started with permissive licenses and regretted it. What's our strategy to avoid their fate?"

Let them think about it. They likely won't have a good answer.

Moderate Objection: "Can we start with open source and switch if needed?"

Your Response:

"Unfortunately, that's the hardest path. Here's why:

Switching FROM open source TO BSL:

Requires agreement from every contributor (impossible if community is large)

Community backlash (feels like 'bait and switch')

ElasticSearch and MongoDB faced this - very painful

Starting WITH BSL:

No contributor agreement issues (it's clear from day one)

Community knows the terms upfront (no surprises)

Can convert to open source anytime (easy, one-way door)

Plus, by the time we realize we need protection, AWS might already be launching their competing service. We've seen this movie before - let's not repeat others' mistakes."

Philosophical Objection: "Open source is fundamental to our mission"

Your Response:

"I agree that transparency is fundamental to our mission. But let me challenge: is unlimited commercial exploitation also fundamental?

Our mission is building trust infrastructure. BSL 1.1 supports that:

✅ Source transparency builds trust (anyone can audit)

✅ Cooperative sustainability builds trust (we'll be here long-term)

✅ Fair contributor rewards build trust (people prosper from value they create)

Traditional open source creates problems:

❌ Contributors work for free while corporations profit (exploitation, not cooperation)

❌ No sustainable funding model (we struggle to pay developers)

❌ Hyperscalers can commoditize our work (we become irrelevant)

Which better serves our mission:

Transparent source code + sustainable cooperative + member benefits? (BSL 1.1)

Transparent source code + financial vulnerability + corporate exploitation? (MIT/Apache)

I'd argue BSL 1.1 is MORE aligned with cooperative values than pure open source."

Phase 4: Closing & Next Steps

If Board Seems Receptive:

Your Closing:

"I'm glad this resonates. BSL 1.1 lets us be transparent, community-driven, and sustainable. Here are the next steps:

I'll send the detailed BSL proposal document for your review

We can have legal counsel review the terms

If you approve, we'll publish Rosie source code under BSL 1.1 with clear documentation

We'll proactively communicate the reasoning to potential users

This protects FPP and our members while maintaining our commitment to transparency and eventual open source. I'm confident this is the right approach."

If Board Wants to Discuss Further:

Your Closing:

"I appreciate your thoughtful questions. This is an important decision. Here's what I suggest:

I'll send the full BSL proposal document with all the details

You can review the industry examples and cooperative alignment arguments

Let's reconvene in [timeframe] to make a decision

I'm confident BSL 1.1 is the right choice, but I want you to be fully comfortable. Happy to answer any questions that come up."

If Board is Resistant:

Your Closing:

"I hear your concerns. Let me suggest this:

Review the detailed proposal document I'll send

Consider the alternatives (I've analyzed GPL, SSPL, Fair Source, etc.)

Think about what happened to ElasticSearch, MongoDB, and Redis

Ask yourselves: how do we prevent hyperscaler exploitation?

If after that you still prefer traditional open source, we can discuss compromise positions:

Shorter Change Date (3 years instead of 4)

More permissive Additional Use Grant

Trial period (start with BSL, re-evaluate in a year)

But I want to be clear: I'm not comfortable launching with MIT or Apache. The risk of exploitation is too high, and I've seen this movie too many times. BSL 1.1 is the minimum protection I believe we need."

Be willing to walk away if necessary. Your conviction will be respected.

Tactical Considerations

Timing

WHEN to introduce BSL in conversation:

❌ First 5 minutes - too early, licensing dominates
✅ After value proposition - board understands potential first
✅ When they ask - they're ready to hear it
✅ In "Cooperative Protection" table entry - subtle introduction

HOW LONG to discuss:

Initial mention: 30 seconds
If asked: 2-3 minutes per question
Deep dive: Only if board wants it
Don't belabor unless they're concerned

Tone

DO:

✅ Be confident - you've researched this thoroughly
✅ Be factual - cite industry examples
✅ Be mission-focused - connect to cooperative values
✅ Be transparent - acknowledge trade-offs honestly
✅ Be flexible - willing to adjust terms within reason

DON'T:

❌ Be defensive - it's a thoughtful choice, not a compromise
❌ Be apologetic - you're protecting their interests
❌ Be absolutist - some flexibility is fine
❌ Be dismissive - listen to concerns genuinely
❌ Be complicated - use simple language

Body Language & Delivery

When mentioning BSL:

Maintain steady eye contact
Open body language (not crossed arms)
Speak clearly and confidently
Don't rush through it (that signals discomfort)
Pause after explaining (let it sink in)

When handling objections:

Nod to acknowledge concern
Don't interrupt
Lean forward slightly (engaged listening)
Respond calmly and factually
Use phrases like "I understand" and "Great question"

Key Talking Points - Quick Reference

The Elevator Pitch (30 seconds)

"BSL 1.1 is source-available licensing that ensures transparency while preventing hyperscaler exploitation. Code is public and auditable. Anyone can use it except to compete with us as a managed service. After 4 years, it automatically becomes fully open source. This is cooperative protection - members benefit from the value they create."

The Industry Reality (30 seconds)

"ElasticSearch, MongoDB, Redis, and HashiCorp all started with permissive open source. All were exploited by AWS/Google/Microsoft offering competing services. All had to switch licenses reactively, upsetting communities. We're being proactive. BSL 1.1 from day one avoids that pain."

The Cooperative Alignment (30 seconds)

"Traditional open source says 'work for free while corporations profit.' BSL 1.1 says 'contribute to the cooperative, members prosper, eventually fully open.' We reward contributors with Return on Contributions and potential licensing revenue. That's true cooperative economics, not exploitation."

The Transparency Answer (20 seconds)

"Transparency and permissive licensing are different. BSL provides full transparency - source is public, anyone can audit. The only restriction is competing services. That's not limiting trust - that's protecting sustainability."

The Adoption Answer (20 seconds)

"MariaDB: 5M+ deployments. CockroachDB: thousands of enterprise customers. Sentry: 100K+ organizations. HashiCorp: Terraform adoption continues post-BSL. Adoption comes from value, not licensing permissiveness."

The Flexibility Answer (15 seconds)

"BSL automatically converts to Apache 2.0 after 4 years. We can convert earlier if needed. BSL → Open Source is easy. Open Source → BSL is impossible. Starting with BSL preserves options."

Compromise Positions (If Needed)

Option 1: Shorter Change Date

Current: 4 years to Apache 2.0 Compromise: 3 years to Apache 2.0

Your position:

"I'm comfortable with 3 years instead of 4 if that addresses your concerns. That's still enough time to establish market position, and it shows our commitment to open source."

Option 2: More Permissive Additional Use Grant

Current: No competing hosted services Compromise: Allow non-profit competing services

Your position:

"I'm open to exempting non-profit organizations from the competing use restriction. For-profit hyperscalers are the real concern. Non-profits aligned with our mission can compete."

Option 3: Generous Strategic Exemptions

Current: FPP members exemption only Compromise: + Other cooperatives + Academic institutions

Your position:

"I'm happy to grant blanket exemptions to other cooperatives and academic institutions. They're aligned with our values and unlikely to exploit us. The restriction is really about AWS, Google, Microsoft."

Option 4: Trial Period

Current: Commit to BSL 1.1 Compromise: BSL 1.1 for 1 year, re-evaluate

Your position:

"We can start with BSL 1.1 and commit to re-evaluating in one year. If it's clearly not working - harming adoption, preventing contributions, whatever - we can reconsider. But I'm confident it will work well."

Your Hard Lines (Don't Compromise)

Non-negotiable:

❌ Will NOT launch with MIT or Apache 2.0 (too vulnerable)
❌ Will NOT allow hyperscalers unrestricted use (defeats the purpose)
❌ Will NOT make source code private (contradicts trust mission)

Willing to walk away if:

Board insists on permissive open source (MIT/Apache)
Board doesn't understand exploitation risk
Board prioritizes ideology over sustainability

Your conviction will be respected. Don't compromise on fundamentals.

Post-Presentation Follow-Up

If Approved:

Email within 24 hours:

Subject: BSL 1.1 Approval - Next Steps

Thank you for approving BSL 1.1 for Rosie. I'm excited to move forward with this approach that protects our cooperative while maintaining transparency.

Next steps:

Legal review of BSL terms (Week 1-2)

Documentation and FAQ creation (Week 2-3)

Public announcement blog post (Week 3-4)

GitHub publication under BSL 1.1 (Week 4)

I'll keep you updated on progress. Here's the full BSL proposal document for your records: [link]

If Deferred for Review:

Email within 24 hours:

Subject: BSL 1.1 Proposal Document + Supporting Materials

Thank you for the thoughtful discussion about Rosie's licensing. As promised, here's the detailed BSL 1.1 proposal document: [link]

Key sections for your review:

Industry examples (ElasticSearch, MongoDB, HashiCorp)

Alignment with cooperative principles

Risk comparison (BSL vs pure open source)

Alternatives considered

Supporting materials:

BSL 1.1 Full Text

FOSSA BSL Analysis

HashiCorp BSL Announcement

Happy to discuss any questions that come up. I'm available for a follow-up call whenever works for you.

If Strong Resistance:

Email within 24 hours:

Subject: BSL 1.1 Discussion - Thank You + Clarification

Thank you for the candid discussion about licensing. I appreciate your concerns about open source and cooperative values.

I want to clarify my position: I'm not opposed to open source philosophically. I'm concerned about exploitation practically. BSL 1.1 IS a path to open source - just with a 4-year protective period.

The alternative - launching with MIT/Apache - leaves us vulnerable to the exact fate that befell ElasticSearch, MongoDB, and Redis. I've watched this happen too many times.

I'm attaching the full proposal document for your review. If after reading it you still prefer traditional open source, I'd like to understand your strategy for preventing hyperscaler exploitation.

Let's schedule a follow-up call to discuss further. I'm committed to finding an approach we're all comfortable with, but I cannot in good conscience launch with no protection.

Mental Preparation

Before the Presentation:

Review:

Main 1-pager (your delivery)
Industry examples (ElasticSearch, MongoDB, HashiCorp)
Cooperative principles alignment
Your compromise positions

Mindset:

You've done the research
You're protecting their interests
You're willing to listen but firm on fundamentals
BSL 1.1 is the responsible choice

Visualize:

Confident delivery
Thoughtful responses to questions
Board nodding in agreement
Successful outcome

During the Presentation:

Stay:

Calm
Factual
Mission-focused
Confident but not arrogant

Remember:

Pause after questions (thoughtful, not reactive)
Acknowledge concerns genuinely
Use industry examples to support points
Connect back to cooperative values

After the Presentation:

Regardless of outcome:

Thank them for their time and consideration
Offer to provide additional information
Commit to following up promptly
Maintain positive relationship

If approved:

Express appreciation
Outline next steps clearly
Deliver on timeline commitments

If deferred:

Respect their need for time
Provide requested materials promptly
Stay available for questions

If rejected:

Understand their reasoning
Propose compromise if appropriate
Be willing to walk away if necessary (maintain integrity)

Success Metrics

Signs You're Succeeding:

✅ Board members nodding during explanation
✅ Questions are clarifying, not challenging
✅ Concerns are about implementation, not concept
✅ Board references cooperative values positively
✅ Someone says "That makes sense"
✅ Discussion moves to next steps

Signs You Need to Adjust:

⚠️ Multiple board members look confused
⚠️ Same objection raised repeatedly
⚠️ Discussion stuck on ideology vs pragmatism
⚠️ Body language shows resistance (crossed arms, frowns)
⚠️ No questions asked (either bored or decided)

If struggling:

Slow down
Ask: "What concerns you most about this approach?"
Listen actively
Address root concern directly
Offer to table and provide written details

Remember

You're Not Selling Out:

BSL 1.1 is MORE aligned with cooperative values than pure open source
You're protecting members from exploitation
You're ensuring sustainable development
You're guaranteeing open source future

You're Not Alone:

MariaDB, CockroachDB, Sentry, HashiCorp all chose BSL
Industry trend is moving away from permissive open source
ElasticSearch, MongoDB, Redis learned the hard way
You're in good company

You're Being Responsible:

Proactive protection is better than reactive scrambling
Sustainability matters for long-term mission success
Transparency doesn't require exploitation vulnerability
Cooperative values include protecting member value

Trust Your Research:

You've analyzed alternatives
You've considered cooperative alignment
You've studied industry precedents
You've made the informed, responsible choice

Good luck! You've got this. 🎯

Quick Access Links: