Ask HN: Which Open Source License to Choose for a Python Language Server

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

11 points

・

davidhalter

・

3 days ago

13 comments

Burnsedia ・ 3 days 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.

  • dapperdrake ・ 2 hours ago

    Also note GPLv2 vs. GPLv3 vs. GPLv3-or-later and the analogous chain for AGPL.

    For example, the Linux kernel is purposefully GPLv2 instead of GPLv2-or-later.

lieks ・ 3 days 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 ・ 3 days 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?

    • lieks ・ 3 days ago

      It was originally designed to be used by government software in the EU. AFAIK, it doesn't really get used for much else, but it fills a niche not covered by the GPL family, which is weak/non-viral copyleft (as the LGPL provides), plus handling SaaS in a reasonable way (as the AGPL provides).

      Copyleft protects against proprietary forking, and also assures the community you can't close the source in the future. Weak/non-viral copyleft makes it so you can still link it to proprietary software, so you could sell integrations (non-LSP) or closed-source plugins.

      LGPL and GPL licensed software can be provided over a network with proprietary changes. The AGPL and EUPL both close that hole. Every change to the modules covered by the EUPL must be open sourced, even in that case.

      If your intention is to monetize the LSP itself, open source is probably not what you want. It's fundamental to open source that anyone can use it for any purpose, and also fork it. Permissive licenses like the MIT license allow relicensing to a proprietary license later (see Redis) but that causes problems with the community (see Redis), and is nearly guaranteed to cause a fork.

gkoos ・ 3 days ago

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

brudgers ・ 3 days ago

I'd still like to find a way to make at least a small living from it

There’s nothing wrong with that and a commercial license is the simplest thing that might work. If you want to improve the world with your software charge enough that you can donate cash to your local food bank without a second thought…the hungry need your charity more than developers. Good luck.

bananapub ・ 3 days 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 ・ 3 days 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 ・ 3 days ago

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

      • davidhalter ・ 3 days ago

        Due to AGPL's viral nature they will have to open source their code if they use it as a library. But in general I feel like companies simply don't want to deal with the potential "threat" of lawsuits so they don't want to use it that way. This means they either search for other solutions or will try to negotiate some kind of deal.

nylonstrung ・ 3 days ago

Ty and Pyrefly are already MIT

I'm sorry but there's zero chance people people are gonna use this LSP over these tools which already have communities and trust in production use cases

Especially if the license is more restrictive.