search

fairsource / fair.io

Fair Source is software sharing that is fair for companies and developers alike.
https://fair.io/
88 stars 5 forks source link

Launch Fair Source #14

Open chadwhitacre opened 1 month ago

chadwhitacre commented 1 month ago

Now that the logistics of transferring the GitHub org are complete (#9) and I've made contact with the Fair Code crew (#10), it's time to get Fair Source off the ground! 🙌

What is Fair Source?

Fair Source is our answer to @adamhjk's CTA:

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.

Fair Source is our fill-in-the-blank for “Codecov is now [__].”

Here's a Google Doc that we're sharing with the design team.

To Do

ezekg commented 1 month ago

I like this. I'll try to stay in the loop and change verbiage on Keygen to "fair source" when you're ready (from the cheeky "open, source-available" that seems to toe the line a bit too much according to a few people).

Are you going to fully merge https://faircode.io into this, or will it stay separate? You mentioned their "in the loop", but just curious as to what that actually meant (if you even know yet).

chadwhitacre commented 1 month ago

I like this. I'll try to stay in the loop and change verbiage on Keygen to "fair source"

Woo-hoo! Awesome! 😁

Re: Fair Code, there are few more details at https://github.com/fairsource/fair.io/issues/10#issuecomment-2085637607. @janober and I had a call and he is busy being a CEO, so he is happy to see someone else run with this. :) If all goes well we will see Fair Code fully merge into Fair Source! 🤞

chadwhitacre commented 1 month ago

Can we talk about outcomes? What outcomes are we trying to drive here?

Here's a sketch: 10 years from now basically every company shares their core products. Google Search. Facebook News Feed. Late majority, 80%+ of companies are using Fair Source (at least for new products). Starts with developer tools(?), expands from there.

Why? What are the values?

Sentry's values are user freedom and developer sustainability, which matches the first Fair Code principle, "Free and Sustainable." The rest there are: "Open but Pragmatic," "Community meets Prosperity," "Meritocratic and Fair." @dcramer talks about "access to technology and knowledge for developers."

What are the benefits?

  1. Knowledge. Individuals can read and learn from software that is shared (though probably not if they are employed at an upstanding competitor).
  2. Usage. Fair Source should allow some measure of software use, not just reading the code.
  3. Hackability. Fair Source should allow for modifying the software to suit ones needs.
  4. Contributing. Fair Source should allow for contributing modifications back to the producer.
  5. Transparency. Democracy dies in darkness, etc., etc.

🤔

chadwhitacre commented 1 month ago

Hmmm ... maybe Fair Source distinguishes between software producers and consumers. Fair Source producers grant consumers the right ("freedom") to:

  1. read,
  2. non-competitively run,
  3. modify, and
  4. share their modifications with the producer and with other consumers.

The delta with Free Software/Open Source is that it doesn't distinguish producer and consumer as strongly.

The delta with closed source is that it distinguishes producer and consumer more strongly.

chadwhitacre commented 1 month ago

Interesting Twitter exchange with ESR, led to a post "Widespread Use of a Fair Source Product."

chadwhitacre commented 1 month ago

Open Core - Open Source license on community edition, proprietary license on enterprise features.

Fair Core - Fair Source on community edition, proprietary license on enterprise features.

Keygen is Fair Core. Accurate, @ezekg?

chadwhitacre commented 1 month ago

I cleaned up the homepage and started driving traffic a bit.

Screenshot 2024-05-16 at 10 35 45 AM
ezekg commented 1 month ago

Open Core - Open Source license on community edition, proprietary license on enterprise features.

Fair Core - Fair Source on community edition, proprietary license on enterprise features.

Keygen is Fair Core. Accurate, @ezekg?

I'm not really sure how you'd categorize it using those 2 definitions. Keygen's entire code base is licensed under Elastic, which has a clause that allows license-key-gated features. So CE is licensed under Elastic, and EE is licensed under Elastic + a license key for those features. So I guess you're right i.r.t Fair Core, but the overloaded term for "license" seems ambiguous, i.e. license terms vs license key, because they're both under the same license terms — just Elastic has provisions for protecting certain parts of the code base from modification and use with a license key (where a license key allows use but not modification).

So would that mean any project using Elastic which used the license key provision in the license terms for additional features would be Fair Core, not Fair Source? Is that what you're thinking? Fine either way. I think it makes sense.

By the way, great rebuttal[^1] i.r.t. widespread use of "fair source."

[^1]: I was kind of taken back with that exchange (among others) with ESR on Twitter. I don't particularly enjoy how people on the other side seem so — for lack of a better term — arrogant (especially referring to this exchange). I wish we could all just work together, but they seem so vehemently against that. I personally still think the term "open source" needs to be a larger umbrella — but I digress (maybe I'll fight that battle another day). The "fair source" and "fair core" terms are a good enough compromise, even if the other side still hates us for it for some reason esoteric reason.

