[Lutger]

I disagree. For an open core product the core is actually open source. You can fork it, change it, distribute it. It may have an OSI approved license. You can't do that with a source available product.

Furthermore, you can't even talk about the open core as a part of the closed source product, because the open core application is invariably a whole in and of itself. You could theoretically fork it, improve on it and it could have a life on its own as a 'fully' open source product. You can even make it incompatible with the closed version.

[ezekg]

> You can fork it, change it, distribute it. It may have an OSI approved license. You can't do that with a source available product.

Small correction: under popular source-available licenses like the FSL, BUSL, and ELv2, you can fork, modify, and redistribute. These licenses are usually just concerned with cloud competition, which is none of those things. You can still fork, modify, and redistribute your changes, with no copy-left strings.

Still not Open Source like AGPL, but just wanted to clarify. :)

[Lutger]

True, I'm not sure I would say these are source-available, but I'm a bit out of touch regarding the jargon around these clauses that guard against cloud competition.

There's a big difference between 'you can look at the source but not use this product in the way it is intended if you make money by doing so' (production use), and 'you can use the source in any way you like, also for production, but not to compete with us'. I've always understood 'source-available' to mean the former because it used to be like that, and the latter to be a slightly restrictive version of open source. Historically, the latter variant also emerged out of competition with the big clouds (mostly AWS), from projects that used to be truly open source, whereas a lot of what I think are source-available licenses come from vendors that were fully closed before or would be if there was no demand to see the source (for example, for security purposes).