I was reading this article recently where they explain why they switched from MIT to AGPL for their open source web service, and I think it makes a lot of sense. The idea is to prevent a company from taking the software, improve it and sell it as a service, without contributing anything back to the original project. It's still however possible to self-host the service and I suppose even modify it, as long as it's not for commercial purposes.
It all seems quite reasonable, so I think I will switch to that license for Joplin Server. However if anyone can think of any issue with this, feel free to let me know.
For now, the desktop, mobile and CLI apps will remain MIT.
Can you clarify about modifying it non-commercially?
I won't pretend to be a business man, but I'd assume the value proposition of hosted Joplin servers is more in the hosting than in the Joplin Server, not to sound as if I'm discrediting Joplin, but as you say, anybody could host it themselves if they wanted to.
AGPL Joplin Server could still be taken by another company, who would have to apply AGPL3 compatible patches and release them to the world, and they could potentially still be seen as more valuable, either in terms of extra functionality (maybe you're not willing to support their patches) or in raw cost (maybe they can get better deals on hosting). This is assuming they even patch the server to begin with.
Frankly, if the goal is to try earn a sustainable income long term, you might be better simply considering a custom license for the server itself, where commercial use requires actually literally paying you, similar to Gitlab, you'll get the source and be able to apply your own patches, but you're still using it under their terms and pay them directly.
Hey well I should pipe up because I actually plan on doing just this -- though I planned on giving back, essentially doing a profit/revenue share and projects sponsorship assuming it actually got off the ground. My project hasn't launched yet so I don't mind getting feedback, I'm planning on calling it "Ragtime Cloud" (it is really hard to think of names that fit in well with joplin without mistaking myself for the brand itself).
Up until now what I wanted to do was offer WebDAV based syncing services (there are varying problems with the other methods except for DropBox as far as I have heard). Since Joplin Server does sync much more quickly, it makes sense for me to run it as well and offer it to users (even in it's experimental state). There are more features I want to offer based on Joplin -- basically, I think Joplin could rival Notion but it needs innovation on the hosting side, as the app is already pretty fantastic, thanks to your hard work.
More to your point, I'd say that the AGPL will not protect your interest in this way, what you should go with is the BSSL (MariaDB, Sentry, other decent companies have gone this route). In general, the AGPL will not prevent people (me, let's say) from using your code without contributing, they just require that you contribute back if you modify it. So if you run the code unmodified, technically you don't have to contribute. I have no problem contributing (and was hoping to, but have been stuck in a bunch of yak shaves along the way which is why Ragtime Cloud still isn't even up) -- but just want you to know how it stands as I see YOur other points on AGPL are correct -- most people who run it locally won't care (if they even understand the licensing to start with).
If you're interested in talking about this feel free to send me a DM on here and we can chat/email or get on a call. The part of my skillset that is relevant is infrastructure and I think the Joplin community needs a known-compatible sync/backups provider (and from there growing into more things).
Seems like a smart move. If you've followed any of the goings on with ElasticSearch and Amazon, I think that has caused a lot of people to rethink licenses this same way.
Thanks for the feedback guys, I think it's quite a tricky problem. Based on what you said and what I've read over the past few days I think I'll lean on a license that's open for personal use or internal use (for example at a company), but non-free for cloud operators who would want to offer Joplin Server as a service.
I believe that's roughly what the Server Side Public License (SSPL) does, by making it impossible for cloud operators to comply with it they force them to reach out for a paid license. So maybe I'll go for that, or maybe a dual license like MIT for open source and personal use, and just no license for commercial use.
What I mean is that if you're running Joplin Server for your own use and decide to patch it to add some feature or tweak something, you can do so, and you have no requirement to publish your modified source code.
@vados, thanks for the input. It's a bit early to say at this point but maybe we could indeed reach some agreement either on cooperation or licensing.
Thanks for the feedback -- I will be posting here when the service is up and look forward to hearing from you. Would love to give back to the you and the community here who have created and maintained this valuable project for so long. I personally just updated to Joplin beta on the AUR the other day.
Look forward to seeing what you decide on this issue as well -- people still certainly contribute to Sentry for example but I wonder how many of those contributions are from employees, and you can still run Sentry for yourself so that's perfect for your goals as well.
Another rather serious problem with the AGPL is that there is serious confusion around it.
More or less invariably when someone points this out someone will say it is really simple so let me try to preempt that:
Does the AGPL
force you to open source under AGPL anything it reaches out to on your side? Based on my last reading of it, yes. If this is correct it is hopeless. I'm just a person, not a big company but I cannot live with the idea of having to opensource every personal script that I ever hack together that an AGPL server reaches into.
or is it more really more like LGPL that you are forced to release changes of itself? Many people seem to think so. If so then it is a completely different matter and I'd be tempted to call AGPL a relatively nice license that sadly barks loudly and scares everyone away.
Now the problem is people say in various ways it is 1 or 2, but no one has so far been able to point me or anyone I've seen to an official explanation.
Until someone who knows can explain in plain English what AGPL actually means I walk circles around anything AGPL. I've contributed bug reports, bug fixes, donations etc to MIT licensed, GPL licensed and what not projects but the moment things go with AGPL or any of these new heavily one sided licenses I'm out until someone can
I see that SourceHut is fully open source, while also providing a paid service so maybe it's an option.
What I want to avoid is being outcompeted by a company as soon as the final version is released. Like an established cloud operator could quickly deploy and rent instances at a low cost if they already have the infrastructure in place, and I won't be able to compete with them. I don't know if it's even a possible scenario but if it happens it would annoy me, so for now I remain careful with the licensing.
Not that I'd recommend it quite as is, it would prevent some scenarios like third party repackaging of the server even if that was primarily for non commercial use, and you'd probably have to increase the number of allowed users at once for example, but generally speaking something similar could be a good suggestion.
I've been rereading about the AGPL License and I now think it makes a lot if sense:
it doesn't care about other things that it itself touches over the network (databases, fileshares etc).
it doesn't care about the clients that reaches out to it either, only that one must provide them with an opportunity to download the AGPL licensed software
what becomes "infected" by AGPL? :only what would have been affected by GPL in the same case, e.g. if you modify AGPL code it is obviously still covered by AGPL. If you create a combined work it is probably covered by the AGPL etc
With GPL, there's a loophole: if you modify GPL code, but you aren't distributing it, you have no obligation to release the source code. The issue with web services is that you aren't distributing software, you just allow people to connect to the service.
The AGPL was invented to close this loophole: if you make changes to an AGPL-based web service, you have to release the source code.
It's good to force cloud providers to contribute back to open source, however in my case I'm not sure it's the right license.
Just yesterday Grafana announced that they are shifting to AGPLv3 for 3 of their projects.
The QnA has some interesting insights on why this change.
SSPL has a lot of issues, some of them are mentioned in this.
Also, this has been debated to death but SSPL is not and OSI approved license. AGPL also makes it impossible for cloud providers to offer it as a free service without also open sourcing their modifications. That respects the open source spirit. SSPL is an impractical license and I'd do a strong -1 for this.
I agree I don't like the SSPL either, mostly because it pretends to be what it's not. It's essentially a commercial license and it's not even very good at that.
