Normalize software sharing between closed-source and Open Source

[dcramer]

Update

from @chadwhitacre

The Story So Far

A year and change ago, Sentry bought Codecov. Eight months ago, we published it under BUSL-1.1. Our headline said "Codecov is now Open Source," which set off a vigorous discussion about the meaning of the term Open Source, out of which emerged this proposal from @adamhjk:

I think the way forward here is to make what I suspect is a loose confederation of folks using non-compete licenses to actually get together and draft their own set of values. To then brand that. And stand behind it proudly.

We started a repo at getsentry/loose-confederation with discussions about overall goals as well as brand naming. We also started writing a new license, FSL, which we shipped five months ago. The loose-confederation repo has been downscoped to focus on that.

Meanwhile, Software Commons emerged as a strong brand for something, but not for what we originally set out to do based on Adam's suggestion. Software Commons is now evolving into an attempt to solve the sustainability crisis in Open Source; you can join that conversation over here. The present ticket was brought from what is now the fsl.software repo to this here new repo, which is for a website called howtoshare.software.

Our Purpose Here

From @dcramer on getsentry/fsl.software#2:

The intent here is to normalize a category of software which provides more freedom than closed source, and more freedom than typical source-available software. It should not diminish the value of FOSS (or OSI's definition of "Open Source"), but should also not be overly confusing to end-users, and not include prejudice.

I've updated the issue title based on this intent: "Normalize software sharing between closed-source and Open Source." The site currently live at howtoshare.software pursues this intent by defining levels of source availability. I propose that we use this issue to see if we can converge on details under this general approach.

---

Original

from @dcramer

Let's educate the broader open source community on where these style of licenses make sense. There's far too many conversations where Open Source is one giant bucket of things, but thats not how the world actually operates.

For example, if you're building a library, FSL almost certainly should not be used (and frankly, non-compete in general should be avoided). Obviously thats our opinion, but given this entire thing is our opinion thats ok, and it doesnt need stated that the team has a lot of historical domain experience in mainstream open source. I would go so far as to say we should suggest libraries be put under a fully permissive license, but we should run the exercise of the core licenses and which models they might work best in (permissive, copyleft, non-compete, and maybe even closed source/proprietary?).

We should also not exclusively tie it to the type of code, but the organizational and/or business model in general.

[adamhjk]

I think you can generally point to the trend within FOSS in general for guidance on when restrictions make more sense. Today, I tend to think of it like:

Building Blocks / Libraries

Generally under permissive licenses: MIT, Apache2, LGPL.

End user software (non commercially backed)

Permissive licenses, weak copyleft (MPL), strong copyleft (GPL).

End user software (commercially backed by a single strong vendor)

Proprietary licenses, Permissive licenses + Proprietary ("tight" open core), Permissive Licenses + Proprietary SaaS ("weak" open core), Non-compete licenses (FSL)

End user software (commercially backed by a consortium/foundation)

Permissive licenses, Permissive licenses + Proprietary SaaS, full proprietary enclosure

As for when to use which - I'll leave that up to y'all. :)

[dcramer]

Something I want to note here: Chrome is Open Core, but not like many of your typical commercial projects. I've never had that come up in conversation, but I want to make sure we consider that when we're thinking about how we describe things, as to me its an unsung hero of the model.

[chadwhitacre]

From @WisTex in getsentry/fsl.software#34:

Re: https://softwarecommons.com

Are the categories supposed to be license types or business models?

Instead of trying to combine both into one classification list, perhaps we classify software using both.

Examples:

Core Licensing: Open Source - Copyleft
Addon Licensing: Proprietary
Business Model: Freemium (e.g. Open Core / Premium Addons)

Core Licensing: Open Source - Copyleft
Dual Licensing: Available
Addon Licensing: Varies
Business Model: Support Services, Customization & Development Services

Core Licensing: Open Source - Permissive
Addon Licensing: Open Source - Permissive
Third-Party Addon Licensing: Varies
Business Model: Donations & Contributions

Licensing: Public Domain
Business Model: Gift to Public (i.e. does not accept donations)

Mix and match licensing and business model as appropriate.

Then:

@dcramer I think this might be similar to what you were talking about with distribution models, etc.?

Yes, separating the decision points on business, distribution, contribution models
we should articulate the ecosystem, the decision points, examples of those decision points, etc
basically it needs to be trustable resource

[chadwhitacre]

I've done a bunch of shenanigans to hopefully get conversations in the right place. This issue now lives in the repo for howtoshare.software. I've written a long update in the issue description for context if anyone is lost.

[chadwhitacre]

Picking up from @MattiSG at getsentry/fsl.software#2 (comment):

finding sustainable business models in open-source for initial vendors through increased friction to reuse

This narrative framing is not adequate to encompass the full range of relevant observable phenomena.

