[Business Model] How vike make money and having plan for long term support products - Serious questions

[harrytran998]

Hi, Vike's team; I will straightforwardly explain the problems I want to clarify to make it easier to decide on them.

Remember that I'm not a personal attack here; I want to be clearer for me or anyone who can make the right decision for us and the community.

1. How could you define "large company"?
2. You know that we can easily patch the Vike source code and use that for free, so how do you have a plan or vision for this?
3. As I see, the business model becomes mainly B2B, so do you know what exactly B2B enterprise companies need?
   I'm a lead FE for cross-team and using microfront-end for our apps. And in the current state of Vike, I think we will not choose Vike for some reason like:

• If CSR, Vite React, or RsBuild React is enough, we don't want to separate our FE technology into multiple FE frameworks, so Vike has no advantage in this use case.
• If SSR is just for some landing page for marketing stuff, another framework like NextJs, Remix, or Tanstack Start can easily archive this thing - for FREE, and they are backed by giant funds or having "great business" to make money!

4. You know that "Ruby and Rail" or Lavarel always develop their products based on those things --> So they can easily have the "resources" to develop the tools incrementally. But with Vike, I don't see anything built with this; I can leverage this and become the "special" one in the multiverse meta-framework.
5. The reality is always harder. I knew Vike Org had around 650$/month from sponsors, and they can disappear at any time; you cannot control that. So, what do you guys do if your organization is out of money? You are the only person in the codebase who contributed ~12k commits. Other folks seem quite Vike or inactive in the Vike codebase. Like @nitedani or @lourot...

Thank you for reading the long long sentence here. Really appreciate the Vike team creating great tools 🙏. If everything becomes clearer, and that will benefit me in the future for enterprise apps, I will pick Vike for cross-team in my company, and I am willing to pay if Vike has a lot of benefits for us, which another framework can't.

[brillout]

1. So far the plan is to look at the number of non-negligible Git authors.
2. We make it difficult to find.
3. We do know to some/limited degree, and we'll further figure it out as we grow. The new business model is actually beneficial in that regard, as it will increase our focus on enterprise users.
4. I'm not sure what your point is. Vike is used in production by a significant number of large companies.
5. Precisely, it's also about giving confidence that we'll stick around.

We do expect a drop in user adoption, but we aren't interested in building the next gratis framework. We want to build a framework that systematically solves real enterprise problems and we can't wait to iterate on that.

[haltcase]

Regarding "non-negligible Git authors", how do you suppose automated contributions like Dependabot or Renovate fit into that methodology?

[brillout]

Automated commits won't count toward the number of significant Git contributors.

[pketh]

For context, the app that I'm considering adding vike to (https://github.com/kinopio-club/kinopio-client) is primarily made by me and one secondary contributor. Although it's received small PRs in the past from other people.

from https://vike.dev/pricing#how-does-it-work :

