Since the beginning the Joplin project has mostly been under MIT license, including the desktop app, mobile app and web clipper. I didn't put much thought into that license actually - it's just the default I go for whenever publishing some code, and I didn't know Joplin would become a relatively big project.
However lately I've been wondering if such a license makes sense for applications? For libraries, MIT is good because it's permissive and allows integrating the code into commercial software - without this many libraries would not be as widely used as they are today.
However for applications it's a different story - we release a final product that can always be used in a commercial context anyway, regardless of the license (even if there was no license). The only thing extra that the MIT license allows would be for a someone to create a commercial fork of Joplin, and make improvements, without having to share back any of these with the open source project. So the questions is - what do we gain from allowing this?
Forking open source projects, making improvements, etc. is great and users benefit from it (and the Joplin license will always allow this), but we'd all benefit even more if these improvements were made open source too.
So with that in mind I've been considering switching the project from MIT to GPL, or possibly AGPL. It would still be open source but with that requirements that any change to the software needs to be shared back as open source too. That means we may integrate these changes into the project, or ignore them if they are too specific, but in any case we'd have the option.
I'm not 100% sure we'll actually proceed with this, but in any case I wanted to bring that up in the forum first, in case you can think of any issue that a change of license could cause. As far as I know all software derived from Joplin currently is open source anyway, so I don't think anyone would be affected.
If you have any suggestion or concern about this please let me know.
It certainly wouldn't be an unusual choice given the licences that apps of this ilk choose. Of the open source note taking apps that I keep an eye on the vast majority are AGPL with a smattering of GPL 2 and 3 thrown in and I think it does make sense.
One question is whether the custom cloud licence is compatible with various GPL licences?
I don't like this very much, I almost always use the MIT license, I'm not sure if it will cause all derived community projects to have to be changed to GPL, which is annoying. . .
Switching licenses doesn't build a "wall", if it's really popular, there must be a commercial company copying it, otherwise no one cares, and there are too many options for note-taking tools
Thats a good point, I imagine anything that uses the data api etc. are fine but what about plugins that use the plugin code (specifically the generator-joplin package), would that force all plugins to be a GPL flavour too?
Also regardless of direction would it be a good idea to adopt a CLA signing procedure from contributors? Especially if it does go to GPL?
Having a quick look I can't find a definitive answer as to how the licence can be changed as such, some suggest it is fine to just swap from MIT to GPL, some imply you need 100% or 95% of all contributors to agree to the relicense and some imply that existing code in the project remains MIT and only new commits are GPL (and the original MIT licence notice has to remain).
Would honestly love to be corrected if I'm wrong about any of the above, it all seems a bit murky.
Yes a CLA would make sense to clarify code ownership. I'm not sure how other projects do it exactly, whether they even have a CLA or, if they don't, how they manage.
I didn't check for relicensing, but my assumption is that anyone, not just us, can take MIT code and build on top of it and apply a more restrictive license if they want, without having the previous contributors' agreement. MIT is permissive enough to allow this. GPL to MIT would be a very different story of course.
Basically it seems that you just create a Gist with your CLA wording (which you can get from places like - https://contributoragreements.org/) then link the assistant to the repo and it will then comment on PRs asking for people to digitally sign it.
Many of the discussions are about somebody forking a project and wanting to release that under GPL where the difference is they aren't the owner of that codebase or the primary copyright owner. I'm already out of my depth with the topic I think, just wanted to bring it up in case it is actually something that might be an issue.
I think the confusion is because we always talk about "changing" the license, but really we can't change it. What's been released as MIT will always be there as MIT, that can't be changed.
What happens instead is that we'd take the existing MIT code and any addition to it would be under GPL license, any new version of the Joplin apps will be under that license too. After all this is what happens with commercial software which almost always include MIT-licensed code, yet they can release their software under any proprietary license they want.
At least that's my understanding at this point, but yes we should ensure there's no doubt if we ever make the switch.
The only thing extra that the MIT license allows would be for a someone to create a commercial fork of Joplin, and make improvements, without having to share back any of these with the open source project. So the questions is - what do we gain from allowing this?
The first question I have is, is this situation likely to creep up since it hasn't? What's the effort to change to GPL?
I think if it's low effort to change to GPL, just do it, so the worry isn't there anymore.
My guess is that while you can't change old source code from MIT, perhaps you can make all code written from this point on GPL?
Some software names their license as such, but according to the Free Software Foundation (see the link listed above), they essentially break their own license. The FSF mentions GPL and AGPL specifically there. Unless we're talking about a single-man project with no contributors that can use different licenses at will depending on where they publish it.
From my limited information based only on what I've found in the Internet (i.e. not legally bounding), LGPL is named as the one that can indeed be used on the Apple Store and still comply with itself and the restrictive Apple Store's terms of service.
Isn't it where it is useful to have each contributor sign a CLA? Because if code ownership is clear it means we can can have a GPL version here, and a relicensed one uploaded to the App Store. A bit like Qt has a dual license - GPL and commercial, and with the commercial one you can of course use it on the App Store.
Yeah, but you do need to get literally everyone to sign it, don't you? If even a few of them don't agree to sign it, you've got to either give up the dual license publishing or strip the program of the code that they've contributed so far. A similar problem problem may emerge if some of the contributors from a long time ago simply can't be reached out anymore (e.g. don't respond to e-mails, etc.).
For old contributions it's not an issue because it's MIT, but for new pull requests the contributor would indeed need to sign the CLA. I don't assume it's a big deal as it's quite common but we'll see.
Depends how much people like your project/company!
GNU ask for a CLA? No one bats an eye. Canonical do it?
I'd potentially expect some friction but there's the practical element that the majority of commits come from a relatively small number of people so the opinion of the majority ends up meaning little overall.
