Skip to content
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

Add Qlty Software to Companies #60

Merged
merged 2 commits into from
Jan 23, 2025
Merged

Add Qlty Software to Companies #60

merged 2 commits into from
Jan 23, 2025

Conversation

brynary
Copy link
Contributor

@brynary brynary commented Jan 11, 2025

Hello! Thank you for your work on this initiative.

At Qlty Software, we have adopted Fair Source licensing, and we have blogged about it here.

This PR adds Qlty Software to the Companies webpage. Please let me know if you have any questions.

Thank you,

-Bryan

@ezekg
Copy link
Collaborator

ezekg commented Jan 11, 2025

@chadwhitacre @dcramer what is your stance on forks of FSL using OSS change licenses that aren't 'official'?

I see this quote on the FSL website against copyleft, which is why I'm tagging y'all:

Why only Apache 2.0 and MIT?
Looking at popular licenses according to OSI and GitHub: copyleft is not our jam, and BSD/ISC don't offer anything over MIT. That leaves Apache 2.0 (with its patent grant) and MIT.

Regardless, love to see this @brynary!

@dcramer
Copy link

dcramer commented Jan 11, 2025

My general opinion is that if you're going to use the GPL, why use FSL in the first place? The goal of FSL is to grant freedom after 2 years, whereas GPL continues to impose what most would consider much stricter restrictions on use. GPL provides quite a large number of seen-as commercial protections, and inhibits adoption of software amongst many organizations who are fearful of consequences or the otherwise tenctacles of a piece of software licensed on GPL reaching into more of their stack, thus causing license violations.

I'd also prefer it not be called FSL - its ok to fork the license, but using the FSL name isn't something we'd support.

@brynary
Copy link
Contributor Author

brynary commented Jan 11, 2025

@dcramer thanks for weighing in. I appreciate your points and expect we'll continue to think about these questions.

To avoid any unwanted confusion, we will fork the license with a new name.

@brynary
Copy link
Contributor Author

brynary commented Jan 11, 2025

Update: We've adjusted the name not to include "Functional Source License" to avoid any confusion in the repository, and clarified in the blog post it is not the official FSL.

@dcramer
Copy link

dcramer commented Jan 11, 2025

Update: We've adjusted the name not to include "Functional Source License" to avoid any confusion in the repository, and clarified in the blog post it is not the official FSL.

Thank you! I'll let Chad weigh in next week, but I'm still strong the added copyleft into the mix muddies the waters too much

@brynary
Copy link
Contributor Author

brynary commented Jan 11, 2025

@dcramer of course.

Re: Copyleft and also for Chad when he gets here... I definitely see where you are coming from.

I think your points are good and make a lot of sense from the standpoint of looking at Fair Source as an alternate to OSS. Through that lens, I completely agree.

However, from the lens of Fair Source being positioned as an alternative to closed source, then I would probably suggest that having the Fair Source tent accommodate that is valuable.

