[armchairhacker]

First, I really like language frameworks like this. I think it could become very useful and popular.

That being said, I really doubt anyone will buy a commercial license. People don't sell compilers and IDEs, and the ones who do are large corporations who make everything themselves. Look at state of language tooling today: nearly every compiler is open-source, every language server is free, every IDE is free except JetBrains (a well-known company with a large reputation) and Sublime Text (being heavily replaced by VS Code), and anything not open-source has an active open-source alternative. Nobody's going to buy a license from you to sell their compiler, because nobody's planning to sell their compiler.

For this reason I'd recommend changing the license. I don't think it's overly-restrictive or dishonest, I think it's fair to expect being paid if someone makes >$200,000 off your work. But nonetheless it hurts adoption, a lot of people will see "proprietary" and not even read the license text. You're more likely to make money distributing it as MIT / Apache, letting it get popular, and setting up donations/sponsorships to fund development. But honestly, if you're looking to make money this isn't the space to do so: you could be hired by someone to work on PL, or you could sell something like a game, but you're not going to sell your own PL.

[Eliah_Lakhin]

Thank you for your feedback!

I agree with your point about the licensing. I would also add that tools for the development of compiler front-ends are quite a niche market. So, honestly speaking, I don't plan to earn much from my project regardless of the license terms. This work is part of a higher-level in-progress toolset, which is closer to the end users. I have dedicated it as a separate project primarily for public preview, with some restrictions on distribution and use, as I haven't decided on the overall toolset distribution model yet. But it is possible that I will change the licensing terms of Lady Deirdre in the future to something less restrictive (maybe even MIT) to make it more popular, this is just not my current goal. I apologize for any inconvenience my current licensing terms may cause.

[zackbrown]

> I apologize for any inconvenience my current licensing terms may cause.

Friendly advice from a stranger, worth what it costs: I believe the greatest inconvenience of a commercial license will be to _you_, as opposed to end-users.

The market is so saturated with open source, developers expect it, and commercial licenses cause huge usage friction and doubt.

The "dual license" died as a viable business model around the time Meta (née Facebook) and Microsoft starting investing billions into free-as-in-beer OSS, 10-15 years ago.

Today, this model will only sabotage usage. People using your OSS is good. Even if your goal isn't to become popular, usage & feedback are learning, and while it's fine for popularity not to be a goal, I would encourage you not to proactively target the opposite of popularity.

If you have some other IP (the other tech you're describing) that can remain proprietary or wrapped behind a service, then people using other pieces of your stack for free is a _really good thing._ At least, they're aware of your brand and have started to trust it. At best, they're ready to use your commercial offering out of the gate.

[Onavo]

You could however offer a cloud based static analysis API for security companies, which could be a viable source of revenue to fund the development.

[zamalek]

IANAL/IANYL. Make it dual-licensed, AGPL with MIT by request. Indicate that you are presently declining MIT license requests. The chances of your agreement being adhered to are near zero, regardless of the legality. On the other hand, any mention of GPL will send lawyers running for the hills - AGPL more-so (and legally so, it makes your code basically useless to a corp). The MIT carveout is merely there so that contributors don't throw a fit if you choose a more permissive license down the line.

[giancarlostoro]

It's 5 thousand after you've made 200 thousand though? I think that's the only restriction? Unless he updated it before I got to look.

[Eliah_Lakhin]

> It's 5 thousand after you've made 200 thousand though?

That's correct. The license agreement requires purchasing a commercial license per product if it reaches a certain revenue threshold. I believe this price should be feasible for a business, and this restriction is not unfair for regular programmers either. To clarify, the license needs to be renewed annually to continue receiving new versions from me. Additionally, I reserve the right to change the price in the future. However, license renewal is not a strict obligation. You can continue using the previous versions if you buy the license at least once.

The idea is to replace the donation model widespread in typical OSS projects with a formal obligation to purchase a license. I believe this approach more accurately expresses what the authors really want in exchange for their labor.

[Vegenoid]

I think your approach is good. There are several ways to make money by independently making software:

1. Charge money for the software

2. Charge money to help people implement/use the software

3. Leverage the experience and credibility gained to get a company to hire you or sell consulting services

4. Hope that people give you money for the software out of the goodness of their heart

Opting for an MIT license pretty much ensures that the software will only make money for you indirectly via option 3, and maybe you'll get a trickle via option 4. There are numerous examples of people making popular OSS that become frustrated with companies that are using their software to make money, and they aren't getting anything for it. They have to work for other people for money despite having made software that generates lots of value. If you want to ensure that if your software creates substantial value, you get some of it, you need a license like yours.

I think there is a strong argument that if you want to get paid for your software, you simply shouldn't make it any flavor of source-available. A company may actually be more willing to buy software that is closed source than open source, because the closed-source software is simply perceived as being more valuable. Of course, as an engineer, I love that the source code is available.

[prmph]

Yeah the readme claims you can use this in an open source project. This is weird. An open source project that bundles this software (as a language implementation necessarily must) will _not_ remain open source. The only way a related work remains open source is if it depends on this project as a _peer_ dependency.

So as it is, I seriously doubt that anyone wanting a quicker way to implement a language will use this; why would I want to hamper adoption of my language by hobbling it with such a license?