chadwhitacre commented 1 month ago

Elastic, which has a clause that allows license-key-gated features

Ah, interesting, okay. Hmmmm ... 🤔 Trying to synthesize the different real-world approaches, wrapping my head around each one. This helps, thanks.

ezekg commented 1 month ago

I think Fair Core is a fair term for projects licensed under the Elastic terms, since it's a Fair Source "core offering" with additional features granted by a license key. It's similar to Open Core, where some of the project is available for everyone, while the rest requires an additional agreement (a license grant, license key, payment, w/e).

chadwhitacre commented 1 month ago

Looking through Fair Code as a starting point, I see six licenses and 11 companies, but only 4 licenses are in use by the listed companies:

Now of course we also have:

My thought is that we should have some opinionated take on what licenses to promote. Something like:

I think we acknowledge BUSL and SUL (and maybe others?) but steer people towards the above. I think any future license we would recommend should go through SPDX inclusion first at a minimum.

SUL

SUL was based on ELv2. I'm not seeing in the announcement or discussion thread an explanation of the difference. Why was ELv2 insufficient? 🤔 Here's a gist with both, with minor formatting adjustments made in order to get a clean diff (below). Afaict SUL a) subtly modifies the limitations and b) removes the concept of license keys. IMO it is not sufficiently different nor sufficiently adopted (i.e., it's not in SPDX) to warrant top-tier promotion. I think we promote ELv2.

--- ELv2    2024-05-16 11:19:27
+++ SUL 2024-05-16 11:19:24
@@ -1,6 +1,6 @@
-# Elastic License
+# Sustainable Use License

-Version 2.0
+Version 1.0

 ## Acceptance

@@ -11,17 +11,15 @@
 The licensor grants you a non-exclusive, royalty-free, worldwide,
 non-sublicensable, non-transferable license to use, copy, distribute, make
 available, and prepare derivative works of the software, in each case subject
-to the limitations and conditions below.
+to the limitations below.

 ## Limitations

-You may not provide the software to third parties as a hosted or managed
-service, where the service provides users with access to any substantial set of
-the features or functionality of the software.
+You may use or modify the software only for your own internal business purposes
+or for non-commercial or personal use. 

-You may not move, change, disable, or circumvent the license key functionality
-in the software, and you may not remove or obscure any functionality in the
-software that is protected by the license key.
+You may distribute the software or provide it to others only if you do so free
+of charge for non-commercial purposes. 

 You may not alter, remove, or obscure any licensing, copyright, or other
 notices of the licensor in the software. Any use of the licensor’s trademarks
@@ -44,7 +42,7 @@

 You must ensure that anyone who gets a copy of any part of the software from
 you also gets a copy of these terms. If you modify the software, you must
-include in any modified copies of the software prominent notices stating that
+include in any modified copies of the software a prominent notice stating that
 you have modified the software.

 ## No Other Rights
@@ -55,11 +53,11 @@
 ## Termination

 If you use the software in violation of these terms, such use is not licensed,
-and your licenses will automatically terminate. If the licensor provides you
+and your license will automatically terminate. If the licensor provides you
 with a notice of your violation, and you cease all violation of this license no
-later than 30 days after you receive that notice, your licenses will be
+later than 30 days after you receive that notice, your license will be
 reinstated retroactively. However, if you violate these terms after such
-reinstatement, any additional violation of these terms will cause your licenses
+reinstatement, any additional violation of these terms will cause your license
 to terminate automatically and permanently.

 ## No Liability
@@ -85,9 +83,9 @@
 power to direct its management and policies by vote, contract, or otherwise.
 Control can be direct or indirect.

-"Your licenses" are all the licenses granted to you for the software under
-these terms.
+"Your license" is the license granted to you for the software under these
+terms.

-"Use" means anything you do with the software requiring one of your licenses.
+"Use" means anything you do with the software requiring your license.

 "Trademark" means trademarks, service marks, and similar rights.
chadwhitacre commented 1 month ago

I've started a Google Doc that I'll be using to coordinate with our design team (also linked in the description).

chadwhitacre commented 1 month ago

I connected over email with Elastic. They are not interested in participating directly in Fair Source at the moment, but they are more than happy for us to promote ELv2.

chadwhitacre commented 1 month ago

Sentry's Launch Week has been moved. The Fair Source launch is now scheduled for August 16.

chadwhitacre commented 1 month ago

Sentry's Launch Week has been moved again. The Fair Source launch is now decoupled from Sentry's Launch Week and we can ship as soon as we're ready.

chadwhitacre commented 1 month ago

Pitch to simplify through a single Fair Source License: https://github.com/fairsource/fair.io/issues/16.

chadwhitacre commented 1 month ago

Decision on #16 was to reticket #17 and proceed here as follows:

  1. Rename Functional Source License to Fair Source License.
  2. fair.io says:
    1. "Fair Source is a great way to meaningfully, safely share your company's core products."
    2. "Want to adopt Fair Source? Here's the playbook:
      1. apply Fair Source License,
      2. audit for secrets,
      3. make it public,
      4. announce 'Foo is now Fair Source'
    3. "FAQ"
      1. "What if I want to monetize self-hosted? Fair Source License is not for you, look into ELv2."
      2. "What if I like copyleft? Fair Source License is not for you, look into SSPL."
      3. "Can I still call it Fair Source if I use ELv2 or SSPL? Yes, of course. Any good faith attempt to meaningfully, safely share your company's core products counts as Fair Source."
      4. etc.

Refer to the Google Doc for further iteration.

chadwhitacre commented 3 weeks ago

Decision taken to not block launch on renaming FSL to Fair Source License. More detail at https://github.com/fairsource/fair.io/issues/17#issuecomment-2155449081 ff. We still intend to promote FSL as the flagship Fair Source license (and FCL as secondary if/when it lands, #17), and may revisit the question of renaming post-launch.

chadwhitacre commented 3 weeks ago

Bringing this back here:

We have to help people understand all the facets of open source and most importantly, the access to software.

If you distill this idea into its most fundamentals it’s about access. We believe giving people software, access to code, it can change everything. It was that for me, and I believe everyone in this group.

My primary goal is to recreate that access, and the goal. The internet has gotten much bigger, but not more difficult. We have an opportunity to keep it open.

@dcramer The common discourse is around freedom to read, run, modify, and distribute software. Is "access" simply a synonym for "software freedom," or is there some nuance I'm missing, or ... ?

chadwhitacre commented 3 weeks ago

Posting some additional guidance from @dcramer culled from last week's convos in private Slack:

i would start by writing down the requirements for a fair source license, and the things we think maybe shouldn't be requirements but "ideal" (imo the time delay thing is ideal vs requirement) and then get feedback from folks on that, and use SSPL, ELv2, AGPL? as tests (reminder im not an expert on these licenses)

heres my point of view: 1) theres a set of non negotiable requirements for fair source licenses 2) theres a set of recommended goals

