[archived] On GPL without contributor licenses, the App Store, and future of Pulse

Hey folks,

We have a problem.

As you know, Syncthing is currently GPL licensed and yet has no contributor license agreements in place. This means, among other things, that no one can put a Syncthing-based app (or Pulse-based, as Pulse is a fork of Syncthing) in the App Store (or any app store, most likely). It also means that no one entity can defend it against license violations, etc.

For Ind.ie, it means that we do not currently have control over a component that we are using as a core element of our platform and thatā€™s unacceptable for us, going forward. (If we are to compete with proprietary software vendors who have 100% control, we must also.) We already have the disadvantage that we are four people (two developers) with $100K+ in crowdfunding vs. thousands of developers with billions in venture capital. (Weā€™ve structured Ind.ie so we cannot take venture capital even if we wanted to because there are no shares ā€” weā€™re a social enterprise limited by guarantee.)

Anyway: going GPL without contributor license agreements was a mistake. It was a mistake on my part as I didnā€™t think about it and assumed they would be in place (live and learn).

So, the question is, what are going to do about it?

The easiest way out of this mess would be to revert to MIT.

Iā€™ve talked to Jakob about this and he does not seem to favour this option.

If thatā€™s the case, it leaves us with two options ā€” neither of which are fun but one (or both) of which are necessary for Ind.ie, going forward:

  • Re-fork from the MIT version and continue from there
  • Re-implement from scratch

Of course, ideally, the easiest option is to revert to MIT and then we solve the app store issue also.

Would love to hear your thoughts on this.

Why would it mean this? Having to sign over copyright with a contributor license agreement is a fairly recent development, driven by corporations, and nothing thatā€™s inherent to using GPL or part of itā€™s history. The only reason for doing it is to be able to distribute the software under non-GPL terms for whatever reason (usually economic). Are you referring to the fact that I would have limited funds to pay layers to mount a litigation against some violation, while if copyright was signed over to some entity with a lot of cash this would not be a problem? Are you offering your $100k as a legal defense fund? :wink:

Iā€™m not really sure what control you are lacking, but I guess you mean the ability to sell it as is? If so, yeah, I guess. Itā€™s free software, so you have the same control you have over Linux, the rest of the GNU toolchain, etc.

Well, yes and no. Can we clarify what exactly it is you want to accomplish once the license is changed? Obviously, the legal defense part is a red herring since going MIT doesnā€™t accomplish anything remotely useful on that front, so Iā€™m assuming this is all about putting Pulse (Syncthing) on the app store? Under what terms, for whose financial benefit, etc?

The part where Iā€™ve said Iā€™m not super impressed by MIT (in email) is for the case where someone just grabs a blob of code and sells it on the app store, without the original authors getting a dime. This is in the spirit of the MIT license, and generally itā€™s something I havenā€™t worried about in the past because itā€™s usually not worth it while the original project is out there for free.

But the app stores changes this dynamic in that all you need is a little marketing and you can easily drown out the ā€œgenuineā€ project, even if that is also available for free on the same storeā€¦ I donā€™t want to see fifteen clones like ā€œSyncthing Proā€, ā€œPulse HDā€ and so on out there that random people are selling and marketing on our behalfā€¦

2 Likes

There is the option of using ā€˜weakā€™ copyleft licenses such as the LGPLv2.1 or MPLv2, the latter can even be edited in such a way that the compatible ā€˜secondary licensesā€™ can be defined by an external authority such as the Ind.ie project.

Any modifications to the library would have to be distributed under the same license, so in effect if a company tried to add their own sauce to the Syncthing library, it would have to be redistributed under the LGPL or MPL.

1 Like

There might be a useful middle ground here, yes. Iā€™ve heard good things about MPLv2 here and there.

This is tricky by the way, since you need to ensure that you are not influenced by the GPL code that came afterwards. That means not fixing the same bugs in remotely the same way, not implementing the same features, etc or itā€™s a derived work of the GPL code again. GPL is called viral for a reason. :slight_smile:

1 Like

If I understand this part of the MPLv2 correctly,

3.2. Distribution of Executable Form

