4 ms·
Ask HN: Thoughts on Elastic V2, SSPL, or mixed software licenses?
Hey all, we’re launching our start-up next month and are planning to pick Elastic V2 as our software license.
Link to the license: https://www.elastic.co/licensing/elastic-license
Link to our project: https://github.com/ubicloud/ubicloud
A recent HN discussion: https://news.ycombinator.com/item?id=36971490
We’re choosing Elastic V2 for three reasons: (1) We’re planning to monetize through a managed service and we’d like the license to support that, (2) Later if we change our mind, we think it’s easier on our users if we go from a restrictive license to a more permissive one, and (3) The Elastic V2 license is much simpler than its cousin, Server Side Public License (SSPL).
That said, Elastic V2 is a new license and doesn’t seem to be as popular as SSPL. Also, some projects out there mix and match multiple licenses in their repo to be able to call themselves open source.
Any insights / feedback on Elastic V2 or software licenses in general?
- mindwok 3y agoIt's a tough balance, but I'm glad to see your company trying to get this right up front rather than pulling the rug later. My only concern with Elastic V2 is the vagueness of providing a hosted service to 'third parties'. There are some use cases where organisations might run a platform team that supports this for other teams, or if organisations have third-party contractors who use the service while engaged on work inside an org etc. I think it'd be helpful to make it more specific that the usage has to be commercially competing with your own managed service so you don't torpedo those kinds of internal use cases.
- ozgune 3y agoThank you for the input! I had a quick question. If we provided a dual license, Elastic V2 and SSPL, would that help? We're happy to clarify the meaning of third-party as "commercially competing with our managed service" once we have a website. Still, we likely won't edit the Elastic V2 license since it might risk creating a new obscure license.
- mindwok 3y agoI think that would potentially help, but there's still ambiguity in the SSPL that might scare off some parties. But at least the SSPL would cover customers who aren't making modifications to the source code, but using the platform internally, which I think would make this option safe for the vast majority of use cases. Another way you could approach this would be a permissively licensed free version and different licenses for paid versions (basically, open core). My company uses this model, and I think it works extremely well because it means that large regulated enterprises or government customers (who don't use SaaS services) don't feel any hesitation to adopt the free tier, and then when they're ready to pay, their use case of an internal platform is already supported under the higher-level enterprise licenses. No legal risks involved here. I think these customers would be extremely well suited to your product because these customers are very risk-averse and the promise of having a neutral cloud vendor with an open codebase means less risk of vendor lock-in or a commercial rug-pull down the line. So I would urge you not to leave them out! In my experience, vendors often treat self-hosted installs like this as second class citizens, but large regulated enterprise and government customers often can't use SaaS services and are an enormous market that will love you if you make this easy for them.