FSL may achieve them all, ELv2 may not e.g. recommended should be "a large chunk of the software is either permissive open source, or with a maximum of a 4 year delay, permissive"

we should be clear on the requirements, and recommendations, and note licenses which achieve both

I would make the approach more focused on “here are different licenses that follow this model, here’s example user, and here’s some kind of grading of if they achieve it fully or not"

chadwhitacre commented 1 week ago

I've published "The Historical Case for Fair Source."

chadwhitacre commented 1 week ago

I've started a PR to define a schema for self-reporting: https://github.com/fairsource/fair.io/pull/18. Comment over there?

chadwhitacre commented 1 week ago

Crap, wrong initiative, sorry! 😅

→→→→ https://github.com/getsentry/osspledge.com/pull/1

ezekg commented 6 days ago

@chadwhitacre looking at your tweet — is ELv2 not considered Fair Source anymore? It's not eventual-OSS.

chadwhitacre commented 6 days ago

@ezekg I don't know. I've been chewing on the same question. @dcramer's guidance above was to have tiers—"ideal" and "required." He put eventual OSS in "ideal" and not "required" but I'm not so sure. I think the story of Fair Source is much stronger if both elements are essential:

  1. meaningful self-hosted usage (even if some features are license-key-gated); and
  2. eventual OSS.