If You distribute Covered Software in Executable Form then:

such Covered Software must also be made available in Source Code Form, as described in Section 3.1, and You must inform recipients of the Executable Form how they can obtain a copy of such Source Code Form by reasonable means in a timely manner, at a charge no more than the cost of distribution to the recipient; and

You may distribute such Executable Form under the terms of this License, or sublicense it under different terms, provided that the license for the Executable Form does not attempt to limit or alter the recipientsā€™ rights in the Source Code Form under this License.

It basically says ā€œif you distribute a binary, you must make source available and let people know where to find itā€ and ā€œdistribute the binary under whatever license you like, as long as the source is available as aboveā€.

Which seems both app store and common sense compatible to meā€¦

1 Like

Hey Jakob,

A contributor agreement doesnā€™t mean signing over copyright. Look at how Canonical do it with a license assignment. Iā€™m not a fan of having people sign over their copyright or waive their moral rights. At Ind.ie we will be using an agreement based on http://contributoragreements.org

Yes, exactly: we need to be able to distribute on App Stores. We need to distribute on App Stores if we are to compete with the ease of proprietary solutions that distribute on App Stores. And yes, we will be asking for payment for App Store versions of Heartbeat to keep Ind.ie going because we do not work for spyware/malware companies during the day to fund our hobby of working on open source projects in the evening. Instead, we are trying to create viable, sustainable alternatives.

No, Iā€™m referring to the fact that you do not have the legal right to defend anyone elseā€™s copyright.

We can then include Pulse as part of Heartbeat and potentially on the App Store in the future. Regardless, it will mean that we donā€™t spend our limited resources contributing to a code base that we do not have control over.

This isnā€™t for Pulse ā€” Pulse is a component of Heartbeat. As is, Pulse/Syncthing wouldnā€™t make sense on an app store. Thatā€™s not what its for (at least not how I see it). Itā€™s a component, not a product.

GPL isnā€™t a patent :slight_smile: Last I checked, you cannot license ideas under GPL, just code. Unless we copy code, we are free to reimplement or implement new functionality on an MIT codebase as we see fit. Are you saying that anyone who implements the Block Exchange Protocol must do so in GPL? That any other language implementation must be in GPL? If so, you should make that very clear in the protocol license so that people know not to use it.

1 Like

Why do you need this? What is GPL not providing to you with that you need to satisfy your goals:

I want technology that protects our freedoms, human rights, and democracy, not technology that erodes them. I want technology that I own and control, not technology owned and controlled by corporations.

1 Like

I donā€™t need to. Defending the majority of the project I still have copyright on is enough to defend the project.

Now youā€™re just being disingenuous and spreading FUD. Algorithms and ideas are not copyrightable, at all. The protocol is public domain, of course there are no restrictions on the license of implementations. Iā€™ve said previously that even if an implementation in another language were similar enough to somehow constitute a derived work by some lawyerly definition, Iā€™d never ā€œgo afterā€ that because thereā€™s absolutely no reason to. I want there to be multiple implementations.

But reading a patch, then implementing that same feature on the same codebase in a similar manner is generally considered a derived work. This prevents idiocy like following a project commit for commit and reimplementing each step slightly differently with a different license and copyright. Or getting a patch, saying ā€œthanks, iā€™ll just reimplement it myself slightly differentlyā€ and not giving credit where itā€™s due.

But letā€™s not go further down this discussion, because itā€™s stupidity.

You want to use Syncthing/Pulse as a component in Heartbeat. Thatā€™s awesome, itā€™s what we discussed at the start of our venture, and I suggested then ā€œjust do it man, itā€™s MITā€. :wink: Now it isnā€™t anymore, and ironically it was you who convinced me to be OK with GPL by the reasoning of not letting evil corporations steal and sell the code.

So how about something like MPLv2 above? It lets you use Syncthing as a component, it requires source to be released for modifications, win-win? Youā€™ve said Pulse isnā€™t going to be sold as a standalone app by Ind.ie, and Iā€™m fine with that. My nebulous ā€œapp store gold diggersā€ should be somewhat deterred by having to release source, and if they arenā€™t, whatever. Are there any downsides I donā€™t see here (from either camp, GPL-preferrers and MIT-preferrers)?

