fsl.software

> Source-available under the Functional Source License v1.1 (FSL-1.1-MIT). Free for any non-competing use; converts to the MIT license on the tenth anniversary of each release. See LICENSE. You should not use the FSL name if you change the date of the license switch, which is originally set to the second anniversary. If you want to change that duration, you should use a different name to avoid confusion. Sentry intended for the FSL to be specific rather than general. The company's Deputy General Counsel stated: > TLDR, FSL is narrow in scope for a reason. > You're free to create your own license based on the FSL with AGPL as the change license if you rename it so that it isn't confusingly similar. https://github.com/getsentry/fsl.software/issues/53#issuecom...

The not-quite-Apache-2 "Fair Source License, Version 1.1, ALv2 Future License" (https://github.com/getsentry/fsl.software/blob/main/FSL-1.1-...) includes the Apache 2 patent grant. That grants you conditional permission to use the software in ways that would, without the grant, infringe upon their patent. One of the conditions is that you may not make a claim against any party that the software infringes upon any patent, or else your patent grant is terminated. Unfortunately, the license actually in the repo is not even a not-quite-Apache-2 license. It doesn't appear to be FSL-1.1-ALv2 at all: https://github.com/statewright/statewright/blob/main/plugins.... This notably does not include the patent grant, which makes it unclear whether use of the software would infringe upon the patent.

It grants them a two-year headspace in which licensees are prohibited to create a competing offering based on the open sourced code—so e.g. Amazon can't just take the source code and create a paid offering within AWS without contributing to upstream—at least for two years after officially licensing the software. You can read the FSL license text here: https://github.com/getsentry/fsl.software/blob/main/FSL-1.1-... Sounds like a reasonable tradeoff to ensure companies don't have immediate disadvantages from open sourcing their code.

IANAL, but on a cursory read, this seems like a minefiled for use in a commercial settings: the definition of "Competing Use" in the license (https://github.com/getsentry/fsl.software/blob/main/FSL-1.1-...) can be read very broadly.

1. You can read more about the Fair Source initiative here: https://twitter.com/chadwhitacre_/status/1790101820364267902 (also [0] and [1] for previous discussions). It's not official yet, but it's an attempt to define a new term for Open Source vs Source Available. I figured I'd start using the term early and see what happens. 2. Yes, the ELv2 will be considered a Fair Source license, because it allows contributions, redistribution, forking, etc. You can visit https://faircode.io for an idea of what Fair Source will ultimately entail (Fair Source and Fair Code will be merged eventually AFAICT). [0]: https://github.com/getsentry/fsl.software/issues/4 [1]: https://github.com/getsentry/fsl.software/issues/2

Just heard about the new FSL. A simple question: I found out the drafting process is publicly accessible on GitHub [0], but it seems that most of the collaborators are not lawyers. Has the license been lawyer-reviewed? [0]: https://github.com/getsentry/fsl.software/issues/4

It feels like you intentionally omitted his immediate follow-up to your quoted comment: > > my theory about embrace/extend/extinguish seems to be as accurate as I thought. > This is confused. Embrace/extend/extinguish means to initially participate in an open standard and then extend the standard in such a way that the non-extended version is sidelined. I'd encourage people to read the entire thread rather than seize on the cherry-picked comment, additionally loaded with terminology like "they want to destroy open source", which doesn't appear in the original thread. I can't speak for whit537, but I do work at Sentry, and I feel your comments about our intentions are disingenuous. We are open in that we feel the existing models don't fit our needs, and we're trying to evolve the language to make non-compete licenses more approachable and

> The main issue of such a license is that you can't fork the project when they go in a direction that you don't like. As long as it's not a Competing Use, yes, you can [0]. I don't get why so many people think you can't fork a project that uses BUSL, SSPL, ELv2, and now FSL. Just like any other OSS licenses, you can fork. And you just like any other OSS fork, you can't relicense. It's obvious people don't actually read the license. [0]: https://github.com/getsentry/fsl.software/blob/main/FSL-1.0-...

FSL has less ambiguity when compared to BUSL. Each use of BUSL is essentially its own unique license due to the variable Additional Use Grant. For example, a company could not pre-approve BUSL as an acceptable license for the company, because all BUSL licenses will have a different Acceptable Use Grant. On the contrary, FSL is a new license that can be pre-approved since it has no variables. It's an improvement upon BUSL. I personally like it, although I won't be moving from ELv2 to FSL due to another reason [0]. [0]: https://github.com/getsentry/loose-confederation/issues/4#is...

https://github.com/getsentry/sentry/pull/60144 -> https://github.com/getsentry/sentry/blob/d4d89e2fa93ad99f13d... If they're going to all this trouble for "ambiguity," I don't know why they wouldn't further extend their custom SPDX identifier to include the "2 year" rollover, since that's one of their pearl-clutching reasons for this bullshit: https://github.com/getsentry/loose-confederation/issues/4

Cross-posted at https://github.com/getsentry/loose-confederation/issues/4#is.... ;-) One of our goals is to keep the parameters to an absolute minimum, to aid in adoption. The simpler we can keep it the more easily it will get picked up, is the thinking.