I know you're interested in moving Keygen in the eventual OSS direction. What are your thoughts on how to define Fair Source and how to communicate whatever-we-define to the world? For better or for worse, the Open Source Definition has been crucial to maintaining Open Source as a meaningful term in the world. Do we need something equally definite for Fair Source?

Considered another way: if eventual OSS is not essential to Fair Source, then what will it look like to try to have different "tiers" of Fair Source? Maybe:

That seems complicated to me to communicate, I worry it will muddy the brand for people out in the world.

chadwhitacre commented 6 days ago

To bring it inline from Twitter, here's a snapshot of the current design work for a vibe check. Vibe I think we're going for is safety, fairness (obvs), stability, modern and forward-thinking but not faddish. This is all very much in progress so now is the time to discuss.

WIP
ezekg commented 6 days ago

I feel like the new definition favors projects that monetize SaaS only. It leaves out those that monetize self-hosting (with or without SaaS as well). There's currently no license other than a customized BUSL that can be used for a project monetizing self-hosting to be considered Fair Source, because of the new eventual-OSS requirement. (Still working with Heather on the Fair Core License to change that.)

What about borrowing from Fair Code as a starting point?

[Fair Source] describes a software model where software:

  1. is generally free to use and can be distributed by anybody
  2. has its source code openly available
  3. can be extended by anybody in public and private communities
  4. is commercially restricted by its authors

Those could probably be tightened up, especially 4, but it's a good starting point. We could then make a point to emphasize eventual-OSS licenses like FSL, BUSL, and eventually FCL, because they're objectively closer to Open Source (a win!) and will in turn encourage community engagement more so than licenses like ELv2.

Encouraging eventual-OSS is good, but requiring it is not, imo. The whole point of Fair Source I thought was to make a term that helps bridge the gap between Open Source and source-available. Requiring eventual-OSS transfers the same problem that Open Source has to Fair Source where once again some projects that are almost-O/FSS-in-practice have to use the term "source-available."

Full transparency, and I figure it's unintentional, but suddenly excluding licenses like ELv2 feels like a rug pull done behind closed doors — the antithesis of the values I think Fair Source is trying to convey. If Sentry wants community involvement with Fair Source, these discussions and decisions should be made in public.

erlend-sh commented 6 days ago

What about borrowing from Fair Code as a starting point?

I like that.

The whole point of Fair Source I thought was to make a term that helps bridge the gap between Open Source and source-available.

That was my impression as well. Keeping the criteria as simple as possible would include the likes of Aseprite in the Fair Source family, which feels right to me.

ezekg commented 6 days ago

The whole point of Fair Source I thought was to make a term that helps bridge the gap between Open Source and source-available.

That was my impression as well. Keeping the criteria as simple as possible would include the likes of Aseprite in the Fair Source family, which feels right to me.

I think that project would fall under source-available, because it's not using any standard license, and the EULA limits modification and redistribution of the project. So it fails 1 and 3 of the fair code definition.

It's actually a good example of what most people think of when they hear source-available — read but don't modify or redistribute — which is why I think Fair Source needs to exist to differentiate projects that offer much more user freedom than what that EULA provides.

dcramer commented 6 days ago

Thinking more holistically, my fear is if we start just including every license that is basically a source available commercial license, what have we accomplished? We're just back where we started, but we've swapped out Source Available for Fair Source, and it means exactly the same thing.

There's two core things that I think we have the opportunity to push:

1) Fair Source should be more aggressive in freedoms than what we see culturally in Source Available software. It should be a better model than those traditional approaches. 2) Open Source is the desired output, and one of the fundamental goals of FSL was to minimize the compromise. That is, to minimize the protections needed. Fair Source was started as a reflection of those goals, as we thought of what we were doing as Open Source (or pretty dang close), but didn't have a way to articulate it.

