Eternal Struggle (yoavg.github.io)

Having created Jedi in 2012, I started ZubanLS [0] in 2020 to advance Python tooling. My initial idea was to use a freemium model where companies would pay for usage on large codebases. That approach didn't work out with the arrival of Ty and Pyrefly. That said, most of the work on the tool is already complete:

- Full set of core LSP features (Diagnostics, Goto, Completions, Rename, etc.) - Type checking that's 20–200× faster than Mypy - Passes most of the official conformance tests [1] and over 95% of Mypy's relevant tests - Offers both a Mypy-compatible mode and a mode more similar to Pyright

Because of this, I'd like to open source the project. Ideally though, I'd still like to find a way to make at least a small living from it, so I'm considering different licensing options. Are there any licenses beyond MIT/GPL/AGPL that might make sense here? Personally, I'm leaning away from MIT since it leaves almost no room for monetization. Do you think that's a mistake? Right now I'm leaning toward AGPL. From your perspective as a user, would that be a blocker for adoption?

[0]: https://zubanls.com/ [1]: https://htmlpreview.github.io/?https://github.com/python/typing/blob/main/conformance/results/results.html

Comments (7)

Burnsedia · 1h ago

MIT is great for fast adoption, but if you go that route, you’d need closed-source add-ons or a SaaS layer to monetize. Apache is also good for adoption and for getting corporate clients and sponsors, but the trade-off is that anyone can take your code and repackage it without contributing back.

GPL or AGPL gives you more direct monetization options because it forces reciprocity. GPL protects against proprietary redistribution, while AGPL goes further by preventing companies from just hosting your project as a service without contributing. That makes AGPL especially useful for developer tools like LSPs, since it also sets you up for a dual-license model (AGPL for community use, commercial licenses for companies that want to integrate it into proprietary tooling).

In short: MIT/Apache = growth and sponsorship potential, GPL/AGPL = stronger control and licensing revenue. It really depends on whether your priority is fast adoption or direct monetization.

lieks · 1h ago

If you are already considering the AGPL, I'd like to suggest the EUPL. It also covers SaaS, is copyleft (forbids nonfree forks), but non-viral (can link to nonfree software), a lot easier to read, and also doesn't have the "bad name" some people attach to the GPL family.

I can't speak to how well it fits in your usecase. There are too many ways to do monetization, and I don't know which one you have in mind. But copyleft at least stops other entities from monetizing without sharing their contributions, so if you want to keep it open source, that's my recommendation.

davidhalter · 1h ago

Thanks a lot for this idea. I did not know about this. Do you have any experience with EUPL or with projects that use it?

But wouldn't in that case people just use it as a library and do whatever they want? EUPL feels like LGPL, doesn't it?

gkoos · 1h ago

Some legal departments are against AGPL and that might affect adoption.

bananapub · 37m ago

why would you use the AGPL? no one is going to be hosting your LSP and selling access to customers, and withholding their own patches.

davidhalter · 18m ago

Most people will be using it as an LSP in their editors. Some companies might be interested in creating services on top of it. They won't be hosting the LSP, but they might want to use it to index code. And at that point there's at least some way for monetization.

bananapub · 11m ago

how do you feel the AGPL is relevant in that situation?