The rest of the code is still MIT licensed. And if you remove the ee/ folder, the project would work without any issue
This licensing model is very similar to what folks like Gitlab and PostHog do today
The rest of the code is still MIT licensed. And if you remove the ee/ folder, the project would work without any issue
This licensing model is very similar to what folks like Gitlab and PostHog do today
From the website: "Why get locked-in with SaaS vendors like DataDog when you can use Open source?"
You expect users to trade one form of lock-in for another one?
We are natively based on opentelemetry which is emerging as the industry standard for instrumentation. So, you can change product you used for backend and visualising and storing your telemetry data very easily
- Open core means no direct path from testing to using (and paying). If I want to make a case for a software to be included in our stack I don't want to constantly run into paywalls while trying out the product but I also don't want to go through the hoops of getting a licence (because of internal bureaucracy).
- You steer away users that cost you nothing but help you spread to word and report issues and might even provide a PR. I'm talking about OpenSource Projects, student organisations and companies with limited resources (NGOs, early stage startup's). I used to be head admin in a student organisation. We developed our own internal tools and only relied on open-source components. I know of at least two cases where other students got to know the tools and after they finished university joined companies and introduced the very tools we used to their employees resulting in paid support contracts.
- It creates tempting opportunities for investors to force you into ruining the open source tier. In the beginning you only have features behind the paywall that are useful to big enterprises but if your business is not growing fast enough (from the perspective of investors) they might force you to push more users to be paying customers. That might help in the short term but will ruin your reputation in the long run.
- Paying for services (aka insurance to get help if something goes haywire) is easier to justify with execs then paying an unreasonable amount for that one feature that is behind the paywall. ("Can't you just make it work without it"). Its a purely psychological argument but decision processes in companies are not always rational and your allies are the devs and you should be helping them make a case to buy your product.
If I want to make a case for a software to be included in our stack I don't want to constantly run into paywalls while trying out the product but I also don't want to go through the hoops of getting a licence (because of internal bureaucracy).
Yeah, understand the use cases you are pointing to. We are planning to introduce a foss only version of the product for users who know that they won't be need the enterprise version. It will not have any enterprise bits, and you could just keep using it as you want. Something similar to this - https://github.com/PostHog/posthog-fossFirst, AGPL only requires to release changes ONLY to the existing AGPL codebase and ONLY if you are providing it as a network service.
Second, the whole idea of virality is a huge misnomer. There is no such thing as one thing "infecting" another in copyright law. GPL/AGPL cannot magically make another piece of software change license.