I think Open Core models often reflect these values quite well (albeit, FSL to me is a superior approach than traditional Open Core), but I am not actually totally sure anymore than some of these other licenses do. If they only offer you the freedom to use the software, how are they any better than full proprietary?

I'm not saying the above are the hard requirements, but we should be concious of "how is this any different than Source Available", and if its not, this project is moot.

ezekg commented 6 days ago

@dcramer see my response above yours as to why grouping ELv2 under source-available is problematic. The term sucks.

Open Core and ELv2 are essentially synonymous for 99% of users. For both, there are parts of the code base that can be used freely, and parts that cannot. In the case of Open Core, the parts that cannot are typically licensed separately under one-off commercial or proprietary terms, which may or may not be under the same public code base (proprietary vs closed source). In the case of ELv2, the parts that cannot are gated by a license key, under the same code base and terms.

For any project monetizing self-hosting, having parts that cannot be used freely is a requirement (i.e. commercial features), otherwise what are you monetizing? For these projects, FSL doesn't work, because:

  1. if it's all licensed under FSL you can fork the core and grant yourself those features without recourse; or
  2. if it's using a Open Core style model, those features are licensed one-off or entirely closed source.

Neither of these are eventually-OSS for the commercial features. So saying these are fundamentally any different than ELv2 is a stretch — ELv2 just lets you license everything together under the same terms and under a single code base, which is much simpler than the alternatives.

I feel that overall, ELv2 is superior to Open Core because everything is under the same license, and commercial features are not closed source. But ELv2 is a non-compete, so it is also farther from Open Source than Open Core. So a "Fair Core" term is where I was leaning, in the same way Open Core is Open Source, Fair Core should also be Fair Source.

With that, I don't see how ELv2 should be excluded. It's essentially another way to do Open Core with a non-compete. At the end of the day, ELv2 offers the same freedoms as FSL minus eventual-OSS — non-competing use, modification, and redistribution.

I'm not saying to include every source-available license into the Fair Source umbrella, but I do think ELv2 should be included because it prioritizes giving as much user freedom as possible without compromising sustainability.

(The Fair Core License I'm working on with Heather will bridge this gap a little bit better, by essentially blending FSL and ELv2, making a license suitable for projects monetizing self-hosting that is eventually-OSS, but it doesn't change my thoughts on ELv2.)

chadwhitacre commented 6 days ago

Two Approaches to Defining Fair Source

Fair Code as a starting point

That's one approach:

I'd rather see us define Fail Source in terms of the four freedoms, because they're so much more widely adopted and understood. These are the four freedoms that define Free and Open Source Software:

  1. read;
  2. run for any purpose;
  3. modify; and
  4. share modifications with anyone.

I propose we define Fair Source as freedom to:

  1. read;
  2. run in ways that do not undermine the producer;
  3. modify for one's own use; and
  4. propose modifications back to the producer of the software.

Applying the Definition

To my mind ELv2 and SSPL clearly fit this definition, as does FSL. BUSL is ambiguous as we know. If we're allowing for ELv2 (and I'm being swayed in that direction) then I do like the idea of gold/silver/bronze above to differentiate further.

Aseprite I am not sure because the licensing situation is so complicated. That raises the further question: if we are adopting a clear definition of Fair Source—a Fair Source Definition, if you will(!)—are we going to enforce it? How?

The tradeoff is if we enforce it we make more work for ourselves and less confusion for users, vs. less work for ourselves at the cost of more potential confusion for users. We already have competing opinions here. Do we want that?

dcramer commented 6 days ago

@dcramer see my response above yours as to why grouping ELv2 under source-available is problematic. The term sucks.

Open Core and ELv2 are essentially synonymous for 99% of users. For both, there are parts of the code base that can be used freely, and parts that cannot. In the case of Open Core, the parts that cannot are typically licensed separately under one-off commercial or proprietary terms, which may or may not be under the same public code base (proprietary vs closed source). In the case of ELv2, the parts that cannot are gated by a license key, under the same code base and terms.

