Rest assured that Deno will remain MIT licensed. For Deno to grow and be maximally useful, it must remain permissively free. We don’t believe the “open core” business model is right for a programming platform like Deno. We do not want to find ourselves in the unfortunate position where we have to decide if certain features are for paid customers only. If you watch our conference talks, you will find we've been hinting at commercial applications of this infrastructure for years. We are bullish about the technology stack we've built and intend to pursue those commercial applications ourselves. Our business will build on the open source project, not attempt to monetize it directly.
> ... until the VCs change their mind or AWS uses our code to make more money than we do.
That is the correct answer.
Amazon (AWS) can lift Deno and use it as a service on AWS for devs and effortlessly compete, out scale and out do them 100 times over and supersede the Deno Company. Thanks to using the '...permissively free' MIT license (Being AGPL will also make no difference) AWS can do just that.
Just like how they did that to MongoDB, Redis and Elasticsearch who were all victims of Amazon's ruthless tactics on open-source.
I just don't understand this. This project uses distributed version control. This implies 2 things
1. It is impossible to delete every copy of this project. If the authors wanted to restrict access by taking the repo private, they can't. It will always be out there.
2. Every commit is licensed with MIT. So even if there is a licensing change, you have access to every commit licensed by MIT. You've lost nothing except rights to future work.
Even if they change their mind, you can still use their existing code to run your software. If it's popular enough to be forked by the community, you can use the fork if you prefer.
You only need to be concerned if you're heavily invested on their platform and it's not popular enough for community support and you need new features added. In this unlikely scenario, yes, you won't have any option but to buy in to their new business model.
"If it's popular enough to be forked by the community"
Yes.
And if it isn't you need to switch.
If you are tied in in a way to proprietary tools or APIs then you have some major migration in front of you. If you don't you you might be able to use Node.
If you have a tight schedule already, or no development capacity for the migration, you will need to buy a license because you might not want to run your code on a plattform that no longer gets security updates and you no longer get support.
When this happend to me in the past, I've got some major bills for licenses b/c most of them are server based (or core based) and also count development, testing, staging and CI servers (>$100k/y).
"You only need to be concerned if you're heavily invested on their platform and it's not popular enough for community support and you need new features added. In this unlikely scenario, [...]"
s/unlikely/likely/g
I have no data but would assume this is the default ending, because most projects are not being forked (Mongo, ...) and create a successful community around a fork and most companies I work with are heavily invested in a plattform and do not adhere to the standard APIs and tools (e.g. I'd say 10% of my customers use AWS in a standard way, 90% are heavily invested in the plattform, same for GCP.) If you have other numbers and/or studies, I would be interested.
If it is run by an established foundation like Apache with established procedures for how to manage large complex projects, then you can be sure that the project will remain open-source and usable for your purposes. Otherwise, I'm not so sure.
