[the_mitsuhiko]

> It's pointless to call this anything other than source available.

I obviously strongly disagree with this. An FSL licensed project turns into full, undeniable open source after two years.

> Maybe we should call this a "you can have the scraps" license because the project only becomes open source when the developers stop caring about it.

Two years isn’t a lifetime. If there is value left the community has full rights to do something with it. No legal worries can stand in that way. You can even rebirth a new company from that if you so desire.

[networked]

"Source available; delayed open-source release" or "source available; delayed open source" is what I would call this kind of license. It accurately describes both the present and the future legal status of the code. I wouldn't use "delayed open source" on its own because it could be misleading. Since it omits the current status, people may believe "delayed open source" software is some kind of open source already.

I think I understand why you strongly disagree with the label. Those who call your license "source available" without qualifiers are, from your perspective, committing the noncentral fallacy (https://www.greaterwrong.com/posts/yCWPkLi8wJvewPbEp/the-non...). While your license is technically "source available" according to the Wikipedia definition, it is not a typical example of a "source available" license, which usually doesn't grant additional freedoms over time and doesn't become free-as-in-freedom. I don't really see a fix. The difference between "technically category X" and "typical of category X" is an eternal universal source of bitter conflict. The best advice I can give to people embroiled in one is to care less about "technically category X" if at all possible.

Besides inventing a new label and adding a qualifier like "delayed open source", one admittedly unlikely thing licenses like FSL could try is to "reclaim" "source-available". It doesn't have to mean "a megacorp lets you peek at the code if you agree to not use it for anything interesting". The typical expectations of a source-available license could shift to less onerous and less restrictive.

[James_K]

> FSL could try is to "reclaim" "source-available"

All the adults in the room realise that "source available" is just an accurate descriptor for what they do, but sentry won't accept anything without the term "open source" in it. They view themselves as open source and the fact that they don't use an open source license is merely an incidental thing they do to deal with some of the challenges of being open source. Instead of admitting their position, they seek to change the definition of open source to match what they are doing.

> The best advice I can give to people embroiled in one is to care less about "technically category X" if at all possible.

I think there is nothing technical about FSL being source available. Open source is about being communally built and communally owned. Everyone contributes and everyone is free to profit. By contrast, this is a license where everyone is free to contribute but only the owner is free to profit. The only difference is that two years after the owner stops profiting, the software opens up to everyone else.

Source available is honestly better for everyone than closed source, and sometimes even better than open source. The only really bad thing you can do is use a source available license while misleading people into thinking you're open source, because you are taking their work under false pretence.

https://open.sentry.io/

[networked]

> I think there is nothing technical about FSL being source available.

Note that I used "technically" as the opposite of "typically". My suggestion is to care less about being in a category you don't want to be in when you are different from its representative members where it matters to you. (In this case the category is source-available licenses.) Focus your advocacy on how you differ instead of arguing membership. ("Yes, we are a source-available license. Don't let it turn you away. There are critical differences between us and source-available licenses you don't like. We are better than old read-only and new Commons-Clause licenses because..."—not literally this, but that's the idea.)

[James_K]

Yeah, but my point is that they are the typical example. They are a company who wants to release their software to give users a peek inside without opening it up to competition. Hence they invented a license to let them do that, and provide the additional guarantee that users can service the software themselves if Sentry ever stops supporting it (after two years). Their motivation is literally the exact thing that motivates every other source available company. If anything, the FSL is closer than the BSL to the platonic ideal of a source available license.

EDIT: having read through the two licenses, I'm actually convinced that the FSL might be less permissive than the BSL in its intended use-cases. The BSL effectively becomes open source whenever owner stops providing the software commercially (rather than 2 years after) which guarantees that there will never be a time where the service is unavailable (if I'm interpreting it correctly). BSL includes a provision saying that a product is defined as competing based on the date of its release, rather than FSL which might allow the licencor to release new services that make someone else's retroactively competitive. It also isn't clear about free offerings, where the BSL expressly permits any non-paid services.

[networked]

The business goal of FSL seems typical enough. The reason I brought up the typical and atypical distinction was something other than the company's motivation.

It seems the_mitsuhiko rejects the label "source-available" because FSL software becomes free. That's different from most other source-available product licenses. (I don't have statistics; this is my impression.) In this sense FSL and BSL are similar enough to each other and both atypical. So, if this is the_mitsuhiko's objection to the label, he can credibly claim FSL to be different from a regular source-available license where it matters to him. (As I said, IMO a better approach than disputing the label.)

> without opening it up to competition.

I wonder about that. In many markets you can probably compete using a competent fork tracking a two-year-old version of a market leader. Even integrations shouldn't be too much of a problem if the market leader naturally avoids breaking the API.

[James_K]

> Two years isn’t a lifetime.

It is in software development. You don't even deny that the project stays source available while developers care about it.

> If there is value left

So, once you've extracted as much value as you want from something, the community is free to have whatever's left? I think "you can have the scraps" is an excellent summation of that philosophy.

[pas]

in many fields it's really not that long. it might be a hundred years in JavaScript framework land, but it's nothing in enterprise/government/medical/industrial/built-infrastructure.

temporary monopolies are a trivial "solution" for the economic incentives problem, but of course it's not not really a great one. discontinuities usually cause their own issues, and even 2 years of vendor-lock-in can do nasty things to an OpEx budget.