What about "fair source with a proprietary shell"?

[Dieterbe]

PowerSync does something interesting: they have a core product ("PowerSync Open Edition") which is FSL licensed, and a proprietary (closed) shell around it ("PowerSync Cloud & PowerSync Enterprise Self-Hosted Edition")

This is effectively a blend of open core & FSL, more restrictive than pure open core, and more restrictive than pure FSL.
I've tried to explain this on my blog ; their implementation is the top right variant on this diagram

To be clear: this is not a value judgement towards PowerSync and how they chose to license their software, that's up to them. What I want to convey here is that I see ambiguity and am looking for alignment on the terms that we're trying to promote.

Now, I have 2 questions:

1. is this full setup something that can be considered "Fair Source", or should it only be the "core" open edition that should be referred to as fair source? Most (or all?) other companies that have come out in support of fair source seem to apply a fair source license to all of their software, or I am missing any? please share any more examples if you know of any.
2. perhaps a setup like this could be called "Fair Core"? Currently the FCL describes itself as "Fair Core" which doesn't make sense to me so i created this ticket. Should the Fair Source website mention anything about "Fair Core"? it's a bit weird that right now the FCL website introduces this term.

[Dieterbe]

relevant: this tweet by @fairsrc claiming "closed-source for software stuck in the past"

[ezekg]

In PowerSync's case, in my personal opinion, it should be considered Fair Core since only the core is available under a Fair Source license. This is because the enterprise edition is closed-source and does not undergo DOSP. Like I mentioned in Keygen's case, it's also considered Fair Core, since the enterprise edition is proprietary, although it's public and undergos DOSP. I think it's fine for there to be different ways to accomplish Fair Core, though do I wish all paths would somehow undergo DOSP.

But like I said in our other linked conversation Fair Core is still Fair Source, just like Open Core is still Open Source. So it's fine for both of us to call our software Fair Source, even though in a strict sense, they're Fair Core.

Maybe we can thoughtfully define Fair Core? But in a simple sense, it's as you've described in your diagram: a Fair Source core with additional proprietary features that may be public and may undergo DOSP.

[Dieterbe]

Fair Core is still Fair Source, just like Open Core is still Open Source

I don't agree with this personally, and also don't think the community agrees. the community has demonstrated a particular sensitivity to using "open source" broadly.

Open Core is a model that includes an Open Source component, you could say it's "based on", but not "is". Treating the fair core<->fair source relationship in this same way makes it more intuitive to newcomers to FS/FC. I also would suggest not diluting the "fair source" term this way.

[ezekg]

I don't agree with this personally, and also don't think the community agrees. the community has demonstrated a particular sensitivity to using "open source" broadly.

I very much disagree. Is GitLab open source? No, it's actually open core. Is Plausible open source? No, it's actually open core. Is Cal.com open source? No, it's actually open core. Is Posthog open source? No, it's actually open core. Is Sidekiq open source? No, it's open core. See where I'm going with this? Yet, everybody I know would consider these projects open source.

Edit: I don't like my terse tone here — albeit unintentional — but I'm leaving it for posterity. Sorry. This is a better attempt at communicating the above: https://news.ycombinator.com/item?id=41505184.

[Dieterbe]

Another Datapoint ... David Cramer on X:

I won't support any convo where we suggest Open Core is Open Source. (...) That's why we built the FSL, why built Fair Source

Source : https://x.com/zeeg/status/1833992294950994230?t=4cOKywmA8Efw_pTTcMWJSg

[ezekg]

More conversation from HN that same day: https://news.ycombinator.com/item?id=41503806

Specifically, here are my thoughts wrapped up, quoting @dcramer

I definitely would never call GitLab Open Source. [...] Sidekiq is actually how I think the world should work: its open source, and then they sell Sidekiq Pro. One is Open Source, one isnt.

I guess this is where I get hung up on this topic. To me, there's no real distinction between Sidekiq's open-source core and proprietary features vs GitLab's. One has their proprietary code closed-source, while the other has it source-available in a monorepo. Functionally though, I don't see the real distinction. If Sidekiq can call itself Open Source by you, then why can't GitLab? They're both doing the same thing in the end, if you really reduce it down to its core (pun intended?).

I think we had a similar discussion before Fair Source launched i.r.t. ELv2 sharing some similarities here. I argued ELv2's license keys are yet another way of accomplishing the same thing, just differently: separating proprietary code from the core (ignoring the non-compete for the sake of this conversation).

I'm not trying to start a holy war, but that comment of mine has a lot of upvotes. I think devs consider the projects in question Open Source… and yet also Open Core. The maintainers sure do, and the OSI-zealots — outside of OSI itself — haven't attacked them for calling their projects Open Source as far as I can find — so what gives?

There's a disconnect somewhere.

I think it ultimately comes down to philosophy, and it's a much more gray area than OSS <> source-available.

I feel like some don't consider Open Core's "core" Open Source, because the "core" is arbitrary — there's no bright line that says "90% of valuable features need to be part of the core otherwise it's not Open Source." And I think we've seen, e.g. with Elastic, that companies can abuse this to their advantage. As a counter, there's Cal.com that only puts real enterprise features outside their "core." This view is very… arbitrary. And I feel it loses some consistency and becomes hand-wavy — opinion-based.

Others don't care as much about ranking the usefulness of the "core" — some Open Source projects are useless, too, after all. I think this is more of where I sit. But I take it a step further as well, I think, because I don't care how companies separate "core" from "proprietary" at all — to me, if it's functionally the same — be it separate source-available repo, private repo, monorepo under dual license, license keys, etc. — it's still Open Core to me, and the core is still Open Source to me. Why wouldn't it be? It's under an OSI license. I can strip out the proprietary code if I wanted, exactly like GitLab does for it's GitHub mirror.

I think I have a unique perspective on this, as I've been using the term "Fair Core" to describe Fair Source through my lens of Open Core. However, I realize this might not resonate with others who share @dcramer's perspective, like you, @Dieterbe, and it has resulted in some confusion on your end, and ultimately this issue and keygen-sh/fcl.dev#3.

I'm completely fine dropping the term "Fair Core" to avoid any confusion, since I think I started using that term and building the FCL site before we rewrote the Fair Source Definition to include more broad "restrictions."

There multiple sides here, and personally I don't think either side is necessarily wrong. 😅