-
Notifications
You must be signed in to change notification settings - Fork 14
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
What about "fair source with a proprietary shell"? #53
Comments
relevant: this tweet by @fairsrc claiming "closed-source for software stuck in the past" |
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. |
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. |
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. |
Another Datapoint ... David Cramer on X:
Source : https://x.com/zeeg/status/1833992294950994230?t=4cOKywmA8Efw_pTTcMWJSg |
More conversation from HN that same day: https://news.ycombinator.com/item?id=41503806 Specifically, here are my thoughts wrapped up, quoting @dcramer
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. 😅 |
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:
The text was updated successfully, but these errors were encountered: