Closed Poll: What's the optimal license, in your opinion?

Here’s a quick poll to gauge the feelings of whatever the current population of people frequenting this forum is… What’s the best license syncthing could possibly be released as, ignoring any difficulty or annoyance of actually changing it?

  • MIT, as it was originally (this includes BSD and other MIT-like licenses).
  • GPLv3, as it is currently.
  • MPLv2, as some sort of middle ground.
  • Other, I’ll specify below.
  • I really don’t care, I just use it.

Note that changing to not-GPLv3 means that any changes introduced in the Pulse fork are off limits for us forever. This is of course in the spirit of MIT, we basically just need to consider it a proprietary fork. :)

If you’re a current contributor and have a strong opinion either way, feel free to post it below.

2 Likes

I don’t have a strong preference, therefore I voted ‘I don’t care’, but the only thing I want to preserve is license compatibility with Pulse, so that we could port the features we find to be useful for syncthing without going to jail.

This is in practice a strong preference for GPL.

I voted GPLv3 but I really wanted to vote dual license: if someone wants to develop the product commercially under friendly terms that shouldn’t be blocked completely. But open source definitely, with patent protection if possible.

I voted other, because while I definitely want changes in the Pulse fork to proliferate, I am wondering if this suggestion might be a way out that ensures that syncthing remains open, pulse-compatible, able to take in pulse code while at he same time licensed flexibly enough for teh Appstore or ventures with commercal aspects. I am not an expert but found this suggestion promising: License question could that be a way to do this? If not, I d opt for GPLv3 to ensure that code sharing with Pulse remains possible.

If you mean dual licensing that’s fine by itself, but won’t apply to changes you adopt from the outside (as opposed to specifically contributed to the syncthing project), so doesn’t really work in the long run.

I agree with @menelic think that the license should fulfill the following points:

  • open
  • pulse-compatible
  • available for the Apple products

Thats why I voted “GPLv3”, because the first two points seem more important than the last one.

I agree - open and pulse-compatible are more important than Appstore compatibility. That’s why I said I d opt for GPLv3 if dual licensing or “compromise licensing” as suggested here License question are not feasible or impede code sharing with pulse.

Yeah, I guess I’d vote on GPLv3 + custom licenses issued by Jakob for those who can't cope with GPLv3 but have a noble purpose. Something like GPLv3, just without the Not for app store issue.

This can’t happen. Licenses are issued by AUTHORS in the entirety.

I am not a lawyer but if you change the license to be what I’ve said, and AUTHORS agree to it being what I’ve said, then anyone committing will automatically have to agree with the license in place, which will be this weird license?

Yes, that’s true. But then we cannot pull in changes that are GPLv3-only.

Rather, we can, but those won’t be covered by the second license.

Fair point, but I guess the same issue prevails with a dual licensed approach too, so given Pulse is GPLv3 there is no way to get anything into the app store, unless we don’t merge anything from Pulse, or Pulse devs just makes pull requests, or people working on Syncthing get ‘inspired’ by Pulse’s code.

I strongly prefer non-copyleft licenses but looks like pulling back changes from Pulse might be important… Or maybe not – Syncthing is good enough for me right now!

1 Like

As I understand the license world, yes.

couldn’t there be some kind of, well, “memorandum of understanding” with the pulse devs, as they are an official, sanctioned and non-hostile fork? I am aware hat the whole forking business is to r4educe some of the communicative strain and clutter that came up in recent weeks, but maybe this would be a possibility fit for a set it once, automate it always approach? So, Pulse- MoU to enable dual license?

@aral ^? MPLv2 or similar?

Hey folks,

I don’t understand the dual-licensing problem. If all authors agree to bestow copyright to the project; we could easily dual license for app stores.

So, here’s my suggestion: all previous authors do this and we get future contributors to do so also. That way, we can keep GPL v3 and dual-license when necessary to get an app on the app stores.

How does that sound?

Yeah, but this only works if all people working on all forks follow the same principle.

1 Like