> It isn't clear what restrictions will be allowed and still qualify as a "Fair Source" license

We called that out on the website though:

Fair Source Software (FSS):

* is publicly available to read;

* allows use, modification, and redistribution with minimal restrictions to protect the producer’s business model; and

* undergoes delayed Open Source publication (DOSP).

The delayed open source publication part is explicit.

"minimal restrictions to protect the producer’s business model"

That isn't very clear to me. Does every license author or licensor get to decide for themselves whether or not a license is Fair Source, or whether or not a limitation is "minimal"? Honestly, I don't think the limitations in the Functional Source License are "minimal". But others clearly believe they are.

The delayed part is explicit... but could a license that delays release to open source for 1,000 years be considered "fair source"? It is a DOSP as you say?

I understand that the Fair Source branding movement is still young and is likely evolving policies and procedures, but those are some of the questions I already see coming up when discussing whether or not a license is Fair Source. It may take a while for the definition to mature.

And it's important that we have these conversations. I would however like to understand why you believe the limitations on the FSL are too strict and what exactly they prevent which you believe they should not.

Lets say there is an FSL licensed SaaS app. And that the company behind it offers two tiers, a lower monthly fee that is "self service" with no integration assistance, and a higher monthly fee with a long contract term that offers integration assistance.

I decide I want to self host the product. I reach out to the company about integration assistance. They tell me they don't provide any support for the self hosted product and aren't interested in providing me with integration assistance if I don't use their hosted version.

Now, I decide to hire a local contractor I know to help me integrate the self hosted version. They don't touch the code or do anything with it, they just work on integrating it into my existing business stack.

Now, the SaaS company offers a competing product and service- the hosted SaaS with integration assistance. Is my contractor violating the license by offering a a service that substitutes for the service offered by the SaaS company?

I think many such SaaS companies would be fine with it, it wasn't a job they were interested in... but it rides up against the license really closely. And there are many variations of this scenario that could play out that could easily cross the line. (Perhaps SaaS company puts in a bid to do the work, but I decide a local contractor I have used many times in the past and is thus familiar with my stack and what they would be integrating would be better, or maybe the contractor does have to make changes to the FSL licensed code in order to make it work with something I need.

Those things can be negotiated and clarified, but generally only if you know they are an issue up front. If business needs change after you have adopted the software, you are in a tough negotiating spot.

One big benefit to the well worn and simple permissive open source licenses is simply knowing very early what exactly I can and can't do. The FSL is trying to get as close to this as possible, but it is inherently more complicated that "take this code and use it, just credit me and don't expect any warranty from me, oh, and by the way, if you want my help I offer my service for $$$ so reach out" style open source licenses (not all open source licenses are simple like that, though).

No ones saying Fair Source is better than Open Source, but in your analogy one protects the commercialization of a project, and the other does nothing to protect the creators.

The clarity of what is and isnt permitted is something we'll be looking to make sure is enforced via the license, at least in FSL's sake. The intent is that if you're commercializing by say, providing support or integration services, that its totally valid. What's not valid is hosting a competitive offering using the source code. That is, with FSL you cannot spin up the project and sell it as a cloud service, but you can provide professional services to customers using said product.

If you decided to build something that tried to sneaky leverage the business model that funds development, that its so closely related to what the company would do, and then the company does it... well, don't do that? You'd be stuck on the old version. Thats the price you pay for trying to be sneaky. The license is effectively encoding a set of values/ethics in how people should run businesses, particularly when building on top of other peoples businesses. I think this is totally fine, so whenever people bring up these hypotheticals I just shrug them off, as they're an academic edge case that all but a handful of individuals will never need to care about them.

Also generally speaking, the case you're describing sounds more likely to be an integration say between your service and their service, or more specifically, your code and their service (say an integration between Sentry annd MyCoolTicketTracker). You could still sell that integration just fine, as its your code, not the FSL code. What you couldn't do is sell a cloud service that was MyCoolTicketTracker, that funnels to a privately hosted Sentry, and then exposes the functionality of Sentry into MyCoolTicketTracker. At that point you're commercializing Sentry itself, not your services.

> Now, I decide to hire a local contractor I know to help me integrate the self hosted version. They don't touch the code or do anything with it, they just work on integrating it into my existing business stack.

We even specifically call out that case in the license as a permitted purpose:

> Permitted Purposes specifically include using the Software: [...] in connection with professional services that you provide to a licensee using the Software in accordance with these Terms and Conditions.

And yes, Fair Source has limitations over Open Source and by design. We figured the best way to balance this out is to transition it into a full and unquestionable Open Source via a springing license.

There are companies whose business model is to offer professional services around the software they produce. In this case, this clause means that they can't use that license to prevent such competition.

Which is why I expect multiple fair source licenses to appear. There is already the FCL too.

"accordance with these Terms and Conditions" implies that the above limitations still apply, does it not?

Hmm, though thinking more about it, as long as the licensee is the company using the software, rather than the company providing the professional services to the company using the software, then that might be allowed.

Does that interpretation sound like the intent?

The licensee is the company using Sentry.

In addition, underneath the definition, we touch on that even more:

> The intention is for the first point to be a bright line, and for the second to invite exploration. We expect Fair Source licenses to emerge and evolve and shake out into a few clear winners over time, as companies apply Fair Source within their own particular business context. The third point is also intended as a bright line, and a key differentiator of Fair Source from Open Core and other approaches.

The key line is to "invite exploration."

Thank you for pointing that out, I did a quick read through of that part and missed the intention behind it. I also found the Readme which helps explain the direction things are going. (https://github.com/fairsource/fair.io/blob/main/README.md)

All of the points you raise would be too if the project were simply a proprietary product, too. We're not worse off for having to deal with them for two years instead of forever.

No doubt that Fair Source and other eventually open source products are better than never open source products. Absolutely! And if Fair Source succeeds in getting more developers to release code, even if the code is 2 years old, as open source, I am all for it. I just want a clear understanding of what it is and what it isn't and what makes it different from open source.

If the vendor doesn't go open source, I will look for an open source alternative. If none is available, I will consider building one. Only after researching those options would I consider a propeietary or "Fair" source product. And I would be very careful with how I integrate such a product into my business.

So yeah, if there are no good open source alternatives and building my own would be cost prohibitive, I might consider a Fair Source product.

This approach is not available to most people most of the time, so it's not going to make a difference.

It's available to everyone, all of the time. Anyone can do it, which is why you actually see forking and custom tooling quite frequently in businesses at-scale.

It's absolutely bewildering that someone would say "it's not going to make a difference" when half of the market for B2B software is literally predicated on the existence of more permissive tooling. Licensing is practically the only thing that matters besides security and functionality when evaluating software.

I'm not sure what you mean by this? I would guess from my own experience that there are open source alternatives to the majority of software. Often the open source software is just as good or better.