The concern would generally be people see certain organisations as altruistic. GNU is generally well respected and the GNU Coreutils are ancient, people trust them highly.
But the more commercial you get, the more likely people are to say "They're only asking for a CLA so they can benefit from open source contributions and then sell them as proprietary in the future".
Not that it tends to happen like that in practise, but it's the concern people would have. The GPL is a very politically motivated license and in theory the CLA is a backdoor to destroy the whole point of it in favour of the CLA owner.
Naming names for the sake of example though, systemd was partially made because the author/community weren't keen on the CLA on upstart, the competitor at the time, coincidentally a Canonical project.
There's also been quite recently a big controversy with Audacity changing ownership paired with introducing a CLA in the process. This together with added telemetry eventually led to creation of at least multiple forks of the project.
Yes I remember the Audacity controversy, but the whole thing looked quite bad especially with the telemetry. That part at least won't happen in Joplin. Also as a project I think it makes sense to clarify code ownership, if only to allow publishing to app stores that have different requirements.
Not having a CLA makes it extremely difficult to get manage large codebases over time. An open source project I contribute had some modules as GPL2, some others as GPL2+ and some others as GPL3, without any CLA. They had different licenses just because whoever started the module didn't really think about it, setup "a GPL" license and that was it.
And it was really painful and time consuming to standardize them later to a single license. So while I get all the concerns people may have around CLAs... I think they are worth. And they are definitely not that hard to convince people when there's some sort of non-profit organization behind the copyright (foundation, etc)
I, for one, really dislike the GPL license. Even in this case it seems you're talking about preventing a theoretical scenario, rather than addressing an actual problem.
Last time I checked (a few years ago), it was getting used less and less frequently than more permissive ones, such as MIT. And I think that's good.
The other question is: how dedicated are you to enforcing this?
Let's say you add things like CLA to the workflow. Then someone comes along, makes a change and publishes a Joplin binary, or whatever. Do you really want to dedicate time and headspace to actually legally fighting them and forcing them to release the code? If not, you've just made your life unnecessarily more complicated for nothing.
And it would also jeopardize otherwise benign usage. Say I worked for Corp X, and I had to do a fix/change in Joplin to make it compatible with corporate policy, or work in a dumb corp environment or something. Right now, it's not a problem; GPL would make it unnecessarily complicated.
I mean, I'm not saying it's a deal-breaker, or anything. But I don't see how it adds anything to the project.
I think this is true but I'd be interested to see the scale of the projects and who makes them.
For example big corporations in open source like to publish in MIT, BSD or Apache whereas "volunteer" type projects seem to prefer copyleft ones like GPL. As for scale (and intended use), Laurent touched on this in the first post but it makes a lot of sense for smaller libraries and components designed for integration into bigger apps to be MIT but something like Joplin isn't exactly well suited for integration into a bigger app.
I think this very much depends on who did it and why. At the very least it gives the option to do something about it.
I don't think it is that complicated, if you make a change to the code for redistribution then you just have to make that code available, it isn't like you have to submit PRs to the original project and you don't even have to put it on a public website - you just need to make it available to whoever wants it (although I think the AGPL licence requires it to be more easily available). You are perfectly within your rights to modify the code and not make the source available so long as you aren't redistributing it (or in case of the AGPL - hosting it).
But I don't see how it adds anything to the project.
The major thing it does add is that if a big company did decide to make their own fork of Joplin and devote far more resources to it than the current team would be able to do then the original project can still benefit from the changes they make.
Actually that's really what licenses are about. The day someone forks Joplin and creates a closed-source version of it, it will be too late to do something about the license.
I can agree that the chance of someone doing that is relatively low, but the cost of changing the license is also low (or at least that's what we're trying to establish here), so it seems like an acceptable thing to do.
But for example when someone created a commercial service based on Joplin Server, while it was still MIT (and well before Joplin Cloud was ready), it took me by surprise, so we can't always predict what's going to happen.
Yeah, when it comes to the server, I thought giving it a non-commercial-only license was good. (Even though I didn't know someone already tried to sell it.)
It does make sense there, because it's relatively trivial to just spin up docker and start charging for it; and if done by someone with enough money, could eclipse the original Joplin cloud easily.
And while that isn't as easy to pull off with Joplin itself, I guess I do understand you wanting a safeguard.
Internal use within a company doesn't count as distribution and so there is no need to publish source code for modified binaries that are used purely within a single organisation for its own needs.
Hi, I am for GPL (I am just a user, not a contributor, and not a lawyer either) - I think GPL makes it more likely that a project like this will continue as free software in the long term, which is good. I will sum up my thoughts about the change, although most of it is in bits and pieces in previous messages.
Any existing user or developer (even commercial one) who acquired the code under MIT would not be affected at all to use it, because he got the code legally under MIT licence and this licence grants him the rights it grants forever. If the licence is changed by the developers/owners, I think the existing code is at that time available under both licences simultaneously, and the new pieces and updates only under the new one.
As there is a community of developers, there should be an agreement among the existing contributors to do the change. Maybe to get a formal unanimate agreement more easily, it might be enough to ask all contributors first if they would agree to the change, if the majority supports it and then organise an online voting - just an idea, I do not really know if this would suffice all formal requirements.
I really do not know what happens if there is no response regarding agreement with the licence change from a contributor, who is not active anymore, changed his/her contacts, etc... I think that would be a problem.
If there are existing contributors from the commercial sphere, they would need to either adopt GPL, or they would probably stop contributing, and will continue to develop their own code under their own licence from the versions acquired under MIT. I don't think it should be a major problem for them or for the project (if they as contributors do not block the change, that is).
Surely there are some other projects which have undergone similar changes in the past. If someone knows of one, you may just ask their community how it was done and how it went.
Syncthing initially used MIT, then moved to GPLv3, and then to MPLv2. I'm not sure what the situation was when the first change happened, but when it comes to changing it again to MPL, the reasoning was that a less restrictive license would allow to publish the program in app stores with restrictive TOS (without asking the contributors to sign anything), and also allow to use the code in 3rd party proprietary software. Obviously, the last point is kind of the exact opposite of what this thread proposes .
Side note, I recently had YouTube throw a video for inkdrop in my algo. It's an incredibly basic MD editor. Gave it a look and boom it's paid... Without any encryption etc.
I think note taking apps are going to see a surge. A second renaissance and with that people looking to profit as easily as possible (think of the Joplin cloud incident).
I think (but this is just a guess) app authors can distribute otherwise-GPL apps on the App Store by distributing the App Store version under a different license (even if it's exactly the same code). I don't know whether or not contributors would have to agree to a different contributor agreement, though...
I'm basing this guess on Qt's licensing. They distribute a GPL version of their software, but allow users to buy their software if they want to use it under a different license. I'm assuming Joplin could do something similar for app store distribution (but really don't know).
Edit: Oops! Someone already posted something similar to this up above! Sorry for re-posting!!!
.