(My understanding is that it's an important priority for Fair Source not to be confused as an alternative to Open Source.)

As some additional context, we were considering the BSL which is a Fair Source license with delayed publication to GPL, but we preferred the simplicity and structure of the FSL over the BSL, which is how we landed where we did.

Since the BSL conveys to GPL, it is/was our understanding that the Fair Source concept is compatible with DOSP to copyleft. Is that accurate?

Regardless, we understand FSL != Fair Source and Fair Source is a superset.

Please feel free to disregard the idea, but one possibility you and Chad may consider is supporting an official FSL-GPL variant that is labeled as "not recommended" (similar to how GNU recommends the GPL over the LGPL), as a way to promote adoption of the FSL language over BSL. But totally respect your decision to keep FSL narrowed.

@ezekg
Copy link
Collaborator

ezekg commented Jan 12, 2025

I thought it'd be worth mentioning, since @dcramer alluded to it, that going from FSL to GPL after 2 years places timed restrictions on your software for users that do not upgrade. For example, if version 1.0 of your software, licensed under an FSL-GPL license, is released on Jan 1st, 2025, then it becomes GPL on Jan 1st, 2027. If a user wants to avoid copyleft, they MUST upgrade to a later version. And if you happen to go out of business or stop releasing new versions of the software under the FSL-GPL license, everybody will eventually be forced into the GPL and the legal ramifications of that (or stop using the software).

That all seems… confusing — and likely not your intention (correct me if I'm wrong). But it's worth thinking about, because if a user can't use copyleft, they can't use your software. Maybe that's what you want, but if it is, then I would fork the FSL and add copyleft restrictions into the base license to match change license, so that there's some harmony there.

The reason why MIT and ALv2 work so well for the FSL is because they don't add additional restrictions on top of the FSL — the change license simply removes restrictions, namely the non-compete, after 2 years.

@brynary
Copy link
Contributor Author

brynary commented Jan 12, 2025

@ezekg ah, thanks for that additional information. That's a great point that we had not considered before.

Essentially, it means that the FSL is not harmonized with the GPL, so the construction of an FSL-GPL likely has a subtle and undesirable impact. Allow me to please withdraw my prior advocacy for a FSL-GPL :) (If I understand correctly, this issue affects BSL as well since it DOSP's to GPL.)

Appreciate the education on this. We're going to spend some more time thinking about potentially improving the license to resolve this issue later this year.

In the meantime, can this PR be merged on the basis that our license conforms to the three principles of the Fair Source umbrella?

@brynary
Copy link
Contributor Author

brynary commented Jan 21, 2025

@ezekg hi Zeke -- Just wanted to check in on this PR.

Is there anything needed for this PR to be merged?

Thanks!

@chadwhitacre
Copy link
Contributor

Thanks for showing up here, @brynary! :) Sorry for being late to the party.

In the meantime, can this PR be merged on the basis that our license conforms to the three principles of the Fair Source umbrella?

Binary answer: no. Here's our status quo on recognizing new licenses:

For licenses, we're still working out specifics but we intend to be fairly stringent in order to avoid license proliferation. Of course your license must meet the Fair Source Definition. It must also not put an undue burden on the user to monitor their compliance with your license (any compliance checks should be built into your software itself). It should also be adopted at more than one company, at least.

As we've started to uncover in this thread, there are important nuances to consider. Basically we would want to see you do what @ezekg said: "fork the FSL and add copyleft restrictions into the base license to match change license, so that there's some harmony there." Once you have a solid license, and another company or two ready to adopt it with you, you could bring it back to us for recognition as a Fair Source license. We would be eager to promote Qlty as a Fair Source company once the license was official.

Not the answer you want, but it's the answer I've got, I'm afraid. Happy to jump on a call if you want to talk it through further. We could get into copyleft vs. permissive approaches to Open Source and why permissive is more aligned with Fair Source in the first place. (@ezekg is not invited. ;)

@brynary
Copy link
Contributor Author

brynary commented Jan 21, 2025

@chadwhitacre thanks.

My understanding is that the BSL license has a DOSP to GPL provision and is considered an official Fair Source license. Is that accurate? If so, then we'll use the off-the-shelf BSL for now until we have more time to devote to this.

@chadwhitacre
Copy link
Contributor

That's an option, yes. The complication with the BSL is that each one is different, so we need to review your specific BSL once you have it to decide if it counts for Fair Source. You can look at Sentry's old BSL implementation for inspo. The more complicated ones like HashiCorp's would not be a fit.

@brynary
Copy link
Contributor Author

brynary commented Jan 21, 2025

Thanks, @chadwhitacre. We will look into that route.

Can you please clarify the specifics for what is allowed or not allowed in a BSL license?

@dcramer
Copy link

dcramer commented Jan 21, 2025

I would argue, BSL by default, is not Fair Source. It can be, but converting from one proprietary license to another restricted license isnt really in the spirit of what we're trying to accomplish here. BSL is just a license that allows you to inject an arbitrary use clause. Each license is a unique snowflake, so BSL in general is not something we'd label as compatible.

@chadwhitacre
Copy link
Contributor

chadwhitacre commented Jan 21, 2025

BSL in general is not something we'd label as compatible.

Alright, well, we might have a mismatch, because we do list BSL on fair.io/licenses. In the README (but not on fair.io) we say, "If you're using BUSL we will need to review your license more closely since BUSL can have highly variable implementations." Do we need to course-correct, @dcramer?

@dcramer
Copy link

dcramer commented Jan 21, 2025

Your statement is correct, I'm just saying generically BSL is not compatible. Its no different than removing any arbitrary license in that context.

@brynary
Copy link
Contributor Author

brynary commented Jan 21, 2025

OK, so if I am understanding properly, it sounds like BSL can be compatible but is not always compatible. That sounds fine.

@chadwhitacre -- Two quick questions that would be helpful:

  1. Can you please confirm that the linked MariaDB BSL, which DOSPs to GPL, is considered acceptable?
  2. Can you please clarify what would make a specific BSL implementation compatible vs. non-compatible? Is it a matter of complying with the three principles of Fair Source Definition, or are there additional requirements?

Postscript follows...

As a bit of meta, I am struggling a bit with three questions on this thread:

  1. Is the expectation that the intent is to apply current policy, or is policy potentially changing on the fly?
  2. What is the decision-making governance process?
  3. What feedback is suggestions vs. requirements (related to 1 and 2)?

(These questions aren't blockers as I'm just focused on figuring out how to create a compatible BSL. This is just feedback that I thought may be valuable from the standpoint of a new community member, which may benefit future contributors.)

@ezekg
Copy link
Collaborator

ezekg commented Jan 21, 2025

Is the expectation that the intent is to apply current policy, or is policy potentially changing on the fly?

@brynary I don't think we've changed policy on-the-fly here. Fair Source is new, but we've communicated generally what we'd like to see from other licenses — abide by the Fair Source Definition, and make it hard to unintentionally violate the license. Right now, the Qlty Source License fails the latter, since changing from non-copyleft to copyleft may cause users to unintentionally violate the license by not open sourcing their software which may eventually depend on a future GPL-licensed Qlty.

As it stands, your variant of FSL-GPL has ambiguities that make it hard to comply with by switching from non-copyleft to copyleft after a certain point in time, which some users may not realize, placing them in a legal 'danger-zone' after 2 years. Like I mentioned, this may (will?) cause some users to unintentionally violate the GPL license terms, because it's confusing to have to keep software up-to-date to use a non-copyleft license, otherwise you have to abide by the copyleft terms. (And even if they did keep it up-to-date, do previous versions of their software need to eventually abide by GPL as well? AINAL lol.)

If you're looking to go the FSL-GPL, maybe work with @heathermeeker to create a copyleft derivative of FSL? I don't really know what that'd look like 1, but I went down a similar route with the Fair Core License when the FSL didn't work for my specific use case (monetizing self-hosting + cloud). Perhaps Heather, or somebody else, can help you tighten up the FSL license text to be a better fit for a copyleft change license (e.g. I'd imagine by making the FSL text copyleft as well but AINAL). Recommending Heather in particular here because she's worked on the FSL and FCL.

Right now, afaik, no BUSL implementation is considered Fair Source yet. But that's not to say it couldn't be, but like others have mentioned, every implementation of BUSL is itself essentially its own license that needs its own compliance/legal review, and thus far, nobody has come forward asking for their BUSL variant to be Fair Source.

(I'd personally consider buttoning up QSL vs a custom BUSL — they're both 'custom' licenses anyways. But of course, that final decision is left up to you — just sharing my $0.02. 🙂)

Footnotes

  1. I'm also going to agree with @dcramer in that Fair Source and copyleft aren't the most harmonious choice, because copyleft already kind of acts as a non-compete for products. To me, seems like you're saying "don't compete for 2 years, then probably don't compete after that either." Not to say it can't be done — and even done well — I just don't know what that'd look like tbqh.

@brynary
Copy link
Contributor Author

brynary commented Jan 21, 2025

@ezekg thanks. Yes, I'm happy to abandon the QSL-GPL direction for now for the reasons cited. We will look into BSL/BUSL as the next step.

Here is what I am planning:

  1. Adopt a BSL 1.1, which is based on the linked MariaDB BSL and DOSP-es to GPL
  2. From @chadwhitacre's recommendation, use an Additional Use Grant which is similar to the one that Sentry used in it's BSL

From a quick review of the Sentry BSL, a simple, comparable Additional Use Grant like this (pending review by legal):

You may make use of the Licensed Work, provided that you do not use the Licensed Work for a Code Quality Service.

A "Code Quality Service" is a commercial offering that allows third parties (other than your employees and contractors) to access the functionality of the Licensed Work soo that such third parties directly benefit from the code quality or code coverage features of the Licensed Work.

Would this meet the requirements?

@chadwhitacre
Copy link
Contributor

Is the expectation that the intent is to apply current policy, or is policy potentially changing on the fly?

The intent is to apply current policy where adequate, and develop policy where needed, sooooo ... both? 🫠

We haven't had someone push for GPL/copyleft yet. For FSL we're explicit that "copyleft is not our jam," but Fair Source is bigger than FSL. For Fair we define DOSP as "publishing that software’s source code under an Open Source license," with a very strong contextual implication that this means any OSI-approved license. In my view it would constitute a change to Fair Source policy to exclude copyleft. We would need a conversation about it, in its own GitHub issue. Conversely, we should probably explicitly say "OSI-approved" there if that's our intent. I've made a PR for that: #65.

We also haven't had someone push us this hard for BUSL, so we don't have any more specific guidance developed than what I've already linked. I've opened #61 to further discuss the general question.

What feedback is suggestions vs. requirements (related to 1 and 2)?

The suggestion is that you use FSL. 😬 The requirements are that you use FSL or FCL, or a BUSL that fits the Fair Source Definition, or a new license after it has gone through our license approval process.

What is the decision-making governance process?

This is documented in the README; I'll inline it here for posterity:

Governance and Process

Fair Source is just getting started, so our governance and process are fairly lightweight. Chad Whitacre (Sentry) and Zeke Gabrielse (Keygen) are handling new company and license submissions.

For companies, we are looking for a) a blog post announcement about b) a software product using a Fair Source license. If you're using BUSL we will need to review your license more closely since BUSL can have highly variable implementations.

