Changing project license from MIT to GPL?

joeschmoe · 2022-05-10T02:19:55.462Z

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?

meldarionqeusse · 2022-05-11T05:16:23.699Z

Logseq is agpl and it's on the apple app store. So I don't think it is a problem

tomasz86 · 2022-05-11T09:06:12.735Z

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.

laurent · 2022-05-11T09:25:18.734Z

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.

tomasz86 · 2022-05-11T09:35:47.242Z

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.).

laurent · 2022-05-11T12:11:38.242Z

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.

james-carroll · 2022-05-11T14:25:37.354Z

laurent:

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.

Daeraxa · 2022-05-11T14:35:14.233Z

james-carroll:

GNU ask for a CLA? No one bats an eye. Canonical do it?

Not knowing what this was about, was this just double standards, iffy wording in the CLA or did people think Canonical was trying to screw them over?

james-carroll · 2022-05-11T14:43:21.371Z

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.

tomasz86 · 2022-05-11T15:34:18.716Z

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.

Ref: https://lwn.net/Articles/859599

laurent · 2022-05-11T15:59:48.190Z

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.

GabrielMPhi · 2022-05-12T16:05:27.789Z

I would like it to be gpl, agpl or the like.

xavivars · 2022-05-13T07:48:23.679Z

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)

zblesk · 2022-05-13T14:44:36.259Z

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.

Daeraxa · 2022-05-13T16:11:36.310Z

zblesk:

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.

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.

zblesk:

Do you really want to dedicate time and headspace to actually legally fighting them and forcing them to release the code?

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.

zblesk:

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 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.

laurent · 2022-05-13T17:37:13.772Z

zblesk:

it seems you're talking about preventing a theoretical scenario

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.

zblesk · 2022-05-13T18:27:40.673Z

laurent:

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.

james-carroll · 2022-05-13T19:11:55.994Z

zblesk:

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.

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.

https://www.gnu.org/licenses/gpl-faq.html#InternalDistribution

Sofie · 2022-05-14T15:19:06.239Z

+1 for GPL

tomas4 · 2022-05-16T09:02:37.359Z

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.