Clarify BUSL requirements

[chadwhitacre]

We allow for BUSL as a license but we say (in the README, not on fair.io): "If you're using BUSL we will need to review your license more closely since BUSL can have highly variable implementations."

In #41 we reviewed a pre-existing BSL. Now in #60 @brynary is asking about how to make a new one from scratch that we'll accept as Fair Source:

Can you please clarify the specifics for what is allowed or not allowed in a BSL license?
Can you please confirm that the linked MariaDB BSL, which DOSPs to GPL, is considered acceptable?
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?

For BUSL implementations the main Fair Source criterion they might fail would be the second: "allows use, modification, and redistribution with minimal restrictions to protect the producer’s business model." That is, they would generally meet the first (publicly readable software) and third (DOSP is built-in) criteria. Here is the relevant text in the MariaDB BSL 1.1:

The Licensor hereby grants you the right to copy, modify, create derivative works, redistribute, and make non-production use of the Licensed Work. The Licensor may make an Additional Use Grant, above, permitting limited production use.

The first question is whether, without any Additional Use Grant, the BUSL fits Fair Source point 2. My gut says no: disallowing all "production use" goes against the intent of Fair Source. Does anyone want to argue differently?

Given that, then the question becomes: what Additional Use Grants are acceptable?

Honestly, one way we might resolve this is to say "BUSL is legacy and we only review BUSL licenses that existed prior to the launch of Fair Source."

[brynary]

The first question is whether, without any Additional Use Grant, the BUSL fits Fair Source point 2. My gut says no: disallowing all "production use" goes against the intent of Fair Source. Does anyone want to argue differently?

My 2 cents is that I agree -- disallowing "production use" is too restrictive to comport with the spirit of Fair Source.

If this is the position that is settled on, I would recommend changing the website to not link to Maria obviously.

Given that, then the question becomes: what Additional Use Grants are acceptable?

It seems like non-compete provisions are clearly acceptable, a la Sentry's BUSL.

This one may benefit from some surveying of BUSLs in the wild.

Honestly, one way we might resolve this is to say "BUSL is legacy and we only review BUSL licenses that existed prior to the launch of Fair Source."

My feedback on this one is that it starts to make it feel like Fair Source == FSL. I realize the door is open to approving future licenses -- however there is a bit of a chicken and egg problem if new licenses can the approved until they are used by multiple companies and companies cannot be listed unless they have an approved license. (Listing on the website would be one of the ways to drive awareness and interest in a new license.)

Here would be my recommendations IMHO to maximize the impact of the Fair Source effort:

1. Instead of blocking off BUSL, try out having clear ok-vs-not-ok BUSL criteria to give folks adopting BUSLs the best chance to join the Fair Source movement. It's possible this will prove untenable, but it seems premature to block BUSL before documenting criteria.

2. Consider allowing companies to be listed on the website if their license meets the Fair Source Definition but isn't an approved license yet. In essence, separate the two. This allows for a company to attract interest in a license that meets the Definition to gain adopters and then get it approved.

The result of this could be to encourage development of a BUSL alternative license which is not FSL to be funded and adopted and approved.

There are companies who find benefit in BUSL and it can fit the Fair Source Definition. However, the substantial variables create some operational overhead.

The best time to deprecate BUSL would be when the community has developer one or more approved Fair Source alternatives which don't have the variability proven.

Side note...

Currently in #60 we are discussing how to establish a BUSL that meets the Fair Source Definition for my company. Is this intended to mean adopting a policy change which would prohibit our efforts to adopt Fair Source with the BSL?

In the other thread we are working through the details of how we can adopt a complaint BUSL and it sounded like the intent was not to change existing established policy on the fly, so I am assuming that was not what is intended here.

So my answer above is framed from the general standpoint not as it relates to our licensing because I obviously have a conflict on that question (as does Sentry due to the competitive code coverage offering)

[ezekg]

I realize the door is open to approving future licenses -- however there is a bit of a chicken and egg problem if new licenses can the approved until they are used by multiple companies and companies cannot be listed unless they have an approved license.

@chadwhitacre tbh, I think we may want to be a little more lax here until we have enough of a Fair Source license pool to meet everybody's use cases. The FCL didn't have any adoption outside of Keygen when it was added to the pool, and now—last I checked—there's ~10 active projects adopting it. I agree there's a chicken and egg problem, because FSL and FCL might not check everybody's boxes, and thus BUSL is the only approved alternative. Worth discussing imo.

[brynary]

@chadwhitacre tbh, I think we may want to be a little more lax here until we have enough of a Fair Source license pool to meet everybody's use cases. The FCL didn't have any adoption outside of Keygen when it was added to the pool, and now—last I checked—there's ~10 active projects adopting it. I agree there's a chicken and egg problem, because FSL and FCL might not check everybody's boxes, and thus BUSL is the only approved alternative. Worth discussing imo.

To just add on to this point a bit...

If getting a license approved for now was just a matter of it being assessed against the Fair Source Definition, that would make it more enticing to invest in the legal effort to craft one.

For our case, it would be something derived from FSL that cleanly DOSP's to GPL. I don't have data, but I suspect this would be appealing to other potential Fair Source adopters if they were aware of the option.

However, if the barrier here is investing in the legal bills to draft the license and potentially get stuck with a non-Fair Source approved license until a second adopter materializes, that makes spending the thousands of dollars on the license drafting significantly less appealing.

It's more important to us to be Fair Source approved than to have exactly the license we want, so the current policy encourages us to stay put on BUSL.