For larger projects, Vike shows a pesky toaster Get your license key at ... in development (it's never shown in production) that you can remove by purchasing a license key

I get the definition of larger projects is non-negligible Git authors , but how is the visibility of this 'pesky toaster' determined? Does vike contain code that evaluates my codebase or githistory to determine this?

[brillout]

With "non-negligible contributors" we mean contributors that seem to be full-time employees (commit regularly over a long period of time). Consequently, PRs and small contributors won't be counted.

The overall goal is to show the pesky toaster only to companies that seem to have full-time employees and use Vike to develop non-minor apps. Since we'll use heuristics we might have false positives, in which case you'll be able to ask for a free license key. The license key unlocks your domain name.

We'll be generous about giving out free license keys — we'll just quickly check your domain name. (We'll only reject if, for example, the domain name is for a company that is actively hiring Software Engineers.)

For example, if your organization is a large non-profit OSS project that doesn't remunerate its contributors, then we'll give a free license key. (However, if the non-profit does remunerate engineers, then we consider that it has enough financial resources to pay for Vike.)

Does vike contain code that evaluates my codebase or githistory to determine this?

Everything is done offline, and nothing is sent to any server. Your privacy is fully respected, just like other open source tools.

So far I think reading the Git history (i.e. the .git/ directory) will be enough, but the vike package might also use other metrics, such as the number of routes and files. Anyways, whatever heuristic we end up using doesn't matter much to the user: you can always ask for a free license key if the heuristic doesn't work for you.

Let me know if you still have questions.

[pketh]

That all makes sense but for

reading the Git history

So it sounds like vike will have code that evaluates my repo (offline) and then shows the license stuff right ?

[brillout]

Yes: the pesky toaster is shown only if the offline heuristic guesstimates that your code is part of a larger company project.

If you see the pesky toaster, you have two options:

• Ask for a free license key, if your organization doesn't remunerate its engineers.
• Pay as much as you can, in a the form of a GitHub sponsorship (or other alternatives such as Open Collective, invoice, etc.).

If you end up sponsoring $2/month we'll take that as a signal that our offline heuristic didn't work. Ideally, users would rather ask for a free license key (we'll dig why our heuristic failed).

Thank you for your questions (let me know if you have more!). I'll be updating the Open Source Pricing page.

[kocv59]

We weren't approved to use Vike because the company doesn't approve the git history and project being analyzed (I know it's offline). I don't think we can maintain a fork to remove the license check and use the fork how they want without worrying about licenses.

I think Vike would be a great tool and I will try to get approved again. For now what can I try that is like Vike? Astro is good but doesn't support Vue templates for SSR on backend.

[brillout]

Thank you for reaching out about this.

I understand that companies are reluctant to trust the Open Source Pricing, and we care a lot about building trust.

For now what can I try that is like Vike? Astro is good but doesn't support Vue templates for SSR on backend.

Other than Nuxt, Astro, and Vike, I ain't aware of any other Vite-based framework that supports Vue.

And, yes, Astro has quite a different philosophy than Vike.

the company doesn't approve the git history and project being analyzed (I know it's offline)

If you have a license key then everything works just like any other open source tool.

So an effective way to get rid of tracking is to sponsor — we'll give a license key to all our sponsors before we release the first version containing the Open Source Pricing mechanism.

Also, we're going to offer the possibility to purchase a lifetime license that you pay only once. (We're going to update the vike.dev/pricing page in the coming weeks to include that offer.)

I think Vike would be a great tool and I will try to get approved again.

Let me know if you believe there is anything we can do to help you get approved.

We wouldn't do the Open Source Pricing if we didn't believe that it's a great approach for users.

[brillout]

Let me know if you believe there is anything we can do to help you get approved.

For example, there is an argument to be made that Vike is actually more economical than alternatives, considering for example that Next.js is hard to self host (e.g. Next.js's deployment skew protection only works with Vercel), and Vercel deployment known to be very expensive.

No framework is truly free — they’re all developed by teams funded by companies that control the roadmap with biased incentives.

[kocv59]

The company doesn't want to add this kind of licensing to the software so it will be Astro used for now.

[brillout]

The whole code is still 100% MIT licensed.

Seems like the bottom line is that your company simply doesn't want to pay. If you don't need the added value of Vike compared to Astro, then it make sense.

[brillout]

Btw, Astro took money from investors, so it's pressured to make massive revenue — users will end up paying one way or another. I'd argue there's more uncertainty in that than with Vike's Open Source Pricing.

[rogeriocosta-mb]

@brillout and team, first off, thanks for the amazing work with Vike, my team finds it super useful. We would love to sponsor the project to show our appreciation. Unfortunately, we can't use the built-in GitHub Sponsors feature because our corporate account is managed externally which restricts us from making payments that way.

We know it's not a large amount, but we believe in supporting the tools we rely on. Could you let us know if there are any other platforms or methods we could use to send a monthly contribution?

Thanks again.

[brillout]

If we provide a Stripe checkout, would that work for your company? It would then work just like any other online purchase e.g. SaaS.

[brillout]

(Thank you for reaching out and the kind words 💚)

[rogeriocosta-mb]

That sounds like a good option. I just need to run this by our finance team to understand how they will operate this. I'll reach out again as soon as I have an update from them.

Thanks again 🙂

[rogeriocosta-mb]

@brillout the finance team replied about the need of an invoice so they can link the payment. They never used a Stripe checkout to so they need to validate how it will work for them. Can you contact me in pvt to provide me the Stripe checkout? :)

[brillout]

I believe Stripe sends an invoice after checkout, so that shouldn't be an issue. We didn't implement the Open Source Pricing yet, but I'll let you know as soon it's implemented and I'll send you the link to the Stripe checkout.

[EduardoAC]

I wanted to provide context for my feedback rather than simply downvoting. I recently discovered this repository while researching alternatives for adopting Nuxt.js patterns in our application without requiring a full re-architecture. This search initially led me to vite-plugin-ssr.

After exploring the project, I have some concerns about the business model that I wanted to share constructively:

Context:
I currently work within an organisation of 600+ engineers, and we're evaluating solutions for our team. When assessing tools, we consider both technical fit and alignment with open-source principles that have historically driven innovation in our ecosystem.

My observations:

The commercial model here feels different from what I typically encounter in open-source projects. Projects like Linux, Vite, and Git have demonstrated that community-driven development can thrive without paywalls. While I understand that commercial services like prerender.io exist and serve a purpose, they position themselves clearly as commercial products from the start, which helps teams make informed decisions.

Specific concerns:

1. Open-source definition: The licensing model appears to diverge from traditional open-source standards
2. Value exchange: The emphasis on monetisation feels different from the community-first ethos that typically drives OSS adoption

A genuine question:
I'm curious about the sponsorship model for the project's dependencies (pnpm, playwright, vitest, etc.). Understanding how you support the ecosystem you build upon would provide helpful context for your approach.

To be clear:
You're transparent about your model, and ultimately it's your prerogative to structure the project as you see fit. I'm simply sharing feedback as someone who was initially excited about the technical solution but had reservations about the commercial approach.

I'd be interested in understanding your perspective on balancing sustainability with community access.

[brillout]

Thank you for reaching out, Eduardo.

The reason we developed the Open Source Pricing (OSP) is precisely because we love open source. We asked ourselves: how can we design a business model that preserves open-source values?

With the OSP, Vike stays 100% open source (MIT license) and 100% accessible (everyone can use it). See: https://vike.dev/pricing#how-does-it-work.

The last point is often overlooked but also important to us: we believe students and users from developing countries should be able to use software as freely as possible.

For companies, the big upside of the OSP is that it guarantees Vike's interests are aligned with its users — otherwise frameworks naturally become out of touch with their users.

One thing we haven't publicly shared yet: companies will be able to purchase a perpetual license — you buy it once, and it's valid forever. This gives companies peace of mind, knowing that Vike will always work like any other open-source project.

how you support the ecosystem you build upon

We plan to forward some of the revenue to our dependencies. And, I think that's even more important, we're eager to share and collaborate — see, for example, https://vike.dev/blog/photon#why-photon.

Projects like Linux, Vite, and Git

Projects like Linux and Node.js are infrastructure projects — companies like AWS finance their development because they have a tight-knit dependency and interest in them. Such projects can be seen as B2B markets with financial partners.

Financial partnerships are much less viable for frameworks, which are more like a B2C market.

Vite is also an infrastructure dependency for Vite-based frameworks (some of which sponsor Vite, and we plan to as well). But that isn't enough, so Vite recently raised a significant amount of money from investors — because Vite-based frameworks don't generate enough revenue to substantially sponsor Vite.

---

Does that answer your questions? Let me know if anything is still unclear.

Nuxt.js patterns

Feel free to elaborate if you'd like feedback on that.

[EduardoAC]

Thanks for taking the time to reply and for engaging with all my previous points.

I think we may have different interpretations of what “open source” means. For me, it includes being free for everyone to use — individuals and companies alike. With that in mind, would you say Vike qualifies as open source under that definition?

Projects like Linux and Node.js are infrastructure projects — companies like AWS finance their development because they have a tight-knit dependency and interest in them. Such projects can be seen as B2B markets with financial partners.

That’s a fair reflection of where things stand today, but they didn’t start out that way. Early on, these projects were driven by people who simply wanted to build something better and believed in the value of sharing it openly.

I’ve always loved the history of Git because it captures that spirit so well. Git was created in April 2005 after the Linux kernel team lost access to the free version of BitKeeper — their primary source control tool at the time. When BitKeeper’s owner tightened the licensing terms, the kernel developers could no longer rely on it. Linus Torvalds didn’t want the project to depend on a proprietary tool that could be taken away again, so he built Git.

I personally think that this doesn't really reflect the nature of open-source MIT license. Nevertheless, this is just my personal take and potentially feel differently about it's if the license was actually BUSL.

Thanks for taking the time to have a open discussion about this topic.

[brillout]

When BitKeeper’s owner tightened the licensing terms, the kernel developers could no longer rely on it. Linus Torvalds didn’t want the project to depend on a proprietary tool that could be taken away again, so he built Git.

The other reason why he built Git is because all version control tools were bad, especially for large projects like Linux.

If something as good as Git already existed and he just had to pay a couple of hundred dollars to purchase a forever license, he would most likely have done that. (He says himself that he built Git not because he wanted to, but because he didn't have a choice.)

I don't think it's whether it's 100% gratis that matters — what truly matters is 100% accessible.

I want everyone, regardless of financial resources, to be able to use Vike. That's why we're setting up a generous gift program: if a company doesn't have the resources to pay for Vike, then they can apply for a free forever license. For engineers (and small teams), Vike stays 100% gratis, and no license key is required — it just works like a regular open source project.

What is also clear: it isn't okay for companies who have enough resources to pay large teams of engineers (very expensive) but aren't willing to pay a single dollar for Open Source.

I empathise with companies that must save as much money as possible — building companies is rough.

The deal is this: as a company, you pay a small amount and, in exchange, you get a significantly more reliable tool.

---

believed in the value of sharing it openly

That was actually a major motivation for designing the Open Source Pricing, see https://vike.dev/pricing#why-not-another-business-model.

The neat thing here is that Vike's source code remains 100% MIT-licensed (i.e. open and forkable), whereas with the Open Core model, some of the code is closed source and isn't available for individuals and teams that don't have enough financial resources.

I honestly think that the Open Source Pricing is the best model in terms of values. Beyond values, we care a lot about collaboration (e.g. Telefunc can be used with other frameworks) — which is actually even more important than having MIT-licensed code if you ask me.

---

I spoke to many framework authors for whom making money is a big problem.

A framework can remain 100% gratis by using a mix of company generosity, advertisement, and skewed interests — but it's problematic:

• Skewed interests — this one is obviously bad (manipulative, sometimes borderline scamming), and at the end of the day you'll end up paying more.
• Generosity — it's fragile: in the next economic downturn shareholders will pressure the CEO to cut expenses that aren't beneficial.
• Advertisement — it only works with extremely popular tools (with relatively low production cost).

For users, generosity may seem the most appealing, but I think it's a mistake. Beyond fragility, I think what's worse is that generosity makes a project dull — being hungry is paramount for building something great. (E.g. many people winning the lottery end up weak and unhappy; it can be a dangerous "drug"). I don't want to build something that survives only because someone has been generous — I want to build something great that companies are willing to pay for. It's a direct, clear, and healthy relationship with users.

We think the Open Source Pricing is an elegant solution to the problem. Our goal is that companies will eventually see it as a feature, not a bug — for large projects, stability is much more important than saving a little bit of money.

Our passion is to build great and robust infrastructure that will last decades, not the next free thing that won't survive the next economic downturn.

More questions welcome — happy to answer them.

[redbar0n]

When BitKeeper’s owner tightened the licensing terms, the kernel developers could no longer rely on it. Linus Torvalds didn’t want the project to depend on a proprietary tool that could be taken away again, so he built Git.

@brillout I think a selling point here could be to give guarantee that the license won’t be changed from MIT in the future. It would give some reassurance for this eventuality/risk. But it may not be necessary, so I’d talk to the companies you’re talking with to hear if it would affect their decision (or if they deem that they could just fork an existing MIT licensed repo before the version with a license change, if that is even possible).

[brillout]

@redbar0n Good idea & will do 🙏

[Uzume]

The term "Open Source Pricing" is going to confuse and push many people away as they will associate it with proprietary pay software instead of what it is. Since this is really free and open source software under MIT licensing, this mean this monetization scheme amounts to optional/suggested "sponsorship pricing". If you really want to keep all the words of "Open Source Pricing" change it to something clearer like "Open Source Sponsorship Pricing".

As for the heuristic to recommend/nag for sponsorship, perhaps you should consider an AI-based approach so it can learn over time.

[redbar0n]

yeah I know, but I figured that could be left as a detail (not everything needs to be in the name, just enough to get a rough idea), since sponsorships already implies it will be supported by companies (and the details specify how).

[redbar0n]

if you really want to force companies to pay, then maybe MIT license is not a good fit? Since then you don’t really force them (they could always apply a patch to releases, and otherwise do as they will without the potential consequence of license breach litigation). But on the other hand if sponsorships are merely strongly encouraged (if they really care about getting rid of the nagging toast), then maybe «with sponsorships» is fitting.

[brillout]

Many companies are wary of unknown licenses — it would massively increase the adoption hurdle.

I'd rather be upfront and clearly mention Pricing instead of using ambiguous terms. It erodes trust when we aren't crystal clear.

Actually, the current model as documented at https://vike.dev/pricing is a bit complex and requires brain power to be understood. That's why we're actually considering going ahead with a fixed pricing (a fair, well-balanced pricing, with a generous free tier and clear progressive path, ensuring Vike remains >99% accessible).

[redbar0n]

Many companies are wary of unknown licenses —

Yeah, I can see that. Especially if a legal/compliance dept. needs to be involved before the engineer can start using it.

I'd rather be upfront and clearly mention Pricing instead of using ambiguous terms. It erodes trust when we aren't crystal clear.

I agree. Open Source is a too ambiguous term. I would just have: a GitHub link (implying source is available) + clear license + pricing page.

(Maybe Vike could be provided under two licenses, aka. "dual-license": MIT for individuals + separate license for companies. The license that applies to companies should be standardised, so that it can be used by other libraries/frameworks and become commonplace, so that compliance/legal departments can blanket approve it instead of having to individually review it for every library/framework.)

I actually think https://vike.dev/pricing is really clear, especially the graphic at the top.
Where it turns to cognitive overhead / complexity (for me) is the "Who pays and how much?" section, imho. I would remove it altogether (at least hide it in an expanded section or bottom of the page, because now it seems like required understanding, even though it isn't, and it raises questions that complicate matters: definitions, enforcement, limitations etc.). If you remove it, then you don't provide an anchor for what the companies would choose to pay (which may very well be much higher than what you recommend), and thus you lose out on that potential learning.

I actually really like Vike's price philosophy, and would love for it to be demonstrated to work out. But I also understand if you don't want to innovate in that extra dimension, which (while the learning could be useful), also carries some risk.

[brillout]

The license [...] should be standardised, so that it can be used by other libraries/frameworks and become commonplace, so that compliance/legal departments can blanket approve it instead of having to individually review it for every library/framework.

Yea, ideally a commonplace minimal addendum to the MIT license would do the trick. But it will take a (very) long time until we get there (and only if other projects also adopt the Open Source Pricing).

So it's going to be 100% MIT license (zero modifications) for a long time.

Where it turns to cognitive overhead / complexity (for me) is the "Who pays and how much?" section, imho. I would remove it altogether

👍 Done, it's removed now that we switched to a fixed pricing.

I actually really like Vike's price philosophy, and would love for it to be demonstrated to work out. But I also understand if you don't want to innovate in that extra dimension, which (while the learning could be useful), also carries some risk.

I'm glad you like it, and we do want to innovate in that space. We're obsessively thinking it through, and I'm proud of our latest design. It's paramount for the future of Vike, if not Open Source in general.

[Uzume]

Well in my mind "Open Source Pricing" and many of the other wording implies paying for open source but open source often means free and open source where "free" means freedom implying that though one can charge a price for it but anyone that has access to it can then turn around and do the same at any price including zero so there is little financial incentive for any real pricing. Adding "sponsorship" to the pricing terminology clarifies that one is paying for sponsorship to support the developer(s) and one is not directly paying for the software in general. I do not think "fair" lends any really added value and instead seems to confuse matters as if there might be something to hide. In lieu of "fair" I would use "suggested" as in: "suggested sponsorship pricing". "Open source" really is not necessary in the pricing terminology as far as I see it.

[brillout]

«Who’s eligible?» (headline) for which of the two options predented: free forever or extended trial?

I just further polished it, should be clear now (f659591).

[redbar0n]

Looks very good! I like the directness in the wording.

On the Pricing page, I'm thinking about the "Free forever" wording, and how a lawyer could construe it in case of a dispute.. I guess the idea is that when teams grow they also grow into a different pricing plan? Not that the Pricing only applies at the time of first "purchase" / usage (irrespective of what happens later).. To avoid such mis-interpretation, I would perhaps change:

• "Forever free" to "Free".
• "≥3 Software Developers" to "When your team is, or grows to, ≥3 Software Developers."
• "Forever access" to "Lifetime license".

[brillout]

I did some more polishing: e857546

I wonder if the root issue isn't the terms Limited funds and Sufficient funds. Because https://vike.dev/free#who-s-eligible is actually measuring the number of employees rather than funds.

The proper terms would be Small organization and Larger organization but then it's weird with the current card title Larger team.

• "Forever free" to "Free".

I agree it's slightly ambiguous. I tried to improve it but couldn't find a solution: if we remove the Forever free bullet points, then the layout doesn't align with last column anymore.

But I think it's okay, I think it's clear that it's "free forever" as long as you belong to the right category. And the https://vike.dev/free#who-s-eligible section now rules out any ambiguity.

And I actually do want to communicate that it's going to be free forever.

So far, I haven't had the feedback that it isn't clear. (The negative feedback I got though is that it took them a little too long to understand the pricing. But I think it's much better now. I'll gather further feedback to see whether it's clear enough now.)

• "≥3 Software Developers" to "When your team is, or grows to, ≥3 Software Developers."

I think it's already clear.

• "Forever access" to "Lifetime license".

I like the parallelism with Free forever.

[redbar0n]

"Forever" implies that the one time action of acquiring Vike will not result in having to pay anything at any later stage, irrespective of team size growth. Because you belonged to a category at the relevant point in time, and were promised access "forever". A later change in category does not affect that given promise. The promise does not explicitly state that it is subject to change (only implies it). This is how a lawyer could construe it in case of a dispute. Just saying.

Hence the "grows to" sentence suggestion. I would not remove the "Forever free" bullet points, just rename them to "Free", keeping the layout. But up to you.

I agree with the rest.

[brillout]

I agree with your point in itself. I guess it's a trade-off situation.

[brillout]

We decided to go for this fixed pricing.

Vike remains fully accessible (we meticulously designed the pricing to achieve this).

(Critical) feedback welcome 👀

[brillout]

To be clear, Vike stays 100% gratis for them — it's just that they'd have the unfortunate situation of having to reach out for getting their free license key.

[thnee]

You and this project give off a good impression overall. But this pricing thing seems confusing. I understand the motivation behind, and I support the ambition to get paid and so on. But the statements on the pricing page are contradictory and vague.

One can not use the MIT license, and then say that some people are allowed to use it for free and some are not. What you can do is give users the ability to choose between different licenses, for example a FLOSS license and a commercial license.

Regardless of which specific license is used, any conditions like "developers who regularly contribute" or "Small organizations with few employees" must be specified in actual numbers, otherwise it could mean anything.

As it stands now, I don't get a clear picture of where this is going.
Just as an example, here are some projects with licensing models that I do understand.
https://www.qt.io/development/qt-framework/qt-licensing
https://www.mysql.com/about/legal/licensing/oem/

[brillout]

@thnee There are indeed some ambiguous spots — thanks for pointing them out.

The cutoff is defined like this:

• You don't see the pesky toaster in dev ⇒ you can use Vike for free and without any license key.
• You see the pesky toaster ⇒ you need a license key (either via purchase or via vike.dev/free).

Now, the pesky toaster cutoff heuristic isn't well defined — it's subject to change (ideally only on semver major changes). This is ambiguous, but it only affects whether a license key is required or not — it doesn't determine whether companies must purchase a license key. So far I don't think it's an issue because what matters most to companies is whether they can use Vike for free or whether they must purchase a license.

[redbar0n]

I think what he alludes to is that it is confusing to say it is MIT licensed but then both have a price tag and require a license key for some…

Btw, do you want to allow people to sell copies of Vike? The MIT license allows that.

[thnee]

Yeah ,just to to be overly clear: The following bullet points aren't just confusing, they are directly contradictory. You can't say that it's MIT licensed, and then say that it's not free to use for some people.

✅ Open source: 100% MIT licensed
✅ Accessible: everyone can use Vike (for free if limited financial resources)

Further down on the page, it says:

As a large team, you will see a pesky toaster Get your license key at ... in development (it's never shown in production). You can remove it by purchasing a license key

I guess that makes sense logically speaking, but personally I would reword the initial bullet points to avoid any confusion.

Then there is this text:

The npm package vike will adopt a proprietary license requiring companies to get a license key when they see the pesky toaster. Vike's Git repository stays 100% MIT-licensed.

This is very unusual, and I'm not sure exactly how this works out in practice. I think this will make some people quite surprised. I believe most people would expect the official package to use the same license as is stated in the official repo.