Yes, HashiCorp did betray the community when they relicensed Terraform from an Open Source project to a BUSL-1.1-licensed product. It was a rug pull. The community's response in creating a viable fork, OpenTofu, is a shining example of the power of Open Source licensing to forestall enclosure of software as an information good. This is the system "working as intended," the community routing around the misbehavior of HashiCorp when they "increased friction to reuse."

Consider movement in the other direction, though. Codecov was closed-source when Sentry bought it. Because of DOSP licensing under BSL/FSL, we were able to publish the source code, creating real benefits for users without jeopardizing our capacity to continue producing it. You used to have to pay to self-host Codecov. Now you don't. The same is true for AnswerOverflow, GitButler, and CodeCrafters, which have all gone from closed-source to source available in the five months since we published FSL. In these cases, the companies in question have decreased "friction to reuse."

As @dcramer expressed in the quote at the top of this issue:

The intent here is to normalize a category of software which provides more freedom than closed source, and more freedom than typical source-available software. It should not diminish the value of FOSS (or OSI's definition of "Open Source"), but should also not be overly confusing to end-users, and not include prejudice.

This is behind how I've distinguished levels of source availability in the first draft of howtoshare.software.

open-source software that has democratic governance

I think differences in governance are worth having in mind when we look at software sharing practices. I almost wonder if we don't need to update our model of the "freedoms" of software. On the one hand the existing freedoms are poorly structured, on the other hand it may be worthwhile to directly incorporate "freedom to participate in governance." 🤔

[chadwhitacre]

In a67fef2...844028e I've renamed what was Open Product to Fair Source, and added back a modified Open Product as a fifth level. Why?

1. "Open" = Communal, Not Corporate

differences in governance

Picking up from our previous thread (one, two, three), and reframing in terms of governance: any application of "open" to efforts with corporate instead of communal governance—and yes, we need a fuller discussion of those concepts—will be seen as open-washing (see also: recent OpenAI disclosures).

2. "Fair" Has the Most Common Ground So Far

I've seen @ssddanbrown (ref.) and @mswilson (ref.) both indicate that Fair Source would be an acceptable term to describe Sentry, Codecov, GitButler, etc. I feel like the vibe in our internal Sentry chat has been more or less okay with "Fair" as a descriptor as well. I think it may be the least bad option, a fair compromise between interested parties. ;-)

3. "Fair" Has the Most External Momentum So Far

Looking at existing efforts, Fair Source License can fit: it's a specific instance of the Fair Source pattern. Maybe there's a slight risk of muddying the waters, but I don't think it's insurmountable. Otoh, Fair Code is basically saying what I think we want to say about Fair Source. That's also fine, imo; they can be synonyms. The story, then, is basically:

Fair Source encompasses a range of source available software sharing options for companies that want to grant some real freedoms while also protecting their business interests. Also sometimes called "Fair Code," the Fair Source License is one specific license in this category, which also includes BUSL, FSL, etc.

4. "Open Products" = Communal Fair Source(!)

Revisiting "Open Products," I want to reserve that term for software products with Fair Source licensing and communal governance. This is where the real innovation is, in my view. Firms are demonstrably better than Open Source communities at building consumer-grade software products, so let's take the firm-friendly licensing of Fair Source, and combine it with communally governed firms (i.e., cooperatives). This creates a new economic relation, wherein individuals have real control over their participation in the economic benefits of a successful product.

[MattiSG]

finding sustainable business models in open-source for initial vendors through increased friction to reuse

This narrative framing is not adequate to encompass the full range of relevant observable phenomena.
[…]
have all gone from closed-source to source available in the five months since we published FSL. In these cases, the companies in question have decreased "friction to reuse."

Just to clarify: I meant “increased friction to reuse” as compared to open-source licenses, not as compared to some existing state of affairs. FSL does add more friction to reuse than MIT. I don't think it's bad in the current context, I am acutely aware of the difficulty of getting an income from developing open-source software and I am also led to think that, lacking a government-provided solution, we need to find some middle ground.

[chadwhitacre]

Just to clarify: I meant “increased friction to reuse” as compared to open-source licenses, not as compared to some existing state of affairs.

Understood. For some examples, though, such as HashiCorp, the existing state of affairs was an Open Source license. That's why their move to BSL raised so many hackles (and rightly so!). For Codecov, GitButler, etc. the existing state of affairs was closed source, so the move to FSL was a decrease in friction. My hope is that having a comprehensive taxonomy of sharing can give us better language for reasoning about these cases together; that's the purpose of howtoshare.software.

I am acutely aware of the difficulty of getting an income from developing open-source software and I am also led to think that, lacking a government-provided solution, we need to find some middle ground.

I'm excited to work on this together! I think a blended approach is what will get us where we need to be. I love what Sovereign Tech Fund is doing, for example (here's a call I did with Fiona about six months ago). I see Software Commons as a FOMO-based complement to taxation-based approaches. Why not both! 🤷 😁