For licenses, we're still working out specifics but we intend to be fairly stringent in order to avoid license proliferation. Of course your license must meet the Fair Source Definition. It must also not put an undue burden on the user to monitor their compliance with your license (any compliance checks should be built into your software itself). It should also be adopted at more than one company, at least.

I've opened a PR to explicitly acknowledge @dcramer's role in decision-making: #63.

@brynary
Copy link
Contributor Author

brynary commented Jan 21, 2025

Thanks @chadwhitacre. This is very helpful!

Based on this information, we are going to start with a BUSL which meets the Fair Source Definition.

I'm still getting my head around BUSL, but it looks like besides the DOSP license (which has been clarified, thanks) that the last variable is the Additional Use Grant.

I sketched out a quick Additional Use Grant modeled off Sentry's, and probably posted it as you were writing this response.

Does that Additional Use Grant look OK?

If so, I'll clean up something to a final form here for review, and then following review I will apply the license in the repository and update our blog post.

@chadwhitacre
Copy link
Contributor

Does that Additional Use Grant look OK?

Probably. Circulating with Sentry legal, will get back to you hopefully tomorrow. :)

@ezekg
Copy link
Collaborator

ezekg commented Jan 21, 2025

@brynary that's a good point about MariaDB's BUSL, which does use a GPL change license. I'm going to defer to 'legal' here because copyleft, especially copyleft change licenses, are a bit over my head tbh. Maybe there's some nuance here re: MariaDB/BUSL where the change license isn't retroactive like I originally thought it would be. I'll admit that BUSL and GPL are licenses that I don't know as well as the FSL or FCL. I'll defer to legal now before I say something incorrect. 😅

p.s. I'd support a Fair Source license with a copyleft change license, just to be clear. I just don't know what that'd look like. (I'd be interested in seeing some clarification on the above scenarios as well i.r.t. a copyleft change license.)

@chadwhitacre
Copy link
Contributor

Confirmed with @GavinZee we're good to move forward with Sentry-ish BSL as at #60 (comment). Let's get you onboarded @brynary and we can discuss additional documentation updates in other tickets/PRs. Huzzah! :)

@brynary
Copy link
Contributor Author

brynary commented Jan 22, 2025

Thanks, @chadwhitacre. That's great to hear!

I'll update our license and blog post and revert back here.

@brynary
Copy link
Contributor Author

brynary commented Jan 23, 2025

@chadwhitacre OK, we are all set here... I've updated our LICENSE file as well as our blog post.

Excited to be part of this community and looking forward to contributing!

@chadwhitacre
Copy link
Contributor

Thanks, @brynary ... almost there! :)

Other variations of the FSL revert to the permissive Apache or MIT licenses. We considered that option; however, we felt that the GPL's copyleft protections provided value by ensuring that all future improvements to the CLI are made available to the whole community.

This paragraph in the blog post has lost its referent. Maybe something like:

We considered the Functional Source License (FSL), but it is written with permissive Open Source in mind, and only allows for Apache or MIT as future licenses. We felt that the GPL's copyleft protections provided value by ensuring that all future improvements to the CLI are made available to the whole community.

