Launch Fair Source #14
Comments
|
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). |
Woo-hoo! Awesome! 😁 Re: Fair Code, there are few more details at #10 (comment). @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! 🤞 |
|
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?
🤔 |
|
Hmmm ... maybe Fair Source distinguishes between software producers and consumers. Fair Source producers grant consumers the right ("freedom") to:
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. |
|
Interesting Twitter exchange with ESR, led to a post "Widespread Use of a Fair Source Product." |
|
I cleaned up the homepage and started driving traffic a bit. 
|
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 rebuttal1 i.r.t. widespread use of "fair source." Footnotes
|
Ah, interesting, okay. Hmmmm ... 🤔 Trying to synthesize the different real-world approaches, wrapping my head around each one. This helps, thanks. |
|
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). |
|
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. SULSUL 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. |
|
I've started a Google Doc that I'll be using to coordinate with our design team (also linked in the description). |
|
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. |
|
Sentry's Launch Week has been moved. The Fair Source launch is now scheduled for August 16. |
|
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. |
|
Pitch to simplify through a single Fair Source License: #16. |
|
Decision on #16 was to reticket #17 and proceed here as follows:
Refer to the Google Doc for further iteration. |
|
Decision taken to not block launch on renaming FSL to Fair Source License. More detail at #17 (comment) 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. |
|
Bringing this back here:
@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 ... ? |
|
Posting some additional guidance from @dcramer culled from last week's convos in private Slack:
|
|
I've published "The Historical Case for Fair Source." |
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
|
@chadwhitacre looking at your tweet — is ELv2 not considered Fair Source anymore? It's not eventual-OSS. |
|
@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:
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. |
|
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. 
|
|
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?
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. |
I like that.
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. |
|
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:
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. |
|
@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:
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.) |
Two Approaches to Defining Fair Source
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:
I propose we define Fair Source as freedom to:
Applying the DefinitionTo 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? |
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 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. |
Does anyone actually do this, though? With ELv2, I mean. |
Fair point. |
|
(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. 😌🙏) |
|
I'm about to head afk for the weekend, so to summarize my proposal:
DefinitionFair Source grants freedom to:
Tiers🥇 Gold—unrestricted self-hosting + eventual OSS Initial Set🥇 Gold—FSL, BUSL† † depends on implementation |
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.
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:
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 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:
(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? |
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, Going to think on this more. |
|
https://fcl.dev/ 👀 💃
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. |
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.
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. |
|
Okay, gang! We're getting into the home stretch here. I've drafted two new pages for the website based on our conversation here a couple weeks ago: Fair Source Definition and Licenses. @ezekg Will FCL be ready for launch, do you think? I have it listed under "approaches" on the licenses page. August 2 is the one-year anniversary of the "Codecov is now Open Source" that kicked this all off. However, that is a Friday, and @selviano is on vacation that week (I'm out next week, btw). Shall we aim to launch on Monday, August 5? I intend to start a private email thread with the companies that have said they will launch with us, to coordinate more closely. @ezekg I'll include you on that. Anyone else listening here that wants in on that? Plans this week:
Anything else missing? How are we feeling about this? I'm excited! :D |
|
@chadwhitacre working to hopefully finalize FCL this week (have a call tomorrow to do so). I have a landing page for FCL ready to go, as well as a "Keygen is now Fair Source" blog post ready to go announcing that Keygen is relicensing from ELv2 to FCL, which delves into Fair Source itself a bit, and also introduces the Fair Core License and the "why." An August 5th launch would work for me. |
|
Hey @chadwhitacre et al, just to be clear, are you planning to move forward with branding "fair source" as a form of "open source"? I offer you the best wishes with the fair source plans, subject to it being clearly distinguished from open source. I ask specifically because this blog post you cited is explicitly passing off non-open-source licenses as if they were open source. |
|
Hi, @ddevault, thanks for jumping in.
Binary answer: no.
If you scroll down a bit on that post, you'll see this next-day update:
In other words, the so-called "Codecov kerfuffle" is what led to Adam's CTA, which launched us on the whole story arc that has led up to Fair Source. This is explained in the description on this ticket, let me know if there's a way we can make it clearer. |
|
Wonderful. I figured as much, but just checking in to be sure. Thanks! |
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:
Fair Source is our fill-in-the-blank for “Codecov is now [__________].”
Organizing docs (shared with Sentry's design/build team).
Launch target: August 5.
To Do
promote it at Sentry's next Launch Week in AugustThe text was updated successfully, but these errors were encountered: