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.
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.
Until Ind.ie makes a proper dent in the issue count on Syncthing’s tracker or deliver some godly features, I think people will not trust Ind.ie up to the extent of assigning copy rights. FSF is a different story, it’s been there for years.
Yeah, no. I don’t trust myself, or want others to trust me, enough to ask people to hand over copyright to me. I’m certainly not handing it over or recommending anyone to hand it over to an as of yet unproved corporate entity.
Sorry, to be honest, at this stage that suggestion feels bizarre and not a just little disrespectful. I think we have our answer as to where things stand, and at the moment that’s a stay with GPL, for good and bad.
Sorry, folks, I don’t know what else to suggest.
However, if you’re looking for a reason to trust/not trust Ind.ie, you should do it based not on lines of code but because of our manifesto. It’s hurtful to be described as a “corporate entity” when all of us have taken huge pay cuts to create and work for a social enterprise limited by guarantee with a social mission that we have crafted, bound ourselves to, and believe in.
GPL it is.
Let’s deescalate this a bit, please. I appreciate both @aral 's and @calmh 's standpoints and would really hope that we can avoid unnecessary acrimony which takes away time and energy from the important projects that both of you have started. You have both been able to rally impressive support, let’s try to ensure synergy instead of division. Maybe the FSF option can be shelved for reevaluation at a later point, and maybe ind.ie can indeed use the implementation of some of the features on the pulse roadmap (and I d say encrypted servers is indeed what @AudriusButkevicius called a “godly” feature) to build trust informed by pull requests. Nothing against the manifesto, and yes I do respect the risks ind.ie folks are taking but I’d say that its understandable that in this discussion,pull requests are the currency that would convince those who suspect that a corporate entity is problematic even if limited by guarantee. So in short, let’s not re-enact the cliche of the fracturous open source community but rather ensure synergy.
Indeed. As such, I don’t think the FSF suggestion is necessarily a bad one, it’s just something I at least haven’t explored or considered yet.
Seems like we have two options:
Get copyright assignments and dual-license for app stores. (The scope of this could be bound by contracts). It appears that the community is not happy with this solution for various reasons.
Change the license in general to something other than GPL.
I’ve spoken to Richard about this and it is apparently their view that App Stores and GPL are incompatible and it doesn’t appear like they’re going to budge on that. So, as much as I find it ridiculous that we should water down the license and remove the freedoms that the GPL provides for one specific use case that could be solved under contract law, it is important for us also that we should be able to offer Heartbeat (which will include Pulse) on app stores. So if the only way to do this that is acceptable to all authors is to water down the license — I’m open to hearing the suggestions.
Without copyright assignments and an ever-growing number of authors, it is clear that we cannot really enforce the GPL in the future anyway so perhaps the best thing is to revert to MIT so that anyone can do anything they want with the source. Which, unfortunately, will mean that a venture-capital funded company that wants to build a proprietary Dropbox competitor can take everything we’ve done, invest a couple of million in adding features that are closed source, and sell that product without contributing anything back.
As far as Ind.ie is concerned, everything we do will be released as free as in freedom licenses but we do need to be able to put convenient versions of our apps on the App Store and sell them to bring in sustainable revenue. These should not be incompatible as long as the source is available and I feel that this is a failing of GNU/GPL’s hardline stance.
So if this means we have to go back to MIT, I’m willing to go along with this for Pulse. At least it’s compatible with GPL and it will solve the App Store problem.
Thoughts?
I am lost now. Syncthing is GPL which means Pulse is GPL and it will stay GPL unless you fork at the point it was MIT.
Now Heartbeat will just package Pulse, Heartbeat might be MIT or whatever but I think the fact that you are packaging Pulse is still a problem, as GPL does not allow enforcing any other restrictions on to it, which is what the App store does, which means you cannot package Pulse to be part of Heartbeat onto the App store. Am I right?
Which is exactly what I was saying and the solution is, as I stated, either for an entity to have copyright so any binaries that want to placed on App Stores can be dual licensed or to go back to a permissive license like MIT. (I have not added anything with that to what I originally wrote, by the way.)
Heartbeat, Waystone, and any other core projects we have copyright and control over will be under GPL. Nothing that happens here affects that. (We are not about to change our manifesto.)
Hi Aral. The incompatibility between GPL and the Apple App Store is very inconvenient indeed. I actually understand GNU’s stance, and feel that the incompatibility is a failing on Apple’s part. But it’s a reality that we need to deal with for now, and that’s why the ports to Swift and Java are MIT licensed.
I would support this course of action.
But this makes no sense if you mean that your contributions would continue to be GPL licensed? Or do you just mean that heartbeat and other similar services that are not to be released on an App Store would be GPL?
@dapperstout: Since you are the sole author of the Swift & Java ports at the moment; you have the right to dual license the code as you see fit. So you could release the source under GPL and also provide a license that allows binaries to be released on the App Store.
@calmh: Since we have copyright on our own contributions, we can dual, triple license as necessary. The problem here is that no one has that flexibility as there are ~25 authors who must approve any action.
Tbh, I don’t really like changing the license again after just a month or so.
For Heartbeat on iPhone, it might be possible to dual-license syncthing as LGPL?
Or just not distribute it on an app store. Distribute something else that adds value to the equation, and that uses syncthing if installed, or just installs it from the network if it isn’t?
Syncthing will “never” run on the iPhone, as it’s code built with a non-Apple compiler etc. On the Mac App Store, programs presumable have the freedom to do a little bit more as they please (within the sandbox).
License or not, I would be a bit pissed off if someone distributed “just” syncthing on whatever app store and charged for it. 
In the “License question” thread, @rodneyrod said:
Moving to something which gives a little more of a middle ground, like LGPLv3 or the Mozilla Public License v2 has put an end to these discussions rather quickly, since both sides are appeased.
I have read most of the relevant threads on this forum and I have not found any explanation as to why this won’t work. I am not an expert so I might be missing the obvious here, but maybe its worth looking at those licenses again to get around the app store issue while at the same time ensuring “enforceable freedom” if that makes sense?
Copyright licenses are just lists of terms of use. Pure GPL or giving up on the “freedoms” it offers are not the only options.
There are some precedents which had serious legal scrutiny for adding exceptions to GNU licenses. Nokia did so when they owned Qt - they had the LGPL with exceptions for static linking and instantiating C++ templates if I remember correctly.
If Ind.ie intends to sell versions of the software on public app stores, why not make this explicit in the license, rather than rely on dual licensing through copyright ownership?
Although I’m not a big fan of the GPL, it seems to be the majority preference of the contributors here, yet there does seem to be a general desire to allow public app store distribution. Even though iOS can’t run the Go version of Syncthing, the MIT Swift port is surely going to want to be able to look at the implementation of future features and protocol changes too, so I think the license will need to match in the long run /cc @dapperstout.
How about adding an exception to the Syncthing license and mirror that in Pulse? e.g.
GPLv3 with unmodified app store binary distribution exception.
This source code is licensed under the GNU GPLv3 with an exception to allow distribution on public app stores. You can submit a binary built from a GPL licensed version of the source code, which has been published publicly online, to a public app store for distribution. The app store owner and/or operator can process that binary in their standard way (including internal distributions, re-packaging and even adding DRM mechanisms) and distribute it via their app store without complying with the terms of the GNU GPLv3.
For the avoidance of doubt, no other exceptions to the standard terms of the GPLv3 are granted by this license and the app store owner and/or operator gets no additional rights to use the project in source code form.
That ought to cover it.
FWIW, additional things to help with abuse on the app stores while giving everyone the same rights to the code as you (more for Ind.ie than Syncthing):
I don’t think you have to worry about people selling just Syncthing on the Mac App Store - I don’t think it’d pass review and if it does you can always provide an official package that’s free… then no-one’s going to download the paid version. This is why the GPL is supposed to only mean free as in freedom but always ends up meaning free as in beer too. If Ind.ie wants to sell Heartbeat then the dual licensing route makes more sense there, although paid apps and broad adoption don’t really go hand in hand - a donation model might be better.
Hope that helps, Mark
I’m pretty certain that a sandboxed app can’t install anything from the network. 