@brynary
Copy link
Contributor Author

brynary commented Jan 23, 2025

@chadwhitacre thank you for the copy improvement! I've updated the post.

@chadwhitacre
Copy link
Contributor

Awesome! Thanks for seeing this conversation through with us and for joining Fair Source! :D

I've approved the PR, leaving for a final review from @ezekg.

@chadwhitacre chadwhitacre requested a review from ezekg January 23, 2025 14:34
Copy link
Collaborator

@ezekg ezekg left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks great. LGTM! 🤘

@ezekg ezekg merged commit 2f13f1f into fairsource:main Jan 23, 2025
@chadwhitacre
Copy link
Contributor

Woo-hoo! Welcome aboard, @brynary! 💃

@ezekg
Copy link
Collaborator

ezekg commented Jan 24, 2025

image

Congrats! Welcome to the club. Ping me if you share the blog post and we can retweet, etc.

@brynary
Copy link
Contributor Author

brynary commented Jan 24, 2025

Awesome, will do. Thanks again!

@brynary
Copy link
Contributor Author

brynary commented Jan 27, 2025

@chadwhitacre Just a quick heads up that we had a late request from legal to clarify how our Additional Use Grant relates to AI coding services.

The intention of our Additional Use grant was to allow widespread use, however we are not granting AI services (e.g. various coding copilots) rights until the DOSP.

I had considered that covered by the restriction on a Code Quality Service but legal felt it could be a bit ambiguous in these cases. To avoid any ambiguity, we've clarified the license to explicitly define Artificial Intelligence Coding Services as products externally commercializing AI coding and indicated that they are not covered by the Additional Use Grant and need to wait for DOSP.

We felt this continues to maintain the spirit as folks selling AI coding tools are a small minority of firms which clearly know that they are doing so.

If you have any questions or concerns about this edit, please let me know.

@chadwhitacre
Copy link
Contributor

Thanks for the heads up, @brynary.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants