@aral cut the personal attacks please, it’s helping nobody.
I’ve read through your posts and find it hard for you to achieve anything with that sort of attitude. You class both Pulse and Syncthing as a component and not a product but I definitely don’t see how you get to this conclusion, Syncthing is far from a component even at this early stage.
At any rate all I’ve ever seen since finding Syncthing in November are constant posts from you not getting on with something or nitpicking instead of spending your time doing what you say you intend to do.
So @aral, why isn’t the MPLv2 a viable option for you? You haven’t said anything about it, when it seems like the obvious solution.
2 Likes
Hey only a few words from me to this conversation. Beside Hyperboria, Syncthing is the first Project I’ve seen that does realy something against the intended restrictions of the Internet from states or others and for more privacy. So I’m following Syncthing just since some weeks but I’m impressed what allready have been done!
And I think it should keep up in this manner and that includes also that every product, that says, it uses Syncthing should be open as well. Under MIT-license an other product could use Syncthing and brand it as a safe and secure product but oneself coud be closed source. I think thats not honest and undermine the fight against restricting the freedom of the internet! Who knows, what a product like that could do beside, when itself is not opensource?
The only and most important thing ist to suport projects like this one, so that they can keep up!
Discussions like this waste useful energy!
I’m a poor electroingenieur-student, but when I can suport projects like this, it would be a pleasure for me 
I’m not sure that the goal of Syncthing is really to go against restrictions of the internet from states. I simply see it like an open-source alternative to BittorentSync. Other projects such as Freenet, I2P, RetroShare, OneSwarm or Waste are more intended to build a communication network “spying proof”.
Because I hadn’t had a chance to read through it. Now that I have, it seems like a viable fit. As I understand it:
-
Any changes to the source code must be shared back
-
You can do what you like with binaries (as long as you share back)
Is there anything else I’m missing?
1 Like
That’s pretty much it. Only thing is, if you want to allow this work to be combined with (L/A)GPL code i.e. compatible with those licenses, you need to remove the ‘Incompatible with secondary licenses’ clause at the bottom of the license file, otherwise users won’t be allowed to proliferate to those licenses.
I wrote a huge rant in response to the Oct-Nov discussions about my dismay of switching to GPL, and now I am very pleasantly surprised to come across this more recent discussion and see that Aral / ind.ie came to the realization of the limitations of the GPL!! I’m all for a Stallmanian utopia where all software is GPLv3, we all have Star Trek replicators so no programmers starve, but we aren’t there yet, and in today’s world, GPL is brutally impractical, (especially for something like syncthing that might be useful as a library,) and therefore repulsive to a huge chunk of developers.
I think SyncThing/Pulse looks awesome and set up a bunch of shares across 6 devices, but then was about to write it off as a user due to lack of app store compatibility. I want an open source bittorrent sync replacement, and I have that on iOS/Android but it looks like SyncThing can’t go on iOS, and new features/bugfixes can’t be brought over to the swift port since they are derived works of GPL software…problem!! And I was about to write it off as a potential developer who could contribute bugfixes/small features, because I work on mobile apps and games that get deployed to app stores (I’m actually considering a sync mechanism for a mobile and perhaps console game, as well as some eventually open sourced (MIT libraries) to support it), where GPL and LGPL are both no-go’s. When I see *GPL, my brain thinks “you’re dead to me” and moves on. It’s not a philosophical choice, it’s my reality. And I am not alone.
As much as I wanted to unload my beautiful unabridged rant against the anti-freedom GPL and LGPL (MPL is ok with me), it looks like peacemaking is needed now:
Guys, PLEASE don’t let petty misunderstandings undermine what could be a great synergistic relationship, or put the future of what should be a BitTorrent Sync killer (and eventually DropBox et al killer, and foundation for a facebook killer,) in jeopardy! So take a breath! 1) Aral makes the dig at spyware companies as part of his regular ind.ie schtick – it’s clear to me it wasn’t directed at Jakob. 2) Also, Aral wasn’t being disingenuous/FUDding about the GPL and derived works. Jakob has a very valid point about fixes being derived works of a GPL, but what constitutes “so inspired it is a derived work” is very much a fuzzy thing that is open to interpretation and Aral just didn’t seem to be as concerned. Why? First, he has a point that algorithms (such as trivial bug fixes?) can’t be copyrighted in their purest form, so that may eliminate the need to find alternative fixes in some cases, (albeit the person who reads GPL syncthing code to determine what is a trivial fix may be “tainted” and unable to contribute to a MIT codebase.) But perhaps Aral does not fully understand how being inspired by GPL bugfixes/commits may taint code as derived work of GPL and therefore be infected by the GPL virus. Or maybe he thinks he and his people have the resources to do clean-room implementations. In any case, there’s no reason for the discussion to get heated. 3) In the context of Aral’s grandiose vision of displacing Facebook, pulse/syncthing is just one small component, but to Jakob and users like me, syncthing is a pretty big deal right now as a standalone cross-platform application! We each have different perspectives about how it is useful to us – don’t get bent out of shape. Some of us think BTSync replacement is big potatoes, while others think that Facebook replacement is big potatoes (and anything else is small potatoes.) And I want to include some sort of peer to peer sharing/sync in apps I make – that could be the kind of thing Aral was referring to when he said it could be a component of something larger. 4) I would think it would be good to not resent ind.ie for not contributing back yet – I’m guessing they have a lot of software to write and adding v2.0 features to syncthing will come but it’s not the biggest bang for their limited buck at this point.
I have been waiting for years and downloaded tons of crappy closed source non-cross platform sync software over the years (one was so good, FreeFileSync, I put up with it even though it defaulted to install Conduit malware in its installer, and I accidentally installed it once. Holy cow! So much for my extreme disdain for malware purveyors.) SyncThing/Pulse/ind.ie is too good of an idea to blow up from misunderstanding in a few messages. BitTorrent Inc., closed a thread in their forums that was advertising SyncThing too much. That’s how I found out about it. You’re sticking it to the man! Keep it up!
You two appear to be prone to emotional overreaction, and hasty decision making (so don’t feel bad about changing your mind – making bad decisions is fine as long as you’re not too stubborn to fix them.) Realize these weaknesses and be prepared to gracefully deal with the consequences, (as you grow out of these weaknesses.) But neither of you guys is mean-spirited. You guys should be friends. Trust me.
So I say pick MIT (or MPLv2) and get on with making beautiful music together!
3 Likes
I was personally glad to see the move to GPL as for me that’s the sign of a project that will last, often beyond changes of stewardship. In contrast to some who write-off GPL software, I will write-off non-GPL software when deciding what to invest time / energy / and code in. I say this just to show that not everyone is against the GPL. (Though of course I respect everyone’s views)
With regards the App store, I am happy to see Apple unable to benefit from the wealth of GPL software as it is a small encouragement for end users to shun their products. The solution to the App store problem in my view is for those who wish to see syncthing supported on such devices to create their own implementation of the protocol and put it under a license compatible with Apple’s policies. Not ideal from ind.ie’s point of view, but a workable solution.
I am grateful to all involved in syncthing for such a great contribution to our world. And equally I have great faith in Aral’s vision for a more equitable future for all regardless of technical ability and wish him all the best in proving the model works.
I hope you don’t mind me sharing my views on the project with you all, I know time is precious! Oh and… I’m celebrating my first minor contribution to the codebase going out in a release 
Yay!
6 Likes
Shots fired!
FWIW, the protocol implementation is now separate and MIT licensed, so at least that part is free for anyone to look at, copy, modify, print, burn, yell at and so on. 
https://github.com/syncthing/protocol
Hopefully some cleanup and docs to follow to make it more of a genuinely reusable component, but in the meantime it’s the code to go with the specs.
3 Likes
FWIW, if a project grows, it might make sense to introduce a contributor license agreement (CLA) to be able to change the license at a later point in time. The GPL might not be the right license forever. There could e.g. be a legal bug in the version of the GPL used. An agreement with a nonexclusive license could be sufficient for the purpose of changing the license later.
But in any case the decision to introduce a CLA should be carefully planed, as it involves a lot of difficult decisions and requires a certain infrastructure. The most important decisions would probably be: Who decides a license change and how? and Who do the contributors license their rights to? (Ideally a non-profit entity.) Before these questions can be agreed on it probably makes little sense to debate much about whether a CLA makes sense. But at some point it will be too late. Because the introduction of a CLA, just like any change of licnese without a CLA, ideally requires everyone’s consent. The VLC experience when trying to relicense is a good example for the difficulties in getting this when a project has grown.
1 Like
Just to update you all, we have gone back and reforked from the MIT-licensed version. We’re building upon and using that version in Heartbeat.
We’re also no longer supporting Pulse as a separate product, although anyone can still download and use it. We’ve suggested that people look at Syncthing instead if they want a standalone file synchronisation app.
You can read the full update here.
Best of luck with everything and I’m sorry it didn’t work out.
I know that my answer is completely off-topic here, and I apologize in advance. However, since you posted a link to your article and there is no way to comment, I’ll do it (shortly) here.
The paragraph “Why Mac?” is a complete non-sense. Apple is a spying company. For the record, they are tracking their iPhone/iPad users, and are also spying the searches in Yosemite. You compare Apple to Google, but you know the comparison with Microsoft or Linux would not keep up very long. The only honest sentence I read is the following:
Finally, all of us at Ind.ie use Macs and so we are both familiar with the culture of the platform and we will be eating our own dog food, as it were.
You are a very small team and all Mac users, so you develop for Mac. This pragmatism justifies your choice.
Again, sorry for the off-topic.
1 Like
Apple is a closed/proprietary company and thus not ideal in the long-term (and thus why our goal is to eventually build our own platform). However, you must understand that the question isn’t “can they spy on you if they want to?” (sure, yes) but rather “is it in their interests to spy on you?"
For Google, yes. Spying on you is how they primarily make their money.
For Apple, no. Selling you products is how they make their money.
Now think about what’s happening in the world. More and more people are waking up to corporate surveillance. This includes policymakers and politicians. The corporations are countering by increasing their lobbying (“ok, you see us for what we are now, here’s some money”). Regardless, there will be an increasing amount of regulation. Some of that regulation could seriously harm Google (which is why they’re spending so much on lobbying). When I talked to Eric Schmidt last year, he said that regulation “could kill Google”. Not immediately, but slowly, over time, could kill what it can become.
So take a world where privacy starts becoming competitive advantage. And yet it is the one area that Google cannot compete in. (Not won’t but can’t, as it is mutually exclusive with their business model.) They can only compete in the illusion of privacy and they can compete in security, which is a related but very different thing. What they cannot compete on is actual privacy.
If Google stops spying on people, they will go bankrupt. (And if they even thought about altering their core business model, they would be sued by their shareholders.)
Apple, on the other hand, can compete on privacy because their core revenue stream is not tied to monetising data.
So answer me this: if you have a competitive advantage that your main competitor(s) cannot compete on, would you throw it away?
Only if you’re an idiot.
And something tells me Tim Cook isn’t an idiot.
1 Like
I also want to comment on your Article. Why are there no comments? (and please without disqus)
I LOL at the whole “Apple isn’t a spyware company” because that’s just being naive.
2 Likes
Is the code you’re writing for Heartbeat not as easily portable to other platforms as you had first thought?
The concept of Heartbeat is great, I would really use a decentralised Facebook-like platform, especially if it had options for event handling, contact syncing and synchronous communication, I would have liked to have seen it available to more platforms early on, but I suppose that if this is going to be open sourced in the future, someone in the community might be able to do that.
(Bringing this slightly back on topic…)
That’s one way. :) As I remember we talked about at the start, I think it’s more likely you should remove code rather than add it, to work well for your underlying requirements. Will you be publishing source for the result?
(Edit: I previously asked whether the existing Pulse development was going to be stopped, which has been answered in practice by the repo being renamed to ...-legacy. I see there’s also activity on the Swift port, which is neat!)
Wow.
I had high hopes for ind.ie.
Carry on, Mr. Bork. You’re doing good work.
You have my sympathies for putting up with such abuses.
1 Like