For any project monetizing self-hosting, having parts that cannot be used freely is a requirement (i.e. commercial features), otherwise what are you monetizing? For these projects, FSL doesn't work, because:

  1. if it's all licensed under FSL you can fork the core and grant yourself those features without recourse; or
  2. if it's using a Open Core style model, those features are licensed one-off or entirely closed source.

Neither of these are eventually-OSS for the commercial features. So saying these are fundamentally any different than ELv2 is a stretch — ELv2 just lets you license everything together under the same terms and under a single code base, which is much simpler than the alternatives.

I feel that overall, ELv2 is superior to Open Core because everything is under the same license, and commercial features are not closed source. But ELv2 is a non-compete, so it is also farther from Open Source than Open Core. So a "Fair Core" term is where I was leaning, in the same way Open Core is Open Source, Fair Core should also be Fair Source.

With that, I don't see how ELv2 should be excluded. It's essentially another way to do Open Core with a non-compete. At the end of the day, ELv2 offers the same freedoms as FSL minus eventual-OSS — non-competing use, modification, and redistribution.

I'm not saying to include every source-available license into the Fair Source umbrella, but I do think ELv2 should be included because it prioritizes giving as much user freedom as possible without compromising sustainability.

(The Fair Core License I'm working on with Heather will bridge this gap a little bit better, by essentially blending FSL and ELv2, making a license suitable for projects monetizing self-hosting that is eventually-OSS, but it doesn't change my thoughts on ELv2.)

Thats helpful. I always forget about the nuances.

I do think that the benefit is arguably only to the author here though, as open core you'd (ideally) have part of the codebase cleanly licensed as open source, whereas in ELv2 (at least my understanding) is that wouldn't be true? You'd still have the license holding true over all of it?

ezekg commented 6 days ago

Thats helpful. I always forget about the nuances.

I do think that the benefit is arguably only to the author here though, as open core you'd (ideally) have part of the codebase cleanly licensed as open source, whereas in ELv2 (at least my understanding) is that wouldn't be true? You'd still have the license holding true over all of it?

Yes, but in the case of ELv2, 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), 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 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.

chadwhitacre commented 6 days ago

you can redistribute those modifications without limitation

Does anyone actually do this, though? With ELv2, I mean.

chadwhitacre commented 6 days ago

ELv2 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.

Fair point.

chadwhitacre commented 6 days ago

