"Fair Core is to Fair Source what Open Core is to Open Source." doesn't make sense to me

[Dieterbe]

The FCL is basically the FSL + a clause to avoid circumventing license key checks.

It doesn't cover any closed/proprietary code, so the comparison to open core is rather awkward.
In fact, i find that the FSL itself (and by extension the FCL, but only to the same extent and for the same reasons unrelated to the key checks) can be reasonably compared to Open Core (as explained here)

Fair.io says "A variant of FSL that includes license key support. Consider it when monetizing self-hosted software with commercial features." which seems a lot more appropriate.

[ezekg]

I like the tag line. It's an attempt at driving home a new term, "Fair Core", which is subtly different from pure "Fair Source." But in the same way that an Open Core project is still Open Source, a Fair Core project is still Fair Source.

Fair Core is the only variant of the Fair Source licenses that you can use to implement an Open Core-style model, e.g. you can't use an Open Core-style model strictly under FSL, because you'd need to dual license under a commercial/enterprise license that undergoes DOSP (which doesn't exist yet) or you risk somebody forking your project and using the commercial features for free, or you'd need to have the commercial features be closed-source which I don't particularly like.

So the entire point of the FCL is to protect commercial features while keeping the entire code base — the free and commercial parts — licensed under a single license which undergoes DOSP.

Maybe the intent here can be clarified? I thought the tagline was pretty clear but I have a lot of context.

[ezekg]

I briefly touched on how licensing under the ELv2 (and so the FCL) is "open core"-style here: fairsource/fair.io#14 (comment)

[In] the case of ELv2 [and FCL], you can modify any part of the codebase not protected by a license key without limitation, you can redistribute those modifications without limitation, and you can use it with the only limitation being a non-compete (just like FSL). So it's literally a non-compete Open Core but instead of the commercial features being separately licensed under different terms and in various file locations (e.g. under an ee/ directory) [or entirely closed source], the commercial features are inline throughout the codebase gated by license key functionality.

Instead of asking "is this file in x directory?" you ask "is this code protected by a license key?" and if the answer is no, it's essentially open source for 99.999% of users and you can do what you want with it, as long as you're not competing via SaaS.

ELv2 [and FCL] really shines for closed source projects going fair source, since it doesn't require the codebase to be reorganized in order to open it up (like in my case with Keygen). There's huge risk in that reorganization due to code churn. So it can encourage adoption of fair source in some scenarios, like mine.

So FCL is Fair Core, the same way a project that is dual-licensed or with a closed-source shell would be Fair Core. The FCL simply uses license keys to segment features, instead of separate license terms. Much simpler, imo.

[Dieterbe]

So what FCL (vis-a-vis FSL) has in common with Open core (vis-a-vis Open Source) is that it's a method to add protection around commercial features in an otherwise "freely modifiable" codebase.
But it doesn't employ any of the techniques otherwise associated with Open Core (multi repo, multi license, proprietary code). Therefore I understand what you're accomplishing, i just think the comparison is quite the mental leap that may not be obvious to many.

i think it may also be confusing to use the term "fair core" to mean both fair source + proprietary shell (as discussed here) as well as fair source with license key checks. if we were to use the term "fair core" only for the former, people checking out fair source / fair core would have an easier time understanding how this all fits together.

[ezekg]

Yes. But there can be no comparable model to the ELv2/FCL under Open Core, because there's no OSI-approved license that could protect proprietary features (because doing so would break the 4-freedoms of OSS), which is why people use a commercial license for code under ee/, or make the proprietary features closed source. That's my whole point.

It's not confusing the term — that's literally the definition of the term. It's just a different way of doing the same thing: protecting the proprietary parts of a code base from usage until an additional license is granted — be it a key, terms, etc. 🙂

At its core, there is no difference. It's the same thing just done differently.

[ezekg]

To add, I thought the "How is the FCL different from Open Core?" FAQ directly addresses this.

Maybe it could be improved?