4 ms·

I find "open core" or source-available (with license allowing self-hosting and custom modifications) to be a good middle ground. It allows potential users to q

I find "open core" or source-available (with license allowing self-hosting and custom modifications) to be a good middle ground. It allows potential users to quickly try out the solution and prove its worth without having to first go through a (often months-long in big companies) procurement process. It also allows users to understand how the system works internally which can fill gaps in documentation or cover use-cases the original developer hasn't thought of. It can also allow them to fix bugs/edge-cases (that may not be in upstream as they are specific to a niche use-case) or to tweak the software to better fit their infrastructure. Finally being self-hostable automatically makes the software suitable for secure, potentially air-gapped environments or allows the software to be deployed closer to where the rest of the infrastructure is.

tracker1 3y ago
Disagree on source-available... if the upstream business dies, source available doesn't necessarily allow you to make adjustments or fix bugs should that upstream company go under, or just stop supporting the application/library/service you depend on.
- ezekg 3y ago
  What "source-available" license doesn't allow you to do that via a fork? I'd love to know. ELv2 allows it. BUSL allows it. SSPL allows it. Apache Commons allows it. People diss these licenses and they don't even understand them.
  - Nextgrid 3y ago
    To be fair, "source available" could also mean a fully custom license, closer to a typical proprietary closed-source license, except with "btw here's some source code, but you're not really allowed to do anything with it". Even in the above scenario, source-available is still better because you at least have the technical possibility of doing something with it, at the cost of potential litigation for breach of license.
    - ezekg 3y ago
      Yes, in theory. But in practice, I haven't seen a popular "source-available" license that limits your ability to fork. So making a blanket statement like that is wrong in practice, but people still tout it. That's the problem with the term "source-available" and why a lot of companies using these licenses avoid the term altogether.
      - Pannoniae 3y ago
        But if you say "open source" instead of "source available" then you get the OSI folks flaming you for not comforming to the definition. It's a lose-lose situation.
  - tracker1 3y ago
    My biggest familiarity with "source available" was some of the .Net stuff from MS before they fully embraced FLOSS for .Net language/platform development. Which was iirc, a look, but don't touch kind of thing. If you can fork and reuse, then "source-available" is probably a poor term for said license.
    - ezekg 3y ago
      > If you can fork and reuse, then "source-available" is probably a poor term for said license. I agree. Yet projects using said licenses get shamed into adopting the term "source-available" even though it doesn't fit, while "open-source" actually makes more sense in terms of communicating freedoms. It's all so ridiculous. Things need to change.
- Nextgrid 3y ago
  You at least have the technical possibility to do so - not the case with closed-source or even cloud-based systems. It may be a breach of the license, and it will be up to you to weigh the cost of potential litigation against the cost of stopping using the software immediately. Also note that fixing bugs/making adjustments doesn't mean releasing them - the latter may be a problem with some companies, but it's unlikely anyone would care (nor know about) if you do the former internally.

tracker1 3y ago

Disagree on source-available... if the upstream business dies, source available doesn't necessarily allow you to make adjustments or fix bugs should that upstream company go under, or just stop supporting the application/library/service you depend on.

ezekg 3y ago
What "source-available" license doesn't allow you to do that via a fork? I'd love to know. ELv2 allows it. BUSL allows it. SSPL allows it. Apache Commons allows it. People diss these licenses and they don't even understand them.
- Nextgrid 3y ago
  To be fair, "source available" could also mean a fully custom license, closer to a typical proprietary closed-source license, except with "btw here's some source code, but you're not really allowed to do anything with it". Even in the above scenario, source-available is still better because you at least have the technical possibility of doing something with it, at the cost of potential litigation for breach of license.
  - ezekg 3y ago
    Yes, in theory. But in practice, I haven't seen a popular "source-available" license that limits your ability to fork. So making a blanket statement like that is wrong in practice, but people still tout it. That's the problem with the term "source-available" and why a lot of companies using these licenses avoid the term altogether.
    - Pannoniae 3y ago
      But if you say "open source" instead of "source available" then you get the OSI folks flaming you for not comforming to the definition. It's a lose-lose situation.
- tracker1 3y ago
  My biggest familiarity with "source available" was some of the .Net stuff from MS before they fully embraced FLOSS for .Net language/platform development. Which was iirc, a look, but don't touch kind of thing. If you can fork and reuse, then "source-available" is probably a poor term for said license.
  - ezekg 3y ago
    > If you can fork and reuse, then "source-available" is probably a poor term for said license. I agree. Yet projects using said licenses get shamed into adopting the term "source-available" even though it doesn't fit, while "open-source" actually makes more sense in terms of communicating freedoms. It's all so ridiculous. Things need to change.
Nextgrid 3y ago
You at least have the technical possibility to do so - not the case with closed-source or even cloud-based systems. It may be a breach of the license, and it will be up to you to weigh the cost of potential litigation against the cost of stopping using the software immediately. Also note that fixing bugs/making adjustments doesn't mean releasing them - the latter may be a problem with some companies, but it's unlikely anyone would care (nor know about) if you do the former internally.