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.
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?
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
So, that first of all requires copyright assignment of contributions to some central project authority - I’m not super excited about that, since first of all I don’t think it’s right to take away the copyright from the creator, and second it’s a bureaucratic hurdle to contributing.
And, as Audrius alludes to, this only works for actual contributions. I.e. I can’t grab a cool looking diff from Pulse and apply it.
1 Like
Just did a bit of research; apparently the FSF does copyright assignments even — one of the reasons they state being that they can then enforce the copyright in case there are violations (which is something to think of — what happens if someone violates the agreement; right now we have the responsibility split between a rising N number of authors):
https://www.gnu.org/licenses/why-assign.html
One idea would be to assign the copyrights to Ind.ie with the understanding that it would (a) enforce the copyright when necessary to tackle infringements (b) provide the ability to dual-license Syncthing/Pulse for specifically for the purpose of allowing them (and software based on them) to be included in app stores (given that a version is also made available under GPL). We should be able to handle this within the confines of contract law without lengthy bureaucratic bs and without weakening the overall license for just this one use case.
Would this work? Thoughts?
While using GPL, other projects (i.e. which use the code forked while this project was still using MIT-style license) won’t be able to benefit from any changes made afterwards. The opposite is of course true - projects using GPL-licensed code can, and frequently do, import ISC/MIT/BSD-style licensed code, making the other project unable to re-import the changes in the process.
Apart from that, GPL license is complex and sometimes leads to misinterpretation which in turn may require clarification from the FSF themselves and/or a lawyer. ISC license, on the other hand, is short and clear.
3 Likes