Hi everyone, I would like give you a little heads up on what I’m currently working on in my spare time: I started porting the Syncthing protocol to Java and Swift.
It’s still early days, and because I’m only able to work on it in my spare time, it will probably take a while before it is complete. I am however always grateful to get early feedback, so please don’t hesitate to look over the code and give me honest feedback.
You can find the code at http://dapperstout.com.
I would support the port to Java with both hands if it would help anything.
For one thing, the GUI aspect and dynamics reporting could be significantly improved with Java built-in GUI subsystem, and it would be as portable as what they have now, if not more.
Then the exceptions handling could significantly improve the error reporting since exceptions thrown could be handled by the higher levels on the stack where the context of some error could be reported in a much more meaningful way. The whole anti-exception argument of the Go designers seems to be a joke and nothing more than that. To claim that code with exceptions is bigger than without them is just upside down in reality. Because with exceptions you get rid of most of your rudimentary logic (all the ifs and buts) and simply execute the code without worrying about the return results. So, the code becomes smaller, not bigger, and SIGNIFICANTLY so.
The same thing is applicable to the issues of synchronization. In Go, it may be “easier” to use, but their arguments are pretty weak.
Anyways, we’ll put this thread on watch and if we find some progress with Java, it will be reported in quite and extensive manual on sync. From the preliminary look, it looks like not much code has been converted so far. Or am I missing something? Are there any estimates on when the port is going to be complete?
Good luck. We’ll review what you have with your progress so far.
Hi Alberto and anyone else reading this thread,
I’d love to hear what you think of the code. Feel free to send me review comments or pull requests on github. It is certainly true that not much code has been converted. I’m only halfway through the messages that make up the Block Exchange Protocol. And that is in the Swift port, which is currenlty a bit ahead of the Java port. So I wouldn’t expect a working Swift or Java library before the end of this year. I am, after all, only able to work on it in my spare time.
Good luck with that.
By the way, will there be a Javascript port at all, for all the HTML app devs?
Making a Javascript port does sound like fun. But I think I want to finish porting to Swift and Java first 
Hey, never said it was something that was needed, just curious is all. And thanks for doing all this work gratis.
Good thing there are alternatively licensed Syncthing implementations like these so developers are offered licensing choices when developing apps for restricted environments like the App Store or Windows Marketplace.
I’m really happy to find someone working on this but… are these clean room implementations of the protocol or ports. I realise more liberal licenses are needed on iOS and possibly even for Google Play but you can’t just decide on a new license for ported code. A port is a derivative work so it’d have to be GPL unless all the copyright holders of the original work agree otherwise.
Google Play doesn’t have any requirement for project licenses.
It’s true that Google will let you provide any license you want to the end user, but you also grant them (Google) a license that isn’t necessarily compatible with the GPL (because it doesn’t pass on the copyleft conditions). They also make you agree that you’ve obtained permission from the copyright holders to do so, so it’s all on you.
In reality, I’m sure Jakob and the other contributors are not only happy with the code being used in mobile apps but actually want that to happen. However, the GPL is a (deliberate) legal mess and doesn’t play nicely with almost any other generic T&Cs you might have to agree to with a middleman distributor.
In Google’s case it’s a very mild possible infringement of the license. In Apple’s case there are minimal terms for the EULA you can provide to end users and they are in places in direct conflict with the GPL. Of course IANAL, but I worked for an open source software foundation and have yet to meet a software copyright lawyer who doesn’t think the GPL is just best avoided if at all possible - the only thing they’re almost unanimously certain of is that it doesn’t mean what its creators intended it to mean.
My personal opinion is that if you must use the GPL then add specific exceptions for grey areas where you actually want people to be able to do stuff - like distributing on app stores. Ideally dual license with something less messy.
Okay I’m definitely not a lawyer and I couldn’t find any sure source, but there are many apps (eg Bitcoin Wallet) on Google Play that use GPLv3, so I’m worried about this.
Do you know any better/simpler alternative to GPL with similar conditions? Or are the problems you’re describing a caused by the intent of the license?
You can’t find any sure source because no-one will stake their reputation on an interpretation of what the GPL does or doesn’t mean outside of what a judge has already decided. 
Unfortunately the problem is with the intent of the license. The GPL tries to force copyright law to do something it was never intended to do. If you’re sure you want strong copyleft, the GPL is the best way to go.
In the real world I struggle to think of popular projects that actually need the protections the GPL attempts to offer. The Linux kernel is usually cited as a major case but they openly tolerate closed source drivers and actively avoided moving to the GPLv3. The main real exception is dual licensed projects that use the GPL to be both open source and sell commercial licenses to companies that understandably don’t want to touch the GPL.
As I see it, Ind.ie software ought to aim to eventually be included by default in devices everywhere. This is not the license to achieve that.
My view, after many years of thinking about it (I was once a fan of the GPL), is that open source projects main problem is adoption and more liberal licenses do better there (even weak copyleft if it’s felt necessary, although most people who add to an open source project would rather someone else maintained their code). Keeping the project free is best achieved through a strong developer community, such that a fork with proprietary code can’t out-compete the original. I think the freedoms that the GPL tries to protect for its users, most of them will never care about. The freedoms are really for developers and those developers are perfectly capable of choosing products that allow them to retain the freedoms.
When it comes to end user security/privacy etc. being protected, I’d claim the GPL does nothing. You have to either compile the software yourself or get it from someone you trust. If someone wants to insert spyware or backdoors in some binary distribution of open source code they will and they won’t tell you they’ve done it because the GPL says they have to disclose their code. Indeed it seems that those that want to spy have been able to insert security holes in open source code publicly without anyone noticing for years, let alone what they do to binary distributions.
We have had some people express happiness about GPL, because that made them feel that the contributions they make eventually will not get wrapped up to some commercial closed source project, so it’s very subjective to the individuals view.
Yeah. So, the internal/protocol package could probably be broken out into a separate, MIT, package if we wanted to and thought it would be useful. The only changes done since the MIT licensed versions are by me and @AudriusButkevicius so it should be painless bureaucratically if we wanted to go there.
Hi Mark, you raise a good point. I think that there is no legal issue with licensing the Swift and Java ports under the MIT license. I am basing them on the protocol description, and only occasionally used the older Syncthing Go code for reference, which was from before the switch to GPL.
Legal issues aside, I do hope that the developers of the Go code don’t take offense to my choice of the MIT license. I have great respect for what they have achieved, and hope that they support the porting effort.
Yes, it’s kind of sad that there’s a split between free software and open source. Like I say, I’ve actually switched sides in that debate so I understand why some people prefer “free” software. I’ve come to see the “freedom” aspect as mostly good marketing.
It’d be a good idea to do that while there are no other contributors. There’s no need to split the package out, you can just change the license on those files. It’s the best way to make sure ports are interoperable.
It feels kind of messy to have a mix of licenses in the same code base, but I guess it’d work. Licenses suck, and changing them sucks even more, that’s for sure. 
Certainly not, I think MIT (or BSD etc) is the reasonable default license in any case. In this case the Ind.ie dudes were kind of adamant on GPL, coming from the Stallman school of thought.
No legal issues at all if you’re referencing pre-GPL versions of the code.
MIT is the most sane choice for iOS since you’ll probably end up with it as a static library to be compiled into apps. Java could go anywhere and I guess the license choice is a bit more open.
If the Heartbeat thing being built on top isn’t pure GPL then I’d be interested in helping with the Swift port. I’m not yet sure how much time I’ll have though.
In this case the Ind.ie dudes were kind of adamant on GPL, coming from the Stallman school of thought.
I’m confused by this. Aral’s initial blogs suggested they needed to attract a different set of developers. Design led open source was the key, not design led FOSS. Even the Ind.ie timeline mentions an iOS port. I emailed Aral about the license compatibility issue but haven’t had a response. Not many users to be had if they all need an iOS developer account and compile it themselves.
Then the social network is launching on Yosemite only initially. Not exactly a free software embracing move. Something that started as privacy + open source + UX focus seems to have morphed into giant corporation bashing + free software fundamentalism. I want to support it but I’m not sure I know what it is any more.
I hear you, and I expect that’s something that @aral will need and want to clarify. I myself can only speak for the syncthing part of the equation.