If you are planning to monitise it through SaaS, might be worthwhile to change the license to AGPL from MIT.
We value input from the community and are open to suggestions and assistance in making this decision. Our goal is to prevent unauthorized copying and resale of our product under different names while fostering a collaborative and innovative environment.
There's also the BSL. It specifically calls out competitive products. It automatically falls away for code older than a given time to another OSI license: https://en.wikipedia.org/wiki/Business_Source_License. Per the Wikipedia article this still has issues: contributors are handing over their work for to you for free for that duration, they can't use their own work for profit.
The AGPL does make your project extremely unattractive to competition, without affecting your contributors. The issue is that it is still possible to compete with you using it, so long as your competition releases all their code (i.e. infra, billing, etc.) under AGPL.
I would personally go for AGPL because it will keep the worst offenders (Amazon, Microsoft) away from your code.
Open-source has a specific meaning that too many people don’t know or forgot.
The line must be drawn. Open-source absolutely needs to have a firm definition, otherwise it will be whittled away to nothing. Microsoft already tried that with "shared source".
If you think the difference between BSL and AGPL is just splitting hairs, then why not just use the AGPL?
Nonsense. There is an enormous difference between the MIT license, which grants you permission to use and sublicense something without any restrictions, and the BSL, which does not.
> If I'm giving away software including source in the open, for free, while allowing redistribution and modification, then I'm not sure how to convey that without offending patrons of the OSI and FSF.
If you put limitations on how that software is used, then no, you're not giving it away. That part is something the OSI and FSF have been very clear about for decades - see e.g. the FSF's "four freedoms", which are about as clear and simple as you can get.
Even silly "camel's nose" limitations count, and have to count, otherwise there is no place to draw the line; see the OSI and FSF's comments on the HESSLA or the (pre-2021) JSLint license. Again this is something they've been clear about for decades.
> Not feeling like walking around on eggshells to give things away that's for certain.
If you want to give things away for free then do so. If you want to pull a Columbia Record Club "it's free, no wait you have to pay us" scam then of course people aren't going to support that.
Again, Columbia Record Club
> putting their extremely permissive terms in clear writing
If the written terms are clear already, why do you want to call it free/open source? (Which it isn't)
You would expect to be able to run the program freely, including as part of your production services, without incurring any obligations. And under any open-source license (including GPL-family) you can, because that's part of what open-source means. Getting presented with a bill because the program turned out to be BSL and the way you were using it means you need a commercial license is absolutely a scam.
1. Open (Source) for Business: A Practical Guide to Open Source Software Licensing
2. From Project to Profit: How to Build a Business Around Your Open Source Project
This video presentation by her on this topic is really valuable too: https://www.youtube.com/watch?v=Ck1gJIZ3Lr4
You will then have a really good idea of where to start. As the parent poster said, it is wise to switch to AGPL if you want to build a COSS business.
Also, lots of organisations have a blanket ban on AGPL, so offering it under an alternative commercial license is a great approach to enable them, but explicitly blocking it for "commercial use" makes it no longer free software, which would be a shame.
You could certainly iterate on the terms to strike the balance you want. You could make the source available to commercial clients as well. Each client can have a licensed tailored to their exact needs at a price that works for the people that make this software.
- If my limited company use it to manage internal development, but we aren't yet profitable (making money), is it commercial use?
- If a company uses it to manage internal development, but it isn't the product itself, is it commercial use?
- If I as an individual use it to manage a non-commercial side development project, and when it is then finished, I decide it is worth value and I sell it, does it become commercial usage, and my previous usage turns out to be non-compliant?
- Is a charity using it to manage an internal development project "making money"?
- If I as an individual provide a professional service to deploy this to "non-commercial" users, is this compliant by the license?
Regardless, by doing that the software would no longer be open source, and it seems like being open source is a significant part of the marketing strategy currently.
If you want to compete on being open source your license has to be free.
This is fine if you expect people to want to modify the backend, but it won't stop people who only care about cloning the service.
Which is sort of the point, good software made available to as many people as possible as cheaply as possible, but it's not really protection against others who would monetize the software you wrote.
This sounds like a myth. There is no way AWS legal would allow providing access to an AGPL licensed work over the network.