IME, HN tends to use the term open source in two senses. It can either refer to:
- the license or;
- the business model.
And we know that licenses exist on a spectrum of permissive to restrictive.
So when the community is presented with a for-profit entity in a Launch/Show HN, they tend to dwell on the 2nd sense.
If it’s a side project that’s on display, then the 1st sense kicks in.
Based on this, I’d like to offer the following colloquial interpretations for the terms you mentioned.
1. Open source: permissive (or more correctly, well-known) licenses like MIT, Apache, BSD, GPL, LGPL etc that do not prohibit commercial derivatives (or prevent cloud hyperscalers like AWS from using it).
2. Open core: our code is split into 2 parts: the open source bit (often under a permissive open source license in #1) to attract fellow devs and the closed source bit. The closed source bit is how we plan to make money.
3. Source available: we plan to make money however we see best so as insurance, our code can only be available under an obscure license that was designed to be restrictive.
So, I think what’s really happening is that labelling something “open source” will cause the community to quickly to point out that said license is restrictive.
(Here is an example from another post on the frontpage where the community is engaging in the 1st sense on a side project: Show HN: Little Rat – Chrome extension monitors network calls of all extensions
IME, HN tends to use the term open source in two senses. It can either refer to:
- the license or;
- the business model.
And we know that licenses exist on a spectrum of permissive to restrictive.
So when the community is presented with a for-profit entity in a Launch/Show HN, they tend to dwell on the 2nd sense.
If it’s a side project that’s on display, then the 1st sense kicks in.
Based on this, I’d like to offer the following colloquial interpretations for the terms you mentioned.
1. Open source: permissive (or more correctly, well-known) licenses like MIT, Apache, BSD, GPL, LGPL etc that do not prohibit commercial derivatives (or prevent cloud hyperscalers like AWS from using it).
2. Open core: our code is split into 2 parts: the open source bit (often under a permissive open source license in #1) to attract fellow devs and the closed source bit. The closed source bit is how we plan to make money.
3. Source available: we plan to make money however we see best so as insurance, our code can only be available under an obscure license that was designed to be restrictive.
So, I think what’s really happening is that labelling something “open source” will cause the community to quickly to point out that said license is restrictive.