So, I was trying to steer this back to something constructive, but then I reread this and see the dig against me in the second sentence and get fucking angry. Yes, I work for a company you donā€™t approve of during the day, producing something in the evenings for the benefit of all, that Iā€™m not selling.

You want to take that and sell it, with an as yet unspecified layer of functionality on top. So you barge in and declare ā€œwe have a problemā€, insult me, and want license changes so you can sell the software? The software that you and your company have so far contributed zero lines of code back to? Thatā€™s a bit of a crappy attitude, to be frank, and not the way towards whatever goal you haveā€¦

Perhaps if we lay off the personal attacks, define the goals, and define what you intend to contribute back to Syncthing, we can get somewhere?

3 Likes

Our ability to compete on UX with proprietary solutions that are available on App Stores. Also the competing on unequal ground with proprietary software companies that control 100% of their codebase.

I donā€™t think thatā€™s hard to understand and Iā€™m not sure how to make it any clearer so Iā€™ll stop trying.

It wasnā€™t a dig at you specifically but at ā€œopen sourceā€ in general. Working at (e.g.) Facebook, Google, etc., and, with the privilege afforded from that, working on open source projects as a hobby is quite common. And no doubt a lot of value is created that can be used by independents as well as proprietary silos. But whatā€™s not created are alternatives.

So here we are, a tiny group of people, who are working for comparatively little pay (everyone gets a little over Ā£2K a month expect me, I just put money in and donā€™t draw a salary; I subsist currently on professional speaking fees) who are trying to make an alternative. I donā€™t mention this because ā€œhey, weā€™re holier than thouā€ but because Iā€™m sick of the allegations that somehow weā€™re some sort of corporate entity in it to make money. If I was in it to make money, Iā€™d be working at a cushy job at a malware/spyware company instead of setting up a social enterprise that doesnā€™t even have shares so that it cannot be sold or accept venture capital. So thatā€™s quite enough of that, to be honest.

I think itā€™s clear that we have very different cultures and Iā€™m done responding to ā€œwhy canā€™t you do it our wayā€ questions. Weā€™re not doing it your way because we donā€™t have or want the privilege of working at malware companies for high 5/6 figure salaries during the day while we work on open source in the evenings. And we have absolutely no reason to justify our actions to people who are.

Please feel free to do whatever you like with the license of Syncthing going forward. Itā€™s your hobby project and you have every right to run it as you see fit. At this point, Iā€™m done wasting our limited resources on this farce.

We will continue to use the fork, with whatever restrictions are present in the license, until we have our own implementation of something that solves the same problem.

It was my mistake in thinking that open source culture could evolve to be compatible with independent technology. Itā€™s not. We wonā€™t make that same mistake again.

1 Like

This is a textbook example of where the GPL can unintentionally lead, and one more reason I stick to the most minimalistic permissive licenses (MIT and BSD) for my own open source projects.

IIRC, back when the Syncthing license was MIT the lead developer was cool with a company of some sort doing a friendly fork.

Then - who knows why - said company suggested relicensing under the GPL, soon to find out they had shoot themselves in their feet.

Now, no matter how much goodwill may have been there from both sides, it sounds like the Pulse fork is not going to be that friendly anymore, and chances of cooperation and mutual benefit for the two projects appear slim.

No individual or small company can really afford the legal costs of enforcing whatever license terms they set against some ā€˜big evil corporate code thiefā€™ anyways, so why bother with pages of licensing legalese? If I MIT/BSD license something and somebody takes it and makes millions, good or them - they found a business case I wasnā€™t aware of and wouldnā€™t pursue myself. If I code something specifically for my own financial gain, I simply do not open source it. I can always license it for free to whomever/whatever use I may wish.

But hey, to each his own, and thanks a bunch for giving us Syncthing and any offsprings may come. Please take my post as well meant, from a user who appreciates what great tool Syncthing is :o)

2 Likes

@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 :wink:

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