Consider adding BSD 3-clause as a change licence

[martintoreilly]

Hi, I came across this project while researching available licences that provide some mechanism to protect the reasonable commercial interests of the licensor while retaining as many of the freedoms of open source licences as possible. This looks like a useful refinement of the BUSL and could potentially be more appropriate for the use cases I'm considering.

I've read the discussion on the decision to limit available change licences to the MIT and Apache-2 licences in issue #4 and the FSL announcement post. However, for the use cases I'm considering, a non-endorsement clause is important and the BSD 3-clause licence provides this while otherwise granting the same rights as the MIT licence. I acknowledge that the Apache-2 licence includes non-endorsement terms in its trademark clause, but it also includes patent grants that could potentially be problematic for the use cases I'm considering. I acknowledge that the initial FSL licence includes patent grants, but I think there is a difference between granting these for non-competing usage under the initial FSL licence vs granting them for unrestricted usage under the perpetual change licence.

What are people's thoughts on adding the BSD 3-clause licence as a change licence option?

[chadwhitacre]

Thanks for chiming in @martintoreilly. Can you say more about your use cases for which non-endorsement is important and patent grants are potentially problematic?

[martintoreilly]

Sure. In terms of the non-endorsement aspect, I work for a research organisation and we generally look to make the outputs of our research available openly for others to reuse and build upon. However, we mostly develop code at the prototype or proof of concept level and so, in addition to making it clear that we don't offer any warranties for the code we share publicly, we also want to ensure that others don't lean on our organisational reputation when using our code for any high stakes purpose. We've historically used MIT as as our default licence but, as we have at times found ourselves producing code that is closer to "production", that non-endorsement element has become more important.

A good concrete example of this would be our Data Safe Haven codebase, which allows reproducible deployment of isolated secure project workspaces for working with sensitive data. We use this in production to support our own research, but the safety provided by these environments depends strongly on having an appropriate information governance regime around the deployment and management of the platform and the work that takes place on it. We're very happy for other organisations to leverage our work by deploying their own instances of our platform, but it would not be appropriate for them to say they are deploying / using "the Turing" Data Safe Haven as part of the assurances they provide about the safety of their deployed system, as that safety is critically dependent on them doing a lot of other things right.

[martintoreilly]

In term of the patent grant aspect, we regularly work with partner organisations to apply our research in real world use cases and, while in many cases we do agree to publish all code we generate as part of the collaboration under genuinely open licences, we occasionally have partner who have reasonable concerns about other organisations using the outputs of our collaboration to compete with them.

We've not had much luck persuading these organisations that copyleft restrictions are a suitable substitute for explicitly retaining exclusive rights to use code in their areas of commercial interest, and the lack of a good "standard" licence for this scenario has made it hard to include open licencing commitments in our collaboration agreement. I've been looking at the BUSL as a potential middle ground for this. However, the effectiveness of the BUSL in practically permitting others to use code in the initial BUSL licence period is critically dependent on being extremely clear about what is and isn't permitted using the additional usage grant. I worry that this will be hard to get right and, if open for negotiation with every partner, will effectively result in us collectively writing a custom licence for each collaboration. It's quite likely that we will fail to do this in a way that provides sufficient clarity for many potential users of the code base and, even if we do manage to do that, each potential user will need to get each custom version of the BUSL reviewed by their legal advisors

I see the FSL as solving this problem by providing a clear standard permitted usage grant that very explicitly reserves the minimum critical rights for the industrial partner and very explicitly grants the minimum critical rights for the research community, leaving all other uses as implicitly permitted as not "competing uses" (but contestable by the industry partner / off-putting to a potential competitor where those uses come uncomfortably close to current commercial interests of the industry partner).

I'm pretty hopeful that the FSL standard permitted usage terms are ones I could get industry partners to agree to, so the remaining challenge will be the fact that the licence reverts to a genuinely open one after 2 years. Patent grants are an even more challenging topic with these types of industry partner than software licences and I feel that giving up patent rights while also giving up the right to exclude direct commercial competition would be something these organisations would find challenging.

I think a potential approach that could work well here would be the combination of a non patent granting change licence combined with permitting continued use under the FSL terms as an alternative to the open licence (as also discussed in #20). Then people would have the option of non-competing use with patent cover or competing use without it. I'm very open to alternative suggestions, including arguments to use with such industry partners to persuade them the FSL is a good choice with the currently available change licences.

[martintoreilly]

I'm happy to use some of our current collaboration partnerships as concrete test cases for finding out what works for these organisations where, while they are not against open licencing, they are very wary about "giving away the crown jewels", and I see a lot of value in the FSL approach of tweaking a limited set of licence "configuration options" rather than the BUSL approach of supporting what amount to fully custom initial licences.

[martintoreilly]

By the way, I'm absolutely not looking to turn the FSL into something that makes it meaningfully worse at its original purpose. My starting view is it's always better to contribute to an existing endeavour and also that there's huge value in the community coalescing around a very small number of "standard" licences that organisations can become used to and that advice and legal opinion can accumulate around. I'm hopeful there's appetite for supporting this sort of rights balancing scenario in the FSL. However, if the view is that it's too orthogonal to the orthogonal goals of the FSL, just let me know.

[chadwhitacre]

Sounds like we share a view of BUSL as being too open-ended, and a goal for FSL of finding the sweet spot between standardization and suitability for multiple adjacent use cases. I'm glad you're here, and I'm hopeful we can find a good resolution here that allows you to adopt FSL. :-)

I'm happy to use some of our current collaboration partnerships as concrete test cases for finding out what works for these organisations

This sounds like a great opportunity! Can you send me an email? I'd love to schedule a call with you to learn more about your situation and come up with a plan that we can bring back to this thread for wider review. chadwhitacre@sentry.io 🙏

[chadwhitacre]

Gonna go ahead and close this one out, as it seems to have lost steam. We would need to see significant demand for BSD-3 over MIT before considering it more seriously.