(I don't have a problem with this but I do want to acknowledge it once on record: Keygen, as a key server, has a vested interest in companies shipping key-gated software. 😌🙏)

chadwhitacre commented 6 days ago

I'm about to head afk for the weekend, so to summarize my proposal:

  1. We adopt a Fair Source Definition based on the four freedoms.
  2. We adopt a 3-tier system (gold/silver/bronze).
  3. We have a license review process (using issues in this repo) to vet licenses into tiers or reject.

Definition

Fair Source grants freedom to:

  1. read;
  2. run in ways that do not undermine the producer;
  3. modify for one's own use; and
  4. propose modifications back to the producer of the software.

Tiers

🥇 Gold—unrestricted self-hosting + eventual OSS 🥈 Silver—(unrestricted self-hosting w/o eventual OSS) or (restricted self-hosting + eventual OSS) 🥉 Bronze—restricted self-hosting w/o eventual OSS

Initial Set

🥇 Gold—FSL, BUSL† 🥈 Silver—SSPL, ELv2 w/o key, FCL, BUSL† 🥉 Bronze—Open Core, ELv2 w/ key, BUSL†

† depends on implementation

ezekg commented 6 days ago

you can redistribute those modifications without limitation

Does anyone actually do this, though? With ELv2, I mean.

Not that I know of. But has anybody actually done this with BUSL or FSL? Feel like this is moot and depends on the project. I was mainly saying that to convey the freedoms users have, even if it's never used.

(I don't have a problem with this but I do want to acknowledge it once on record: Keygen, as a key server, has a vested interest in companies shipping key-gated software. 😌🙏)

Yes, this is true. I've been wanting to acknowledge this elephant in the room, too. (I had actually mentioned this "conflict-of-interest" to my wife awhile back and wanted to address it but hadn't yet so thanks for bringing it up. 👍)

Even with my vested interest in mind, I am sincerely not pushing ELv2 or FCL to benefit Keygen; ELv2 is the license I chose for Keygen because, like I said, it was the simplest way to go from closed source to source-available (looked at BUSL and AGPL + Open Core, too). So I also have a vested interest in making the freedoms of ELv2 clear because they're very often misunderstood thanks to the baggage from source-available.

Like I've said before, I'm fine with ELv2 (and FCL) w/ commercial features even being considered "Fair Core" and not Fair Source in a strict sense (though still under the umbrella because they have the same goals and values), as long as the relationship between Fair Core and Fair Source is clear like the relationship between Open Core and Open Source.

I really think this needs to be figured out because Fair Source needs to acknowledge that many Open Source projects monetize self-hosting (PostHog, Cal.com, GitLab, etc.), and there's no way to safely do that here too without Fair Core. And if Fair Source's mission is about balancing sustainability and user freedom, Fair Core is just as much a part of that mission, just focusing on the other side of the monetization coin.

So maybe those tiers could be:

  1. Fair Source and eventually OSS (FSL, BUSL)
  2. Fair Core and eventually OSS (FCL)
  3. Fair Source and never OSS (SSPL, ELv2 w/o comm features, BUSL)
  4. Fair Core and never OSS (Open Core, ELv2 w/ comm features, BUSL)

In this case, either 1 or 2 are preferable, because everything* is eventually OSS, but 3 and 4 are also acceptable. All are good, but some are better because they also benefit OSS (again, values overlap). They also all abide by the freedoms you mentioned, at least for their core offering.

But even 1 and 4 may see some overlap (the * above), because a project could be Fair Core under FSL, where commercial features are never OSS even if the majority of the code base will be OSS (e.g. if the ee/ directory was under the typical one-off commercial license used in Open Core projects).

So imo it doesn't really matter how something is Fair Core (comm features under different license terms, gated by license key, file location, file contents, closed source, etc.), what matters is that most of the code abides by the freedoms of Fair Source, but some of it is restricted ala Open Core.

So revising tiers, acknowledging possibility for overlap:

  1. Fair Source and eventually all OSS
  2. Fair Core and eventually all OSS
  3. Fair Source and never all OSS
  4. Fair Core and never all OSS

(Sorry for the brain dump — just been thinking about this a lot as I work on drafting FCL and the website for it, https://fcl.dev.)

wdyt?

ezekg commented 5 days ago

To my mind ELv2 and SSPL clearly fit this definition, as does FSL. BUSL is ambiguous as we know. If we're allowing for ELv2 (and I'm being swayed in that direction) then I do like the idea of gold/silver/bronze above to differentiate further.

Sorry I missed this comment earlier. I wish I didn't because it kind of makes my comment above irrelevant. But it's worth discussing a Fair Core term if self-hosting is restricted (similar to Open Core), to simplify Fair Source (which sounds like what you and @dcramer want).

I like the idea of a Fair Source Definition. Although I don't particularly like the gold/silver/bronze tiered approach, I'm not sure I can come up with another way that encourages eventual-OSS with the least amount of restrictions possible (i.e. FSL > FCL > ELv2).

Maybe Fair Source = meets definition, Fair Core = meets definition with restrictions on self-hosting? Could strongly encourage but not require eventual-OSS for both.

Going to think on this more.

chadwhitacre commented 5 days ago

https://fcl.dev/     👀 💃

Fair Source needs to acknowledge that many Open Source projects monetize self-hosting (PostHog, Cal.com, GitLab, etc.), and there's no way to safely do that here too without Fair Core.

Fair point. ;-) I searched for "open core" on opensource.org and found a strongly worded denunciation(!). It's probably worth being explicit on our website that we see both Open Core and Fair Core as legitimate approaches.

ezekg commented 5 days ago

Fair point. ;-) I searched for "open core" on opensource.org and found a strongly worded denunciation(!).

They denounce everything. Doesn't stop most Open Core projects rightly claiming they're also Open Source. Maybe that's a battle they lost? I don't know the history there.

It's probably worth being explicit on our website that we see both Open Core and Fair Core as legitimate approaches.

Agreed. In the same way an Open Core project can call themselves Open Source (much to OSI's dismay — just look at PostHog, Cal.com, etc.), I think Fair Core should be to Fair Source what Open Core is to Open Source.